Choosing MCP Servers for a Coding Agent
A coding agent needs four capabilities, and adding them in order matters more than which implementation you pick. Repository access, the ability to run tests and see output, the issue or ticket context that explains why a change is wanted, and a knowledge layer that supplies conventions the code does not state.
The four capabilities, in order
1. The repository. Reading files, searching, and writing changes. Without this an agent is guessing about the code it is modifying, so this is not optional and nothing else matters until it is in place. Scope it to the project rather than to a parent directory: granting a home directory is the same single argument and puts credentials and unrelated work inside the boundary.
2. The test and build loop. The ability to run the suite and read what came back. This is the capability that separates an agent that writes plausible code from one that writes working code, because it closes the feedback loop without a human relaying results. It is also the most underrated addition, because the value is not visible until you have it.
3. Issue and review context. The ticket, the discussion, the review comments. Code tells an agent what the system does. This tells it why a change is being asked for, which is the difference between a technically correct change and the change that was wanted. Read-only is sufficient for most of the benefit.
4. The knowledge layer. Conventions, prior decisions, architectural reasoning, why the last attempt was reverted. None of this is in the code and none of it is in the ticket. It is the layer that stops an agent solving a problem in a way the team already rejected, and it is the one most teams add last, or never.
After those four, additions are genuinely optional and should be justified by a workflow you actually have.
Evaluating an implementation
Specific recommendations date within weeks, and endorsing software this project cannot verify would be worse than useless. These criteria hold regardless of what is currently popular.
Read the tool descriptions first. They are what your agent reads to decide whether a tool applies, and they reveal how carefully the thing was built. Vague names and one-line descriptions predict tools that are never selected or selected wrongly.
Count the tools it exposes. A server adding twenty tools adds twenty descriptions to every request in that workspace. Narrow servers with clear boundaries cost less and choose better than one server that does everything.
Check what it does when a call fails. Structured errors an agent can act on are worth far more than a stack trace it will misread as data.
Check the credential scope it asks for. A server requesting broad access for a narrow feature is telling you something about how it was designed.
Check whether it is maintained. A server built against an API that has since changed will confidently call something that no longer behaves as described, and nothing in the interface will indicate that.
Prefer read-only until a workflow demands write. Most of the value in the first weeks is inspection.
The cost nobody accounts for
Every configured server contributes its tool descriptions to every request in that workspace, whether or not any of its tools get used. A large catalogue is therefore a standing token cost and a standing source of wrong tool selection, because the model has more options to choose badly among. Install for a task you have; prune quarterly.
Why the fourth capability is the one that changes results
The first three are access. The fourth is understanding, and the gap between them is where most disappointment with coding agents actually lives.
An agent with repository access can read every file and still not know that one module is deprecated, that a pattern appearing in twenty places is the old way, or that the obvious fix was tried last quarter and reverted for a reason nobody wrote in a comment.
That knowledge exists in an organisation. It is in decision records, in pull request discussions, in documentation, in the heads of the people who were there. It is not in the code, which is why an agent reading the code cannot reach it.
Supplying it through tool calls to more servers does not work well, because each call is a round trip and the agent has to know to ask. Supplying it through the conventions file does not scale, because that file is loaded on every request and this material is large.
What works is retrieval: the agent asks for what it needs when it needs it and receives the specific passage rather than the whole corpus. That is what RDK is built for, and stacked retrieval means most of those questions resolve before the model is involved at all, so the grounding is close to free.
Get the first three servers in place. Then add the layer that makes the agent understand what it is looking at.
Frequently asked questions
- Which MCP servers should a coding agent have?
- Four capabilities in order: repository access, the ability to run tests and read output, issue and review context, and a knowledge layer supplying conventions the code does not state. Which implementation provides each matters less than adding them in that order.
- What is the most underrated capability to add?
- The test and build loop. It separates an agent that writes plausible code from one that writes working code, because the agent closes its own feedback loop rather than waiting for a human to relay results. The value is not obvious until it is in place.
- How do you evaluate an MCP server without a recommendation?
- Read its tool descriptions, since those are what the agent acts on and they reveal how carefully it was built. Count how many tools it adds, because each one costs tokens on every request. Check its error handling, its credential scope, and whether it is still maintained.
- Is there a downside to installing many servers?
- Yes. Every configured server contributes its tool descriptions to every request in that workspace whether used or not, so a large catalogue is a standing token cost and a standing source of wrong tool selection. Install for a task you have and prune quarterly.