A basic read only model context protocol (MCP) server built against one API runs in a few days. A production deployment takes months, covering authentication, user level permissions, audit logging, and integration with a security information and event management (SIEM) system. Salesforce, SAP, and Snowflake each need that work done again, which is where the build hours and governance overhead accumulate.
Security and ongoing maintenance account for most of that effort, so both should be factored into delivery estimates. For the strategic framing behind this decision, see our guide to the MCP build vs. buy choice.
What MCP server build hours and governance overhead actually include
MCP server build hours are the engineering time required to move one source system from a working prototype to a production MCP server, covering tool design, authorization, testing, and deployment. Governance overhead is the recurring work of authorizing, scoping, logging, reviewing, and re-approving every MCP server and tool, repeated for each new data source.
Governance is counted separately from build hours because the MCP specification makes authorization optional. The specification's security principles require explicit user consent and access controls on user data, and each implementation is responsible for how those controls are enforced. Teams must develop and maintain their own authentication and audit controls, making governance a separate cost in the project estimate.
Phase 1: Building your first production connector (4–6 months)
The first production connector can take an estimated four to six months to build. The additional time goes into making the connector secure and reliable. An HTTP MCP server using open authorization (OAuth) 2.1 must validate access tokens and confirm they were issued for that server.
Tool definitions also need security review because AI models rely on their descriptions, parameters, and schemas when calling tools. These definitions can introduce prompt injection risks, so approved versions should be tracked and monitored for unauthorized changes.
Build stage | What it covers | Typical DIY effort |
Read only prototype | One system, narrow tool set, no auth. | 24–40 engineering hours. |
OAuth 2.1 resource server | Token validation, audience checks, scope errors. | 80–160 engineering hours. |
Tool design and schema review | Descriptions, parameters, hash pinning. | 40–80 engineering hours. |
Testing, hardening, and deployment | Abuse cases, rate limits, rollout. | 120–200 engineering hours. |
These CData planning estimates apply to a single data source. Adding Salesforce, SAP, or Snowflake requires additional work to accommodate each system's APIs, authentication methods, and error handling, along with the security and operational requirements covered in CData's MCP server best practices guide.
Phase 2: Security, access control, and audit trails (another 2–3 months)
Security, access controls, and audit logging add an estimated two to three months to the four to six months required to build a connector. These CData planning estimates reflect the additional work needed for each data source, extending the overall project timeline across multiple quarters.
Passthrough authentication and RBAC
The MCP specification does not allow servers to reuse access tokens meant for other services. Each server must check that a token was issued for it and use separate credentials to connect to the data source. To keep the user's identity, the server needs a secure way to obtain a token for that source. Different data sources may require different authentication steps, adding to development time.
Each custom connector needs role-based access control (RBAC) to enforce least privilege, using credentials limited to the server, restricted OAuth permissions, and short-lived tokens. CData's guide to enterprise MCP security practices explains these requirements, while its comparison of managed and self-hosted MCP solutions covers how managed platforms handle security across data sources.
Audit logging, SIEM export, and workspace isolation
The Cloud Security Alliance (CSA) outlines four levels of MCP security maturity, starting with basic authentication and server inventory and progressing to authorization for every tool request and tamper resistant audit logs. The National Security Agency (NSA) AI Security Center has also warned that MCP adoption has moved faster than its security practices.
Teams building their own servers must implement these controls, connect security events to a SIEM system, and repeat the work for each server. CData's guide to securing MCP server configurations covers these requirements.
Phase 3: Ongoing maintenance, API changes, and token overhead
Maintenance costs come from changes to the underlying APIs and updates to the protocol each connector uses.
API drift, server outages, and internal server errors
Changes to source APIs can break existing connectors. For example, Salesforce retired API versions 21.0 through 30.0 in its Summer '25 release. Requests using these versions fail with HTTP 410 for REST and HTTP 500 for SOAP. Some connector failures may affect only specific objects, making them harder to detect without request level logging. A custom MCP server may also return a generic HTTP 500 error, leaving teams to investigate the underlying cause.
MCP itself continues to evolve. The July 28, 2026 specification introduced changes to stateless operation and authorization, requiring teams to review their implementations for compatibility. CData's guide to managing multiple MCP servers explains how this maintenance effort grows with each additional server.
The hidden token cost of per-source MCP servers
MCP tool definitions and responses consume tokens as agents interact with connected servers. Anthropic documented a workflow where token usage dropped from 150,000 to 2,000 after changing how tools were called. Similarly, CData Labs reported 93% fewer tokens to reach the same correct answer compared with an open-source MCP gateway, based on 810 runs across 27 models. These findings come from CData's own serving context to probabilistic agents benchmark, with a publicly available test setup for reproduction. CData also explains how Connect AI reduces tool call overhead.
DIY vs. managed MCP: total cost of ownership compared
Building in-house is a sound choice when one application requires access to one stable API. The total cost of ownership (TCO) picture changes at several sources and several AI clients, because the governance work grows with each one. Credentials and scopes multiply with the server count, since tokens can't be shared across servers, and every DIY server must reach those maturity levels independently.
Cost dimension | DIY MCP (per source) | Managed MCP |
Connector build | Rebuilt for each source's API and auth flow. | Pre-built connections configured per source. |
Passthrough auth and RBAC | Rebuilt and re-reviewed for each connector. | Configured once across all sources. |
Audit logging and SIEM export | Wired into the SIEM per server. | One audit stream across every connection. |
API upkeep | Rework on every upstream version change. | Handled by the platform. |
Protocol updates | Each server revalidated per spec release. | Handled in the managed layer. |
For annual maintenance, organizations can use 15% to 30% of the initial build cost as a rough budgeting estimate, although this is a general planning assumption rather than a verified industry benchmark. Our guide to maximizing MCP ROI covers the KPIs that make that number visible.
Skip the build backlog with CData Connect AI
CData Connect AI provides a governed MCP interface to Salesforce, SAP, Snowflake, and hundreds of other data sources. It supports identity passthrough and least privilege access controls, reducing the need to implement authentication and permissions separately for each connector.
Connect AI is also available as a certified connector in Claude, and CData's partnerships with Microsoft and Databricks support its enterprise AI ecosystem.
You can connect your enterprise data through Connect AI to evaluate the setup and maintenance effort compared with building MCP connectors internally. A free trial is available to test these capabilities with existing data sources.
Frequently asked questions
What is MCP server governance overhead, and why does it matter for enterprise deployments?
It's the recurring work of authorizing, scoping, logging, reviewing, and re-approving every MCP server and tool. It matters because the protocol leaves those controls to each implementation, so the work lands on the team and repeats for every data source.
How many engineering hours does it actually take to build a production-ready MCP server?
Plan on roughly 80 to 160 hours for a single system server, against 24 to 40 for a read only prototype. These are planning estimates and shift with the source API.
Why does a working proof of concept take days but a production MCP server take months?
Because a prototype calls one API with one credential. A production server validates every inbound token, enforces per user permissions, logs each call to the SIEM, and passes a security review first.
What hidden costs should a CIO or budget owner include in an MCP server TCO estimate?
The recurring ones: credential rotation, re-review of tool definitions after each change, revalidation after MCP spec releases, rework when an upstream API version retires, and the token cost of loading tool definitions into the model's context on every request.
Does the MCP protocol handle enterprise security, authentication, and audit trails?
No. The specification makes authorization optional and leaves consent, access controls, and audit logging to implementers.
How much ongoing maintenance effort should teams budget for after an MCP server goes live?
Roughly 15% to 30% of the initial build cost per year is a reasonable planning range, covering API drift, dependency updates, credential rotation, and protocol revisions.
When does building a custom MCP server make sense versus using a managed alternative?
When one application needs one stable API, or when the connector itself is the product. A managed platform fits better once several sources, and several AI clients are in scope.
