MCP Server Development: Cost, Architecture & Security (2026)

MCP server development in 2026 means putting a small, well-guarded layer in front of your product so AI agents like Claude and ChatGPT can call it as tools. A read-only public server over data you already have is one to two engineer-weeks; an authenticated server over customer data takes three to six weeks; a server that writes data in a regulated product takes three to six months. Most of that time goes on authorization, scoping and audit, not the protocol. This guide covers the architecture, the costs and a 20-point security checklist, using the three MCP servers BeevR runs in production as the worked example. Updated October 2026.

What is an MCP server, and when does a product need one?

An MCP server exposes your product's capabilities as tools that any client speaking the Model Context Protocol can discover and call. These include Claude, ChatGPT connectors, IDE agents and agent frameworks. You write the integration once and every compliant client can use it. Before MCP, each client needed its own plugin. An MCP server is not a new backend. It is a thin adapter that sits on top of your API, with its own authorization and its own audit trail.

You need one when customers or partners want to reach your product from an AI assistant. Typical requests are "summarise my account," "check whether this facility must report emissions" or "pull last quarter's numbers into my analysis." You also need one when you want AI engines to answer questions about your company from your own data instead of whatever they remember from training. You probably do not need one yet if no customer has asked, your API is unstable, or your data model is still changing every week. Fix the API first, because the MCP layer depends on it.

What changed in the MCP specification in 2026?

The current MCP revision is 2026-07-28, and it changes how servers are built. The biggest change is that MCP is now stateless. The initialize handshake and the Mcp-Session-Id header are gone. Every request carries its own protocol version and client capabilities in _meta, and servers must implement a new server/discover method that advertises their supported versions. Servers that need state across calls now mint explicit handles and receive them back as ordinary tool arguments. ping is removed, and Roots, Sampling and Logging are deprecated.

Authorization changed too. OAuth 2.0 Dynamic Client Registration (RFC 7591) is deprecated in favour of OAuth Client ID Metadata Documents, though it stays available for backwards compatibility. Clients must now validate the iss parameter in authorization responses to block mix-up attacks. The core rules did not change:

• A protected MCP server is an OAuth 2.1 resource server.
• It must publish OAuth 2.0 Protected Resource Metadata (RFC 9728).
• It must validate that every token was issued for it.
• It must never pass client tokens through to downstream APIs.

Separately, in June 2026 the MCP project declared the Enterprise-Managed Authorization extension stable. It lets a company's identity provider (Okta at launch) grant and revoke MCP access centrally, so users don't have to click through OAuth for every server. If you sell to enterprises, plan for it.

In practice, a server built in 2025 or early 2026 against the handshake-based revisions (2025-06-18, 2025-11-25) still works with clients that support those revisions. A new server should target 2026-07-28. Our own public servers still negotiate 2025-06-18 or 2025-11-25 today, so they are a good example of the migration most teams now face.

What does a production MCP server architecture look like?

Every production MCP server has five layers, whatever the stack. Here they are from the outside in:

1. Discovery. A server card at /.well-known/mcp/server-card.json lists the endpoint, transport, auth requirement and tools. Protected servers also publish their protected-resource metadata and authorization-server metadata.
2. Transport and protocol. Streamable HTTP with JSON-RPC 2.0. In practice this means an HTTPS endpoint that accepts POST and validates the message envelope.
3. Authorization. For anything beyond public data: token validation (issuer, audience or client, expiry, scope), then a per-request policy check.
4. Tools. A small, curated set of tools with strict input schemas and short, factual descriptions. Each tool calls your existing API or data layer. None of them get raw database access.
5. Observability and limits. Rate limits per user or client, an audit line per agent request, and alerts on denied calls.

BeevR runs three MCP servers built this way, and you can connect to the two public ones right now:

To see the protocol for yourself, list the tools on our public server:

curl -s https://beevr.ai/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Or add https://beevr.ai/mcp as a custom connector in an MCP-capable assistant and ask it what BeevR's fixed-price packages are. The answer will come from get_pricing, not from model memory.

If you build agents yourself, the same tool boundary applies on the client side. Kite, our open-source agent framework, ships MCP integrations (Slack, Gmail, Google Drive, PostgreSQL, Stripe), and every tool call an agent proposes goes through a kernel that checks it against an allowlist, a budget and a policy before it runs.

How does an OAuth-protected MCP server work in practice?

The EcoCheck account server shows the full flow, and every step is published so you can check it:

• Challenge. An unauthenticated POST to /mcp/account returns 401 with WWW-Authenticate: Bearer resource_metadata="…/.well-known/oauth-protected-resource/mcp/account", scope="ecocheck/read". That header is how the client learns where to authorize and which scope to ask for.
• Protected-resource metadata (RFC 9728) names the authorization server, the supported scopes, bearer-in-header only, and the token issuer.
• Authorization-server metadata (RFC 8414) at /.well-known/oauth-authorization-server fronts AWS Cognito. It advertises the authorization code grant only, S256 as the only PKCE method, public clients (token_endpoint_auth_method: none) and a revocation endpoint.
• Client registration (RFC 7591) is a thin facade at /oauth/register. It accepts only an allowlist of redirect URIs (Claude, ChatGPT and the local MCP Inspector) and returns a public client ID. Agents never create customer accounts.
• Tokens are Cognito-issued JWTs. Access tokens last 60 minutes, refresh tokens 7 days, and revocation is supported.
• Enforcement happens in the APIs, not just the MCP layer. The backend recognises tokens issued to the dedicated agent client. For those tokens it requires the ecocheck/read scope and allows only GET/HEAD requests on an allowlist of routes. Member lists, evidence files and exports return 403. The customer's existing workspace and organisation membership checks still apply, because the agent acts as that customer.
• Limits and audit. Agent requests are rate-limited per user (120 a minute by default), and every agent request writes an audit line recording who, method, path and whether it was allowed.

Two design choices matter more than the rest. First, the read-only rule lives in the API that owns the data, so a bug in the MCP adapter cannot widen access. Second, the token is the customer's own, so the agent can never see more than the customer could see in the app. Our EcoCheck team explains the customer-facing side in its MCP connection guide (in Vietnamese).

There is also a 2026 update to make: this server registers clients through Dynamic Client Registration, which the 2026-07-28 spec now deprecates in favour of Client ID Metadata Documents. It is still allowed for backwards compatibility, but a new build should support Client ID Metadata Documents from the start.

How much does MCP server development cost in 2026?

Cost is driven by three questions: whose data the server exposes, whether agents can change anything, and which compliance regime applies. The protocol layer itself is a few hundred lines. The table converts effort into money at two published rate bands: the senior Asia rate of $31–$41 an hour from our 2026 Vietnam rates guide, and the $100–$300 an hour typical of US mid-market firms.

The effort ranges are our planning estimates, not quotes. They assume a team that already knows OAuth and the API behind the server, and they exclude external audit or pen-test fees. Running costs are usually small, because a stateless MCP server is a light HTTP function. The real cost sits in the API calls and model usage the agent triggers on your side. For context on the agent side of the bill, see what an AI agent costs to build and run.

What are the biggest MCP security risks?

The risks fall into three groups: what the model reads, who the server trusts, and what you can prove after the fact. The OWASP MCP Top 10, currently in beta, is the most useful map of them. It lists, in order:

1. Token mismanagement and secret exposure
2. Privilege escalation via scope creep
3. Tool poisoning
4. Software supply chain attacks and dependency tampering
5. Command injection and execution
6. Prompt injection via contextual payloads
7. Insufficient authentication and authorization
8. Lack of audit and telemetry
9. Shadow MCP servers
10. Context injection and over-sharing

Three findings show why these are not theoretical:

• Tool poisoning works. The MCPTox benchmark planted malicious instructions in tool descriptions across 45 live MCP servers and 353 real tools. The attacks succeeded 36.5% of the time on average, and up to 72.8% against the most vulnerable model. More capable models were often more susceptible, not less.
• The supply chain is part of your attack surface. In April 2026, OX Security disclosed a design-level command-execution issue in how MCP's official SDKs launch local STDIO servers. It reported more than 30 responsible disclosures and 10+ high or critical CVEs across the ecosystem. Remote HTTP servers avoid that particular path, but your clients and developer machines may not.
• Agents read tool descriptions as instructions. A description is text that lands in the model's context. Treat it like code: review it, version it, and never generate it from user-supplied data.

For the wider governance picture (who may connect which agent to what, and how spend is capped), see our guide to AI agent governance.

What should an MCP server security checklist include?

This is the 20-point list we hold our own servers to. Items marked with an asterisk are what the 2026-07-28 spec requires or strongly recommends.

Authorization

• OAuth 2.1 authorization code flow with PKCE, S256 only, for any non-public data.*
• Protected Resource Metadata (RFC 9728) published, and a 401 with WWW-Authenticate that carries resource_metadata and the required scope.*
• Authorization-server metadata (RFC 8414 or OpenID Connect Discovery) reachable from that document.*
• Tokens validated for issuer, expiry, scope and intended audience or client. Tokens issued for anything else are rejected.*
• No token passthrough: the server never forwards the client's token to a third-party API.*
• Client ID Metadata Documents supported for new builds. Dynamic Client Registration only for compatibility, and only with an exact-match redirect URI allowlist.*
• Short-lived access tokens (we use 60 minutes) and a working revocation path.

Least privilege

• Minimal default scope, with privileged operations behind a step-up insufficient_scope challenge.*
• Read-only enforced in the API that owns the data, not only in the MCP adapter.
• The agent acts as the user: existing tenant, organisation and role checks still run on every call.
• No member lists, secrets, raw files or bulk exports unless a named use case needs them.

Tools

• Every tool input validated against a strict schema, and every output sanitised.*
• Tool descriptions reviewed like code, kept in version control and diffed on every release (tool-poisoning defence).
• Tools returned in a deterministic order, and tool names unique and stable.*
• Consequential actions (payments, deletes, outbound messages) require explicit user confirmation and an idempotency key.

Operations

• Rate limits per user and per client (ours: 120 agent requests a minute per user by default).*
• One audit line per agent request: subject, client, tool or route, decision, timestamp.
• Alerts on spikes in denied calls or unknown clients, and a kill switch that disables agent access without a deploy.
• Dependencies pinned and scanned, and no STDIO launch of servers from untrusted configuration.
• A server card, a human-readable auth document and a privacy policy published, so security reviewers can assess you without a call.

Before launch, run the server against the MCP Inspector and at least two real clients. Then repeat the denied-path tests from the checklist: wrong scope, expired token, another tenant's ID, write method, oversized input.

Should you build your own MCP server or use a hosted platform?

Build it yourself when the data is yours, sensitive or regulated, because the authorization logic has to live next to the data. Hosted MCP gateways are a good fit for exposing third-party SaaS tools inside your company, or for prototypes. For a customer-facing server over your own product, the gateway still needs your API to enforce scope, tenancy and audit, and that is most of the work anyway. Whichever you choose, the agent around the server needs the same production discipline as any agent: see taking AI agents from pilot to production.

FAQ

How long does it take to build an MCP server?

A public, read-only MCP server over data you already serve takes one to two senior engineer-weeks, including tests and a server card. An OAuth-protected, read-only server over customer data takes three to six weeks. Read-write or regulated servers take longer because of scoping, confirmations and security testing.

Does an MCP server need OAuth?

Not for public data. Our beevr.ai and ecocheck.ai public servers need no credentials. For anything user-specific, yes: the MCP spec defines OAuth 2.1 with PKCE, with the server acting as a resource server that publishes RFC 9728 metadata. Never put API keys or passwords into an agent conversation.

Is Dynamic Client Registration still allowed in MCP?

Yes, but it is deprecated as of the 2026-07-28 revision. Client ID Metadata Documents are now the recommended way for clients to identify themselves. DCR remains for authorization servers that don't support them yet. If you keep DCR, restrict redirect URIs to an exact-match allowlist.

What is MCP tool poisoning?

Tool poisoning is when malicious instructions are hidden in a tool's description or output, and the model follows them, for example by sending data to an attacker. In the MCPTox benchmark it succeeded 36.5% of the time on average. Defences are reviewed and versioned descriptions, strict outputs, least-privilege scopes and user confirmation for consequential actions.

Can an MCP server be HIPAA or PCI compliant?

The server can be designed to fit inside a compliant system, but compliance belongs to the whole system, not the protocol. Keep PHI or card data out of tool outputs unless the model endpoint is covered by the right agreements, log every access, and scope the server into your risk analysis. Our HIPAA-compliant AI agents guide covers the healthcare side.

BeevR builds production MCP servers and the agents that call them for regulated products, with a fixed price per phase and full code ownership from day one. You can connect to our public server at https://beevr.ai/mcp right now. To make your own product agent-ready, see our AI agent development work or tell us what you want agents to do with your product.