MCP server development means building a service that exposes your systems as tools, resources and prompts that AI clients such as Claude, ChatGPT and coding agents can use through the Model Context Protocol. A focused server for one system takes about 240 to 480 engineering hours, which is roughly $9,600 to $19,200 at $40 an hour, and most of that effort goes into authorization, permission scoping and testing rather than the protocol itself.
The protocol changed in a big way on 28 July 2026. The new specification removed sessions and the initialization handshake, moved long-running tasks into an extension and deprecated several features that older tutorials still teach.
This guide follows the current specification. It covers what a server exposes, how transports and OAuth work, how to scope permissions, where to host, a worked CRM example with the hours shown, and when an off-the-shelf server is the better buy.
Key Takeaways
- An MCP server exposes three things: tools the model can call, resources the application can read and prompts the user can pick. Most business servers are mostly tools.
- The 2026-07-28 specification is stateless: no sessions, no
initializehandshake, and every request carries its own protocol version. Servers built on older tutorials need updating. - Remote servers use OAuth 2.1 with strict audience rules: servers must publish Protected Resource Metadata, accept only tokens issued for them and never pass tokens through to other APIs.
- Permission design is the real work: separate read and write scopes, return only the tools a caller's scopes allow, and require confirmation for anything destructive.
- Check for an official server first: GitHub, Salesforce and Microsoft SQL already ship maintained servers. Build custom when your logic, data or permissions are unique.
What Is MCP Server Development?
The Model Context Protocol specification defines three roles. A host is the AI application, such as Claude or an IDE. A client is the connector inside that host. A server is the service you build, which offers context and capabilities to any client that speaks the protocol.
Messages use JSON-RPC 2.0. Because the format is standard, one server can serve several AI clients at once: Claude, ChatGPT, an internal agent built on an SDK, and developer tools.
That is the business case for MCP server development. You write the integration once, with your permission model built in, instead of rebuilding it for every AI product your teams adopt.
An MCP server is not a replacement for your API. It usually sits in front of an existing API or database and translates it into a small set of well-described actions that a model can choose between safely.
What an MCP Server Exposes: Tools, Resources and Prompts
The specification defines three server features. Each one has a different owner, and that difference shapes your security design.
| Feature | Who decides when it is used | What it is for | Methods | CRM example |
|---|---|---|---|---|
| Tools | The model, with a human able to deny | Functions the AI can execute | tools/list, tools/call |
update_deal_stage |
| Resources | The host application | Data that gives the model context, identified by URI | resources/list, resources/read, resources/templates/list |
crm://accounts/{id}/summary |
| Prompts | The user | Templated messages and workflows | prompts/list, prompts/get |
"Prepare an account brief" |
Tools
Tools are model-controlled: the model discovers them and decides when to call them. Each tool has a name, a description, an inputSchema in JSON Schema and an optional outputSchema for structured results.
The specification says there should always be a human in the loop who can deny a tool call, and that clients must treat tool annotations as untrusted unless they come from a trusted server. Servers must validate every input, enforce access controls, rate limit calls and sanitize outputs.
Resources
Resources are application-driven. The host decides how to include them, for example through a picker or automatic context. Resource templates use URI templates, so one definition can cover every account record.
Prompts
Prompts are reusable templates that users choose, such as "summarise this pipeline for my weekly review". They are cheap to build and they make a server easier to adopt, because users do not have to guess how to ask.
What Changed in the 2026-07-28 Specification
Most ranking guides still describe the 2025 versions. The 2026-07-28 changelog lists changes that affect how you build and host a server:
| Change | What it means for your build |
|---|---|
Protocol-level sessions and the Mcp-Session-Id header removed |
Any server can answer any request, so load balancing and serverless hosting get simpler |
initialize handshake removed; each request carries version and capabilities in _meta |
No connection setup state to manage |
New server/discover method that servers must implement |
Clients can check supported versions up front |
| Cross-call state uses server-minted handles passed as tool arguments | You must bind each handle to the authenticated user |
| Multi Round-Trip Requests replace server-initiated requests | A tool can return input_required and the client retries with the answers |
| Tasks moved into an official extension | Long-running jobs poll with tasks/get |
| Roots, Sampling and Logging deprecated; HTTP+SSE transport deprecated | Do not add them to new servers |
| Dynamic Client Registration deprecated in favour of Client ID Metadata Documents | Plan your OAuth setup around CIMD |
One more detail saves money. The specification now says servers should return tools in a deterministic order, which improves prompt cache hit rates when tool definitions sit in model context. Tool definitions are billed as input tokens on every call, so a stable order and fewer, clearer tools both lower the running cost of every agent that uses your server.
Transports: stdio or Streamable HTTP?
The specification defines two standard transports. Your choice depends on who runs the server and where.
| stdio | Streamable HTTP | |
|---|---|---|
| How it works | The client launches the server as a subprocess and exchanges newline-delimited JSON-RPC over standard input and output | Each message is an HTTP POST to one endpoint; replies come back as JSON or a request-scoped SSE stream |
| Best for | Local developer tools, desktop apps, single-user utilities | Shared servers for teams, SaaS products, ChatGPT and Claude connectors |
| Credentials | Read from the environment, not OAuth | OAuth 2.1 bearer token on every request |
| Scaling | One process per user | Horizontal, now easier because the protocol is stateless |
Remote clients need a public HTTPS endpoint. Anthropic's help centre says Claude connects to custom connectors from Anthropic's cloud, not from the user's device, so a server on a private network needs a firewall allowlist. Custom connectors are available on Free, Pro, Max, Team and Enterprise plans, with Free limited to one. OpenAI's developer documentation likewise describes how to build an MCP server for ChatGPT and Codex, with review requirements for public listing.
So a custom MCP server for Claude and a custom MCP server for ChatGPT can be the same server. The differences sit in how each product lists, reviews and authenticates it.
Authentication and Authorization: OAuth 2.1 the MCP Way
Authorization is optional in the protocol, but any server that touches business data needs it. For HTTP transports, the specification builds on OAuth 2.1 and a set of related standards.
The flow in plain terms:
- The client calls your server without a token and gets an HTTP 401 with a
WWW-Authenticateheader pointing to your Protected Resource Metadata (RFC 9728). - The client reads that metadata, finds your authorization server and fetches its metadata.
- The client registers, preferably with a Client ID Metadata Document, then starts an authorization code flow with PKCE and a
resourceparameter naming your server (RFC 8707). - The user signs in and approves. The client validates the issuer (RFC 9207) and exchanges the code for a token.
- Every later request carries
Authorization: Bearer <token>. Your server validates that the token was issued for it, and rejects anything else.
Three rules catch most teams out:
- Audience binding. Servers must validate that each token was issued specifically for them, and must not accept or forward any other token.
- No token passthrough. The security best practices call passing a client's token straight to a downstream API an anti-pattern that breaks audit trails and enables confused deputy attacks. Your server should hold its own credentials for downstream systems.
- Step-up scopes. When a caller lacks a scope, return HTTP 403 with
error="insufficient_scope"and the scopes needed, all in one challenge. The client can then ask the user for more access instead of failing.
If your company already runs Microsoft Entra ID, Okta or another identity provider, it usually acts as the authorization server. The MCP server becomes a resource server that checks tokens and maps scopes to tools.
Permission Scoping and Security Review
A model will call whatever tools it can see, including when a malicious document tells it to. Prompt injection sits at the top of the OWASP Top 10 for LLM applications, and an MCP server is exactly where injected instructions turn into real actions. Pixel's guide to AI agent security covers the wider control stack; the checklist below is specific to servers.
MCP server security review checklist:
- Separate read scopes from write scopes, and keep the starting scope set small.
- Return only the tools and resources the caller's scopes allow. The specification explicitly lets
tools/listvary by the authorization on the request. - Mark destructive tools clearly and require a human confirmation step in the client.
- Validate every argument against the schema and against business rules (amount limits, allowed record types).
- Bind every state handle to the authenticated user; never treat possession of a handle as proof of identity.
- Hold downstream credentials server-side, never in tool arguments or
x-mcp-headervalues. - Rate limit per user and per tool, and cap result sizes so one call cannot flood the model's context.
- Sanitize tool outputs and strip instructions from retrieved text where possible.
- Log every call with the user, tool, arguments and result status.
- Test with adversarial prompts and poisoned documents before launch.
- For local servers, prefer stdio, and never leave an unauthenticated HTTP server listening on localhost.
Hosting Options for an MCP Server
The stateless specification widens your options, because no request depends on which instance handled the last one.
| Option | Fits | Watch out for |
|---|---|---|
| Local stdio process | Developer tools, one user, local files | Runs with the user's privileges; sandbox it |
| Container on your cloud (AWS, Azure, Google Cloud) | Most business servers, private network access to your systems | Public HTTPS endpoint needed for Claude and ChatGPT |
| Serverless functions | Spiky, low-volume tools | Cold starts and execution time limits on slow APIs |
| API gateway in front of the server | Enterprises with central auth, quotas and WAF rules | The new Mcp-Method and Mcp-Name headers help gateways route without reading bodies |
| Vendor-hosted server | SaaS platforms that ship their own | You inherit the vendor's tool design and limits |
For teams in the UK, Germany and the UAE, hosting region matters for personal data. Keep the server and its logs in the region your data protection review approves, because tool arguments and results often contain customer details.
Worked Example: An MCP Server for a CRM
Here is a realistic first server for a sales team that wants Claude and ChatGPT to work with its CRM.
Tools (six):
| Tool | Scope | Behaviour |
|---|---|---|
search_contacts |
crm:read |
Search by name, email or company; returns at most 25 results |
get_account |
crm:read |
Account details, owner and open deals |
list_open_deals |
crm:read |
Deals by stage and owner |
log_activity |
crm:write |
Add a call or meeting note |
create_task |
crm:write |
Create a follow-up task for the current user |
update_deal_stage |
crm:deals.write |
Move a deal one stage; client asks the user to confirm |
Resources: crm://pipeline/stages and the template crm://accounts/{id}/summary. Prompts: "Prepare an account brief" and "Weekly pipeline review".
Hours and cost:
| Work package | Hours |
|---|---|
| Discovery and tool design | 32 |
Server scaffold, Streamable HTTP transport, server/discover |
24 |
| Six tools at about 16 hours each | 96 |
| Resources and prompts | 24 |
| OAuth with the company identity provider, Protected Resource Metadata | 48 |
| Scope enforcement and audit logging | 40 |
| Tests: unit, contract and prompt injection | 56 |
| Deployment and monitoring | 24 |
| Documentation and client setup for Claude and ChatGPT | 16 |
| Total | 360 |
At $40 an hour that is $14,400. At about $93 an hour, the fully loaded cost of a US in-house developer (the BLS median software developer wage of $135,980 a year divided by 2,080 hours, grossed up because wages are about 70% of employer cost), the same build is about $33,480. Both figures are estimates for this scope.
Token overhead check: if each tool definition is about 150 tokens, the six tools add about 900 input tokens to every model call. At 10,000 calls a month on a model priced at $2 per million input tokens, that is $18 a month uncached, or about $0.90 at a $0.10 cached rate (rates from Anthropic's pricing page, as of October 2026). Twenty vague tools would cost three times as much and confuse the model more.
Running cost (estimate): a small container and logging often costs $20 to $100 a month, plus 4 to 8 hours a month of upkeep as the CRM's API changes.
Build vs Off-the-Shelf MCP Servers
Before commissioning a build, check whether the vendor already ships one.
- GitHub maintains an official MCP server under the MIT licence, hosted remotely at
api.githubcopilot.com/mcp/, with toolsets you can switch on or off and a read-only mode. - Salesforce made its hosted MCP servers generally available in April 2026 for Enterprise Edition orgs and above. Every call runs as the authenticated user, so existing sharing rules and field-level security apply.
- Microsoft SQL Server and Azure SQL connect through SQL MCP Server in Data API builder version 1.7 and later. It exposes typed operations on configured entities with role-based access, and Microsoft deliberately does not support natural-language-to-SQL.
- The official MCP Registry lists public servers, and the reference servers repository shows the patterns.
| Choose off-the-shelf when | Choose a custom build when |
|---|---|
| The vendor's tools match your use case | You need business logic the vendor does not offer (approval rules, pricing limits) |
| The vendor's permission model is enough | You need one server across several systems |
| You use the system in a standard way | Your system is in-house, legacy or heavily customised |
| You can accept the vendor's roadmap | You need specific audit, residency or compliance controls |
A common middle path is a thin custom server that wraps an official one, adds your rules and hides tools you do not want models to see.
MCP Server Development Cost
Cost follows the number of systems, the depth of write access and the security bar. These are estimates using hours x rate.
| Scope | Estimated hours | At $40/hour | At $93/hour (US in-house) | Timeline |
|---|---|---|---|---|
| Read-only server for one system, 5 to 10 tools | 240 | $9,600 | $22,320 | 3 weeks |
| Read and write server for one system, OAuth, scopes, audit | 360 to 480 | $14,400 to $19,200 | $33,480 to $44,640 | 4 to 6 weeks |
| Gateway across 3 to 5 systems, SSO, per-tool scopes | 600 to 1,000 | $24,000 to $40,000 | $55,800 to $93,000 | 6 to 10 weeks |
| Enterprise platform, many systems, multi-tenant, compliance | 1,200 to 2,000 | $48,000 to $80,000 | $111,600 to $186,000 | 12 weeks and up |
The single-system bands line up with the 3 to 6 weeks Pixel quotes for an MCP and tool layer. Ongoing cost covers hosting, monitoring and changes when the underlying APIs or the specification move, which the 2026 revision proved can happen within a year.
How to Choose an MCP Server Development Company
Ask every builder these questions, and expect specific answers:
- Which specification version will you build to? The answer should be 2026-07-28, with a plan for clients still on older versions.
- How will you handle authorization? Listen for Protected Resource Metadata, audience validation and your existing identity provider, not shared API keys.
- How are scopes mapped to tools? Ask to see the scope table before the build starts.
- How will you test prompt injection? A credible answer includes poisoned documents and adversarial prompts in the test set.
- Who owns the code? You should own the server, its tool definitions and its tests outright.
- How will tool quality be measured? Good teams test whether models pick the right tool and fill arguments correctly, not just whether the endpoint returns 200.
- Can it serve several clients? One server should work with Claude, ChatGPT and your own agents.
MCP servers rarely live alone. They feed agents, copilots and retrieval systems: Pixel's AI copilot development services use them to put actions inside everyday tools, its RAG development services handle the document side, and its wider AI development services cover the systems around them.
How Pixel Web Solutions Can Help
Pixel Web Solutions is a UAE and India based AI and software development company, operating from Ras Al Khaimah, UAE and Madurai, India. Its engineers build MCP servers and tool layers as part of its AI agent development services, with least-privilege scopes, audit logs and prompt injection tests in every build.
Servers are written to the current specification and handed over with full source code, tool definitions and tests. Custom development starts from $40 an hour. To scope a server for your CRM, database or internal API, contact the Pixel team.
Frequently Asked Questions
What is an MCP server?
An MCP server is a service that exposes tools, resources and prompts to AI applications through the Model Context Protocol. It lets models such as Claude or ChatGPT read data and take actions in your systems through one standard interface.
How much does it cost to build an MCP server?
A read-only server for one system takes about 240 hours, roughly $9,600 at $40 an hour. A read and write server with OAuth and audit logging is about 360 to 480 hours, or $14,400 to $19,200 at the same rate. Multi-system gateways cost more.
Can I build a custom MCP server for Claude?
Yes. Claude supports custom connectors to remote MCP servers on Free, Pro, Max, Team and Enterprise plans, with Free limited to one. The server must be reachable from Anthropic's cloud over HTTPS, and OAuth is the usual sign-in method.
Does ChatGPT support MCP servers?
Yes. OpenAI's developer documentation explains how to build an MCP server for ChatGPT and Codex, and sets review requirements for servers listed publicly. The same well-built server can usually serve both ChatGPT and Claude.
What is the difference between an MCP server and an API?
An API is built for programmers who read the documentation. An MCP server is built for models: it offers a small set of described tools with schemas, decides what each caller may see and returns results a model can use. Most MCP servers call an existing API behind the scenes.
Is MCP secure?
The protocol gives you the parts (OAuth 2.1, audience-bound tokens, scope challenges), but security depends on how the server is built. Least-privilege scopes, confirmation for destructive tools, input validation and prompt injection testing are what make a server safe.
Should I use stdio or Streamable HTTP?
Use stdio for local, single-user tools that run on a developer's machine. Use Streamable HTTP for anything shared, hosted or connected to Claude and ChatGPT, because remote clients need an HTTPS endpoint and OAuth.
MCP server development pays off when one well-scoped server replaces a pile of one-off integrations. Build to the 2026-07-28 specification, design the scopes before the tools, and check for an official server before you write a line of code.
