8 MCP Server Examples for Real Development Work

At handoff time, consider this failure: a coding agent updates a ticket, exits, and reports success, while another continues from an older requirement in a separate note. The developer expected agreement. Both runs used different records. Coordination failure explains the symptom, but misses the boundary. Useful MCP server examples must match their capabilities to a deliberate permission and state boundary. In AuricIDE, runs launched from a repository tile access shared project records through MCP. The desktop shows the shared update and ranks error above blocked-on-input above stalled. AuricIDE chooses repository-local SQLite storage, accepting weaker cross-machine visibility. Access still doesn't ensure sound judgment. Handing a contractor keys doesn't explain which doors they may open.

1. What does the filesystem server let an agent change?

The filesystem reference server lets an agent read, write, and list files within configured directories. Paths outside that boundary fail. A prompt can't widen it.

For a proposed documentation task, configure access to the project directory alone, then ask the agent to read existing conventions before editing a guide. Use absolute paths. Relative paths depend on the server's launch directory, which might differ from the project directory the developer expects.

This local-process pattern uses MCP's stdio transport. Its cost is write authority over permitted files. Start narrow. Keep the home directory excluded.

The guide to building an MCP server provides implementation context. Inspect advertised resources and prompts separately; file tools don't establish either capability.

2. When should a Git server receive commit permission?

A Git reference server should receive commit permission when the workflow explicitly permits commits without prior human review. Otherwise, keep the agent's task to inspection and proposals.

The server exposes repository status and diffs alongside history, staging, commits, and branch operations. A useful scenario is staged-change review: the agent examines the diff, then proposes a commit message. Review remains separate.

Review boundary: Reading a diff and committing it require different permission decisions.

A server-created commit is an ordinary commit. Attribution depends on its author and message. Make those meaningful.

Parallel runs need workspace discipline. Give each run its own worktree rather than letting agents modify the same checkout, then review their changes before combining them. That choice adds worktree management. It also defines which files each run can change.

Don't assume reusable prompts are provided. Check capability discovery.

3. What authority does a GitHub server inherit?

A GitHub server inherits the permissions of its access token, rather than a separate identity created by the agent's prompt.

Its tools connect issue reading with repository search and pull-request work. Consider an agent assigned an open issue: it reads the ticket, prepares a change, and proposes a pull request referencing that issue. Token scope decides which hosted actions are available.

• Scope: Limit the token to repositories needed for the task.
• Storage: Supply credentials through the client environment, not a repository file.

The cost is credential management. Publication needs review. A prompt requesting caution doesn't reduce token permissions.

Inspect resources and prompts during connection. Returned issue text remains untrusted input, even when authentication succeeds, as the MCP security guidance explains.

4. What should a memory server remember?

A memory reference server should retain facts that help later sessions, with explicit ownership for correction and removal.

It stores entities, relations, and observations in a local knowledge graph. An agent could record naming conventions before ending a session, allowing a later run to retrieve them without repeating the same setup discussion. Persistence saves repetition. It doesn't prove freshness.

The server stores agent-written observations without checking whether they remain true. Old entries require removal. Choose a separate memory file per project, and verify its setting against the implementation's documentation before use.

The operational cost is maintenance. Someone must resolve stale claims.

Treat memory writes as edits to a record, not verified conclusions. Discover resource and prompt support rather than inferring it from the server's name.

5. How should an agent use a fetch server?

An agent should use a fetch reference server to gather page content, never to accept that page as authority over its actions.

The server retrieves a URL and converts HTML into markdown. For example, an agent writing a client call could fetch the API reference, compare the documented fields with its proposed request, and identify gaps. The page supplies evidence. It doesn't grant permissions.

External text stays data, even when it contains instructions addressed to the agent.

The cost is network access and output review. Restrict outbound access when the task doesn't need the open web. For a scoped deployment, enforce a URL allowlist outside any advisory prompt.

MCP separates tools, resources, and prompts, so fetch output shouldn't be confused with a reusable trusted prompt. Check what the server advertises before configuring the workflow.

6. What does a Postgres server expose without allowing writes?

The Postgres reference server exposes schema information and query results while running queries in read-only transactions.

An agent could inspect relevant tables, then query rows affected by a migration before proposing its test. Schema access helps it choose valid fields. Read-only access still exposes data.

• Database authority: Use a role with read grants alone.
• Output scope: Apply a row limit before querying a large table.

Rows become model context. Choose access accordingly. The trade-off is real evidence without mutation authority, while retaining the cost of query load and disclosure review.

The MCP server setup guide offers configuration context. Check schema resources and query tools separately during discovery, and don't infer prompt support from database connectivity.

7. What can a sequential thinking server verify?

A sequential thinking reference server can structure reasoning, but it can't verify that a proposed change works.

Its tool supports numbered thoughts, revisions, and branches. Consider migration planning: an agent breaks the task into steps, then revises its plan after a test fails. The trail records that revision. Tests supply the evidence.

Verification rule: A readable reasoning trail doesn't replace an executed test.

The server holds no project data and changes nothing on disk. Its authority is narrow. Its cost is additional context.

Use a short trail for routine tasks. Allow more detail when the agent needs to compare paths, but keep the final claim tied to observable results rather than the length of its explanation.

Resource and prompt discovery still matter. A reasoning tool doesn't imply access to requirements or repository history.

8. How does AuricIDE give agents a shared project record?

AuricIDE exposes project state over MCP, so connected agents use the backlog and requirements shown in its desktop workspace.

Select a pinned repository tile and launch a configured skill. Skills combine a prompt with provider, model, and permission mode. External CLIs register through schema-validated JSON dynamic providers under Settings → Agent, without a plugin API or recompile.

• Shared record: Goals, tickets, requirements, test cases, dependencies, and history use repository-local SQLite storage.
• Process result: Local PTY child processes report success or failure from exit status.

Chains run ordered skills. Each step receives a cleaned terminal tail from the preceding step, not a complete project record. Failures stop the chain.

The shared-project-state MCP example explains this application boundary. Decide whether to commit the SQLite file before sharing a checkout. Local storage requires an explicit cross-machine sharing decision.

Comparison of 8 MCP Server Examples

Which MCP server should a development workflow use?

Choose the server whose narrowest useful authority matches the task, then define its resources, prompts, credentials, and review rules. Filesystem and Git support local code and history; GitHub supports hosted coordination. Fetch, Postgres, and sequential thinking support evidence gathering and planning. Memory retains observations. AuricIDE provides shared project records. Each choice has a cost: Git can create commits, hosted access inherits token scope, database reads disclose rows, and local records need a sharing decision. Successful connection isn't proof of safe operation. Test rejected calls too, following MCP server testing guidance. > Grant the narrow action needed; keep publication, commits, migrations, and shared-state approval with a person.

Label every capability by what it exposes, what it can change, and who reviews the result.

AuricIDE is an open-source desktop IDE for orchestrating local CLI agents with shared project state over MCP. Visit AuricIDE to examine how repository tiles, reusable skills, and ordered chains fit an existing agent workflow.