- In short
- The build vs use decision for MCP servers is the judgment call between adopting an existing community server and writing a custom one. The default is to use a maintained community server for standard integrations and to build custom only when a team-specific workflow has no off-the-shelf equivalent.
What the build vs use mcp servers decision really asks
The build vs use mcp servers decision is an evaluation problem, not a recall one, which is why it sits at the evaluate Bloom level in Domain 2. You are weighing two paths against a scenario: adopt an existing Model Context Protocol server that someone else maintains, or invest engineering effort to write your own. The skill the exam tests is judgment, recognizing which path a given situation calls for and being able to defend the choice.
The headline rule is that the default is use. The MCP ecosystem already contains maintained servers for the systems most teams integrate with, and Claude Code is explicitly built to connect to hundreds of these external tools. When a standard integration like GitHub, Slack, or Jira already has a solid server, writing your own is like writing your own HTTP client: technically possible, rarely the best use of your time, and a permanent maintenance liability you signed up for voluntarily.
- Build vs use decision
- The architectural judgment of whether to adopt an existing community MCP server or develop a custom one. It favors reuse for standard integrations and reserves custom development for team-specific workflows that no maintained server addresses.
The build vs use mcp servers decision, step by step
Run a candidate integration through three questions in order.
- Does a maintained community server already cover this system? For commodity integrations, the answer is usually yes. If so, use it. You inherit the maintenance, the bug fixes, and the accumulated edge-case handling for free.
- Does a close-but-imperfect server exist? If something covers most of your need with clean architecture, adopting or extending it still beats starting over, because you keep the part that already works and only add the gap.
- Is this an internal or proprietary workflow with no off-the-shelf equivalent? Only here does building clearly win. A custom server is justified by the absence of an option, not by a general desire to own the code.
The trap, and the most common exam distractor, is reflexively building. A team decides they want full control, or assumes their needs are unique, and spends a sprint rebuilding a Slack integration that already exists and works. The cost is not just the build week; it is every future week spent maintaining a server the community would otherwise have maintained for them.
Mapping the decision
What changes once you decide
Choosing use is not the end of the work. Community servers are written to read credentials from named environment variables, so adopting one cleanly means wiring it through a shared config with variable expansion rather than forking it to hardcode a key. It also means scoping it correctly, project scope if the whole team needs it, so the decision connects directly back to the scoping and credential knowledge points that precede it.
Choosing build adds a different obligation. A freshly built MCP tool competes for the agent's attention against Claude's strong, built-in tools, and a custom server with weak descriptions will simply be ignored in favor of a familiar built-in. So a build decision implicitly commits you to the description-enhancement work that follows it, ensuring the agent actually prefers your new tool when it is the better choice. Either path, in other words, hands off to the integration best practices that turn a configured server into one the agent uses well.
Can the API connector even reach it?
A reachability check belongs inside the use decision, because not every server a model can adopt is reachable the same way. Claude Code runs local stdio servers as subprocesses on your machine, but the Claude API's MCP connector, which lets the Messages API talk to a remote server without a separate client, supports HTTP-based transports only: Streamable HTTP and SSE. A local stdio-only server cannot be connected directly through the API connector, so adopting a community server through the API quietly assumes that server is publicly reachable over HTTP when the integration runs.
Two more adoption checks follow from the connector's shape. If the server authenticates with OAuth, the connector supports passing an authorization_token in the server definition, so confirm auth compatibility before you commit to it. And availability is platform-dependent: the connector is gated behind a beta header and runs on the Claude API, Claude on AWS, and Microsoft Foundry, but not currently on Amazon Bedrock or Vertex AI. The platform you deploy on can therefore rule a community server in or out regardless of how good the server itself is.
The architectural point is that use is only the right call when the existing server is reachable and authenticable on your platform. When it is not, the decision quietly shifts back toward building, wrapping, or self-hosting a server that fits your transport and platform constraints, even for a system a public server already covers in principle.
The hidden cost of building is maintenance, not the build
The reason reuse is the default is easy to underweight, because the cost of building looks like a one-time expense and is actually a recurring one. Standing up a server is the visible part: a week or two of work to wrap an API and expose some tools. The invisible part is everything after. The upstream API changes and your server breaks. A new authentication requirement lands and you have to implement it. An edge case surfaces in production and you debug it alone, without the benefit of a community that has already hit and fixed the same thing. A maintained community server absorbs all of that on your behalf, and choosing to build means choosing to absorb it yourself, indefinitely.
This is why the build-versus-use question is really a question about where your engineering time is best spent. For a commodity integration, the honest comparison is not your custom server against no server; it is your custom server against a maintained one that already handles the cases you have not thought of yet. Framed that way, the bar for building has to be high, because you are not just paying to create the server, you are signing up to keep it alive.
The fork-and-extend middle path
Build and use are not the only two options; there is a productive middle path that the second question in the decision flow points at. When an existing server covers most of your need but not all of it, and its architecture is clean, you can adopt it and extend it rather than starting over. You inherit the part that already works, often the bulk of the integration, and add only the slice that is specific to you. The trade-off is real and worth stating plainly: extending a well-built server saves significant time, but extending a tangled one can cost more than a clean build, because you spend your effort untangling someone else's assumptions instead of writing your own. The judgment, then, is not only whether a close server exists but whether its design is sound enough to build on.
A rubric you can defend
Because this knowledge point is assessed at the evaluate level, it helps to have an explicit set of factors you can point to when justifying a choice. Weigh, in roughly this order: whether a maintained server exists for the system at all; how standard versus proprietary the target is; how clean an almost-fits server's architecture is if one exists; how much ongoing maintenance you are willing to own; and how unique the workflow genuinely is rather than how unique it feels. A choice that scores toward existing, standard, clean, low-maintenance-appetite, and not-actually-unique points firmly at use. A choice that scores toward no-server-exists, proprietary, and genuinely-unique-workflow points at build. The value of naming the factors is that it turns an instinct into an argument, which is exactly what an evaluate-level question asks you to produce.
Reuse compounds across a team
There is a multiplier effect that makes reuse even more attractive at organization scale. When a team standardizes on a maintained community server, every project that adopts it inherits the same battle-tested behavior, the same security fixes, and the same documentation, with no per-project rebuild. A custom server, by contrast, has to be maintained once but understood many times, because each new engineer who touches it must learn a bespoke integration that exists nowhere else and is documented nowhere public. Choosing the community option therefore does not just save the original build week; it lowers the ongoing cost of onboarding, review, and trust across everyone who will ever depend on the integration. That compounding is the quiet reason the default leans so hard toward use, and it is why a team that builds reflexively often finds the true cost only months later, when the person who wrote the server has moved on and the rest of the team is left maintaining something none of them chose.
Why it matters for the exam
A scenario for this knowledge point usually presents a team about to spend effort, and asks whether that effort is warranted. The healthy answer almost always pushes toward reuse: if a maintained server exists for the system in question, adopt it and spend the saved time on the parts that are genuinely yours. The build answer is correct only when the scenario establishes that the target is internal, proprietary, or workflow-specific with no existing coverage. Reading which of those situations you are in, and resisting the instinct to build by default, is the whole test.
Worked example
A platform team is setting up Claude Code agents for engineering. They need three integrations: GitHub for pull requests, Slack for notifications, and a connector to their in-house deployment system, which has a private REST API and exists nowhere else.
Take each integration through the decision rather than treating them as one block.
GitHub is the textbook use case. Maintained servers for GitHub already exist, handle authentication and pagination, and are kept current as the API evolves. Building one would duplicate solved work and saddle the team with maintenance, so the team adopts the community server, wires the token through a ${GITHUB_TOKEN} reference, and scopes it to the project so every engineer inherits it.
Slack is the same story. It is a commodity integration with established servers, so the team uses one rather than writing a Slack client from scratch. Two of the three integrations are now done with zero custom server code.
The in-house deployment system is where building is genuinely justified, and notice why: not because the team wants control, but because no off-the-shelf server can talk to a private API that only this company runs. Here a custom server earns its keep. The team builds it, then immediately invests in clear, specific tool descriptions so their agents reach for the deploy tool instead of falling back to shell commands. The lesson the exam wants is the contrast: two reuse decisions and exactly one build decision, with the build reserved for the integration that truly has no alternative.
Common misreadings to avoid
Misconception
Building a custom MCP server is the safer default because it gives the team full control over the integration.
What's actually true
Misconception
Once you decide to use a community server, the integration work is essentially finished.
What's actually true
How it shows up on the exam
A team needs their Claude Code agents to read and comment on GitHub pull requests. A senior engineer proposes spending the sprint building a custom GitHub MCP server so the team fully controls the code. What is the best evaluation of this proposal?
People also ask
Should I build a custom MCP server or use an existing one?
Are there community MCP servers for GitHub and Slack?
When is building a custom MCP server worth it?
Where do I find existing MCP servers?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
MCP clients
Why watch: Understanding how a client connects to and consumes MCP servers frames the build-versus-use decision for integrations.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.