Build vs Buy: Should You Write Your Own MCP Integrations?
Build an MCP integration when the system is internal or specific to you, since no catalog will have it. Buy, meaning use a maintained catalog of integrations, for mainstream apps such as GitHub, Slack, or Salesforce, where the work is OAuth, upkeep, and governance rather than the tool code. A common split is to buy the standard apps and build the internal ones, under the same access control and logging.
A Model Context Protocol (MCP) integration is a server that exposes one system's actions as tools a model can call. The first version takes little time. The decision is about everything that comes after it.
What does building an integration involve?
The tool code is the visible part: a name, a description, an input schema, and a call to the upstream API. The specification then adds obligations. For tools, it says servers must validate all inputs, implement access controls, rate limit invocations, and sanitize outputs. Authorization is optional in the protocol, but when a server on an HTTP transport supports it, the specification defines a flow based on OAuth (the consent flow apps use to grant access) with discovery metadata, which you implement and test against real clients.
Then there is per-user access. If the agent should act as the person it works for, you need OAuth per user, which means you need to store each person's tokens, refresh them, and keep one user's from reaching another's. A shared service account is simpler to build, and it means every action is taken as the same identity. The custom route is covered in how to build and host a custom MCP server.
Maintenance is the last cost, and it does not stop. The specification is versioned by date and keeps changing. Its current authorization section, for example, marks Dynamic Client Registration as deprecated and retained for backwards compatibility. The upstream API changes on its own schedule too.
What does buying an integration involve?
Buying means using integrations someone else builds and maintains, usually in a catalog behind a gateway. You skip the tool code, the OAuth plumbing for that app, and the upkeep. In exchange you accept the vendor's choice of tools and their release pace, and you depend on them to cover the actions you need.
A catalog is only a good buy when the app is standard. Nobody's catalog will contain your internal billing service.
How do they compare?
| Criteria | Build | Buy |
|---|---|---|
| Time to a working tool | Fast for the first one, slower with each added app | Connect an existing integration |
| Per-user OAuth and refresh | You write and run it | Handled by the platform |
| Control over tool behavior | Complete | Limited to what the vendor exposes |
| Keeping up with API and protocol changes | Your team, continuously | The vendor |
| Permissions and logging | You add them per server | Shared across all integrations |
| Systems it can reach | Anything you can write code against | What the catalog covers |
| Who owns it long term | A named engineer, which is a risk if they leave | The vendor |
When is building the right choice?
When the system is yours. Internal APIs, proprietary databases, and company-specific business logic have no catalog entry, and the tools should reflect your own vocabulary anyway. Build also wins when exact behavior matters more than speed: a tool that must return a particular shape, or refuse certain inputs.
It also wins at small scale. One developer, one fixed integration, and no plan to add more is a case where a platform is machinery you do not yet need. Write the server with the official software development kit (SDK) and move on.
When is buying the right choice?
When the app is common and the number of apps will grow. Each integration you build adds its own OAuth flow, its own logging, and its own upgrades, so the work grows with the number of apps. Buying also fits when non-engineers will use the tools, since they cannot be sent through a config file.
What does it look like in Metorial?
Metorial covers both paths on one platform. The buy path is a catalog of 1,000+ integrations, which Metorial states are tested with agents such as Claude, Codex, and Cursor. Each provider is version-controlled, so a deployment can be pinned to a version, and alerts can be set for schema changes.
The build path is custom providers: upload TypeScript or JavaScript code for Node.js, and Metorial builds, hosts, and versions it, with rollback to any earlier version. Custom MCP can also deploy from GitHub, GitLab, Azure DevOps, or Bitbucket. Docker-based servers and remote servers a vendor already runs can be connected too. All of these appear as providers under the same access control, and Tracing records each call. Custom integrations are available on every plan, including the free Dev plan.
Where it does not fit: custom providers run TypeScript or JavaScript on Node.js, so a server in another language has to go through Docker or run elsewhere as a remote server. And if you need one integration with no governance requirements, writing it directly may be less work than adopting a platform. For the wider picture of registries and where servers come from, see what is an MCP registry.
Frequently asked questions
How hard is it to build an MCP server?
A server that wraps one API with a single static key is small. The effort is in what surrounds it: per-user OAuth with token refresh, tool descriptions a model uses correctly, permissions, logs, and keeping up with changes to the protocol and the upstream API.
What does the MCP specification require of a server I build?
The tools section says servers must validate all tool inputs, implement access controls, rate limit tool invocations, and sanitize tool outputs. Authorization is optional in the protocol, but servers that use an HTTP-based transport and want it should follow the OAuth-based flow it defines.
Is there an option besides building or buying?
Yes. Some vendors, such as Linear, Sentry, Atlassian, and Microsoft, run their own MCP servers. You connect to those instead of writing or buying an integration. Metorial supports linking a remote MCP server and applies its access control and tracing to it.
Can I build some integrations and buy others?
Yes, and that is the usual outcome. Standard SaaS apps come from a catalog and internal systems are built as custom servers. On Metorial both kinds are providers that go through the same access control and tracing.
What happens when the upstream API or the protocol changes?
If you built the integration, you update it. If you bought it, the vendor does. On Metorial each provider is version-controlled, a deployment can be pinned to a specific version, and alerts can be configured for schema changes.