When to Build Your Own MCP Server vs. Use a Vendor's

This test decides most cases on its own. Map every field the server's tools would read or write, then ask whether the vendor's service, or its subprocessors, could see it. Cyberhaven's research found that 39.7 percent of all AI interactions involved sensitive data across prompts, pastes and uploads, and that employees input sensitive data into AI tools roughly once every three days the Cyberhaven report. That is the baseline you are trying to improve on, not a reason to give up on vendors.

Vendor terms are readable, and reading them is the test. OpenAI's enterprise privacy page states that business data is not used for training by default on its business and API products, that customers own inputs and outputs, and that data is encrypted at rest and in transit OpenAI enterprise privacy. It also states that business data may be run through automated content classifiers and safety tools OpenAI enterprise privacy. If your data cannot pass a classifier or be subject to retention for abuse monitoring, that is a signal to keep it inside a server you run.

The distinction worth internalizing is training versus inference versus retention. A business tier can disable training on your data and still retain content for a window for abuse monitoring, which is why reviewers now ask vendors for retention in days and named subprocessors rather than accepting a no-training claim Parseur's vendor questions. That page also reports that 63.6 percent of vendors advertising AI capabilities do not disclose a third-party AI subprocessor anywhere in their legal documentation Parseur's vendor questions. Ask for the subprocessor list before you sign, and if the answer is vague, that is your answer.

Then look upstream of the server. A connected agent surfaces whatever permissions already exist in your SaaS estate, so the leak often sits in overshared files and stale access rather than in the tool itself Metomic on AI data risk. Cyberhaven's data is a good argument for a policy that names banned data classes, which is exactly what workplace AI checklists recommend: Social Security numbers, payroll, medical records, customer data, credentials and confidential strategy the CTR AI policy checklist.

Decision rule: if the answer to "can the vendor or its subprocessors see this data" is yes and you cannot contract away retention and human review, build, or route the sensitive path through a server that runs in your own environment. A privacy proxy that scrubs identifiers before the request leaves your network is the middle path when only some fields are sensitive the Tiamat privacy proxy writeup.

Count the tools, not the systems. A server that wraps one internal API with two tools is a small build. A server that fans out to eleven SaaS products with forty tools is a product, and vendor servers exist precisely because someone has already maintained that fan-out, including the per-tool pagination, retries and error shapes that nobody budgets for. The CSA paper describes this ecosystem effect directly: hundreds of maintained and community servers exist for systems including GitHub, Slack, Google Drive, Jira, Salesforce and AWS the CSA MCP security guide.

Integration economics follow the same curve. The Exalate build-versus-buy analysis makes the point that initial development is typically only 30 to 40 percent of the total cost of ownership for a custom integration, with maintenance consuming the rest the Exalate integration guide. A broader review of build versus buy adds that pure builds are now rare and reserved for regulated workloads, customer-facing differentiators and deep integrations, while most purchased software gets extended rather than used raw the Zylo build vs buy guide. Both support the same rule for MCP: buy the breadth, build the depth.

A useful sizing calculation. Take the tool count T, the number of upstream APIs A, and the expected change events per quarter C. If T is above roughly ten and A is above three, assume the build carries one full-time maintainer fraction, then compare a year of that fraction against the license plus integration effort. If T is two, A is one, and C is near zero, the build is likely a few days of work. Run the numbers on your own list rather than arguing by instinct.

There is a hybrid that fits most enterprises better than either pure option: buy a general server for common read paths and build a narrow server for your own systems, then expose both to the same host. Keep the custom server's scope list short and explicit, because that is the surface a reviewer will ask about. A strong starting point is to permit read scopes broadly and require write scopes only for the tools your agents actually need, following the resource:action pattern that maps one scope to one tool Casdoor MCP authorization.

Change frequency is the most underweighted input. If your product's API changes every sprint, a vendor's server for an unrelated product will not help, and a generic connector will lag your schema. If the integration is a stable standard like a ticketing system or a document store, the vendor absorbs change for you. The CSA guide notes that MCP adoption outran security governance, with more than 30 CVEs filed against MCP servers, clients and infrastructure between January and February 2026, and roughly half of nearly 7,000 internet-exposed MCP servers running without authentication controls the CSA MCP security guide. Change is not only schema drift. It is also patching.

Apply that to your own server: every tool you expose is a patch obligation. If you build, plan for dependency upgrades, transport changes and auth-flow changes in the spec that lands on you, since the spec now formalizes OAuth 2.1 for remote servers and requires metadata endpoints that clients rely on the CSA MCP security guide. An implementation walkthrough of the required pieces names them plainly: register the server, publish protected resource metadata, validate JWT tokens, verify scopes on every call the Scalekit OAuth guide. Those are four moving parts that exist whether or not you enjoy them.

Decision rule: if you expect more than a few tool changes per quarter, either build with an owner who treats it as a product, or buy a server whose extension layer lets you add your own tools without forking. A bought platform that you configure is the fit Zylo calls buy-and-extend, and it is the honest description of what most teams should aim for the Zylo guide.

The last test is the one finance usually wins. Put a number on your own server: hours to build, hours per month to maintain, and the loaded cost of the person who answers the page at 2 a.m. Then add the cost of a security review, because an MCP server touching internal systems is a new externally reachable surface. Red Hat's treatment of MCP auth frames the server as an OAuth resource server, which means it inherits the operational discipline of any internet-facing service you run Red Hat on MCP security. If your team has no runbook for that, the build is not finished when it works on your laptop.

A worked example with round numbers. Suppose the build takes 60 engineer hours and the ongoing load is 8 hours a month for maintenance plus incident response, against a loaded rate of 100 dollars an hour. That is roughly 6,000 dollars up front and about 9,600 dollars a year, before you count review time. If a vendor subscription plus integration time lands below the annual figure, and the data test passed, buying is the cheaper choice. If the data test failed, the comparison is irrelevant and you build regardless. Keep the loaded rate honest and include the review, because the security whitepaper's finding that half of exposed MCP servers had no authentication is a fair warning about what happens when review is skipped the CSA MCP security guide.

Also account for the identity layer. If your organization already runs an identity provider, scopes and token validation are a standing capability you can reuse across many servers, which lowers the marginal cost of building the second and third custom server. Solo teams without that capability should weight the vendor's auth work more heavily, because the four required pieces are not optional for remote servers the Scalekit OAuth guide.

Write the decision as a one-page record with the four test results, the numbers and a named owner. Reviewers accept a record far faster than an architecture discussion, and you will want it when someone asks why one server is custom and another is bought. A short template keeps it consistent across teams.

Server: <name and purpose>
Tools: <count>, write tools: <count>
Data classes touched: <list>, vendor-visible: yes/no
Subprocessors and retention: <vendor answer in days>
Change cadence: <tool changes per quarter>
Build estimate: <hours> + <review hours>
Annual own cost: <maintenance hours x loaded rate>
Annual buy cost: <license + integration hours x rate>
Decision: build | buy | buy and extend
Owner and review date: <name>, <date>

Two guardrails before you ship either option. First, restrict what the agent can do before restricting what it can see, because a read-only server with broad read scopes is a much smaller problem than a server with one delete tool. Scope-based tool access, where a token's scopes determine which tools tools/list returns and which calls succeed, is the mechanism the Casdoor documentation uses and it maps cleanly onto your own design Casdoor MCP authorization. Second, publish the tool list and the data classes to the people who write your AI policy, since those are the facts the policy needs to say anything useful about approved tools and prohibited data the CTR AI policy checklist.

One caution from the legal side. Terms of use for consumer interfaces often grant the provider rights to use input to improve services, and liability can be capped at trivial amounts, which enterprises only avoid by using business or API tiers under a data processing addendum Norton Rose Fulbright on ChatGPT risk. Whatever you decide, the server's traffic should land on a business tier with a signed agreement, not a personal login that bypasses SSO and logging. Cyberhaven found 32.3 percent of ChatGPT usage and 58.2 percent of Claude usage happened through personal accounts, which is the exact blind spot a single approved path is meant to close the Cyberhaven report.

If the decision is to keep sensitive paths in-house while still calling many models through one interface, a gateway plus a narrow custom server is usually enough. Quanta Inference exposes text, image, video, audio and embedding models behind one OpenAI-compatible API key, which keeps the model side of that architecture simple Quanta Inference. The server decision stays yours, and so does the review.