Model Context Protocol servers can give a coding agent access to documentation, repositories, browsers, monitoring systems, and other tools. That sounds universally useful. It is not. Every server adds tools, permissions, context, and another dependency that can fail.
My rule is simple: add an MCP server when it removes a repeated handoff between the coding agent and another system. If I keep copying an issue, browser error, or API reference into a conversation, MCP may improve the workflow. If a reliable command-line tool already does the job, I usually start there.
What MCP changes
MCP is an open standard for connecting AI applications to external tools and data. A compatible server describes the tools it offers; Cursor, Claude Code, or Codex can then call those tools while working on a task.
The protocol is shared, but the clients are not identical. Configuration locations, authentication, approval prompts, tool discovery, and supported transports vary. A server working in one client does not mean its configuration can be pasted unchanged into every other client.
The shortlist
| MCP server | Best use | Start with it when | Main risk |
|---|---|---|---|
| GitHub | Issues, pull requests, repository search, Actions | Work begins or ends in GitHub | Broad write permissions |
| Playwright | Browser automation and repeatable UI checks | A change must be verified in a real browser | Exposing authenticated browser state |
| Chrome DevTools | Console, network, performance, live-page debugging | The problem is visible only at runtime | Access to open tabs and page data |
| Context7 | Current, version-specific library documentation | Framework APIs change faster than model knowledge | Irrelevant or excessive retrieved context |
| Serena | Semantic code search, references, and symbol-level editing | Plain text search is too noisy for the codebase | Local code access and potentially powerful edit tools |
| Sentry | Production errors and traces | Debugging starts from a real incident | Sensitive production data |
| Figma | Design context and implementation details | Frontend work must follow a source design | Large, noisy design context |
1. GitHub MCP
The official GitHub MCP server connects repository work to the agent doing the implementation. It can search code, inspect issues and pull requests, review changes, and interact with Actions and security features, subject to the permissions of the authenticated account.
The useful workflow is not "give the model all of GitHub." It is narrower: read the issue, inspect the relevant repository state, implement locally, review the diff, and prepare a pull request. Start with read-only access or limited toolsets. Enable mutation only when the workflow genuinely needs it.
Use the GitHub CLI instead when the task is a deterministic command such as viewing one pull request or checking one workflow run. MCP earns its place when the agent must interpret GitHub state as part of a longer task.
2. Playwright MCP
Playwright MCP gives an agent structured browser automation. For application development, that closes an important loop: make a change, open the page, interact with it, inspect the result, and correct the implementation.
I value it most for user journeys and responsive checks. A successful build does not prove that navigation works, text fits on mobile, a modal is usable, or an authenticated workflow reaches the correct state. Browser verification catches a different class of failure.
Use an isolated browser profile for general testing. Connecting an agent to your everyday profile can expose signed-in sessions, private pages, and browser data. Treat that access like a credential.
3. Chrome DevTools MCP
Chrome DevTools MCP overlaps with Playwright, but its strength is diagnosis: console messages, network activity, page state, screenshots, and performance traces from a live Chrome session.
Choose Playwright when you need repeatable interaction and user-flow validation. Choose Chrome DevTools when the question is "what is this page doing at runtime?" A frontend-heavy project may justify both, but I would not install both automatically for every repository.
4. Context7
Context7 retrieves current, version-aware library documentation. It is useful when an agent knows the general framework but may be wrong about the installed version, a recently changed API, or the recommended configuration.
Documentation retrieval works best with a specific question: name the library, version, and feature you are implementing. Pulling broad documentation into every prompt increases noise and latency. It can also make the agent overfit to examples that are technically current but poorly matched to the codebase.
Before adding a third-party documentation service, check whether the vendor offers an official documentation MCP. Codex, for example, can use OpenAI's documentation server for work involving OpenAI products.
5. Serena MCP
Serena is a coding-focused MCP server that gives an agent IDE-like tools for semantic code retrieval and editing. Instead of relying only on file names, line numbers, and broad text search, it can help the agent find symbols, inspect references, understand code relationships, and make more targeted changes.
I would consider Serena for larger or unfamiliar repositories where the hard part is not writing a few lines of code, but finding the right abstraction, understanding where a symbol is used, or making a cross-file change without turning it into fragile search-and-replace work. It is less necessary for a tiny project where the agent can comfortably read the relevant files directly.
Because Serena works close to the local codebase, treat it like an IDE extension with agent access. Follow the official setup instructions, avoid outdated marketplace install snippets, review the tools it exposes, and start with the narrowest useful mode for the task. If the workflow only needs read-only code exploration, do not enable broader editing or shell capability just because it exists.
Situational servers
Sentry MCP can turn a production issue into an evidence-led debugging task by exposing error details and traces. Figma MCP can reduce the handoff between design and frontend implementation. Database MCP servers can help investigate data behavior.
These integrations are powerful precisely because they touch sensitive systems. They should be task-specific, scoped to the minimum data and actions required, and separated from environments containing protected or regulated data unless the complete data flow has been approved.
Cursor, Claude Code, and Codex setup
| Client | Project configuration | User configuration | Useful check |
|---|---|---|---|
| Cursor | .cursor/mcp.json | Cursor settings | Open MCP settings and confirm tools are available |
| Claude Code | .mcp.json | ~/.claude.json | claude mcp list or /mcp |
| Codex | .codex/config.toml | ~/.codex/config.toml | codex mcp list |
Local servers commonly run through stdio as a child process. Hosted services generally use Streamable HTTP and may authenticate through OAuth or a bearer token. Prefer remote HTTP for cloud services when the provider supports it; use a local process when the tool genuinely needs local system access.
Do not commit secrets inside project configuration. Use environment variables or the authentication mechanism recommended by the server. Project-level configuration is useful when the whole team needs the same server definition, but each developer should still review and approve what that server can execute.
A workflow that earns the setup
Consider a frontend bug reported in a GitHub issue:
- GitHub MCP reads the issue, acceptance criteria, and related pull request history.
- Context7 retrieves the exact documentation for the framework version in the repository.
- Serena helps locate the relevant symbols, references, and cross-file relationships in a larger codebase.
- The coding agent implements the fix using the local code and test suite.
- Playwright reproduces the user journey at desktop and mobile sizes.
- Chrome DevTools investigates console, network, or performance behavior if the test still fails.
- GitHub MCP prepares the final issue or pull request update after the diff is reviewed.
This is where MCP helps: it connects evidence from several systems into one development loop. Installing ten unrelated servers in advance does not create the same value.
Security rules I use
- Start read-only. Add write tools only after the read workflow is useful.
- Limit toolsets and scopes. Repository access does not need organization administration.
- Keep credentials out of tracked files. Use environment variables, OAuth, or a secret manager.
- Separate browser profiles. Testing should not inherit personal sessions by default.
- Review external content. Issues, web pages, documents, and tool output can contain instructions intended to manipulate an agent.
- Keep approval around consequential actions. Publishing, deleting, deploying, and changing production data should remain visible decisions.
- Remove unused servers. An integration that no longer serves an active workflow is unnecessary access.
MCP is not always the answer
Use a CLI when the operation is stable, scriptable, and easy to verify. Use a native integration when the coding client already provides the required context with fewer permissions. Use MCP when the agent needs a structured tool during reasoning and the repeated handoff is costing time or losing context.
The best MCP setup is usually small. Start with one friction point, install one trusted server, test one complete workflow, and measure whether it improves the result. Add the next server only after the first one earns its maintenance and security cost.
Official references
Cursor MCP documentation · Claude Code MCP documentation · Codex MCP documentation · Model Context Protocol documentation · Serena MCP
← Back to Writing