MCP server development: connect your APIs to Claude, Cursor, and every agent your team runs

What an MCP server actually does

Skip the analogy and go straight to the mechanics. An MCP server is a thin, standardized interface that sits in front of a system you already have (an API, a database, a CMS, a ticketing tool) and exposes a defined set of tools, resources, and prompts that any MCP-compatible client can call. The client could be Claude Desktop, Claude Code, Cursor, or the OpenCode agent your infra team is testing this quarter. If you’re still deciding which of those belongs on your team’s stack, our breakdown of Claude Code, Copilot, and Cursor covers that separately. The server itself doesn’t need to know or care which one is calling.

The protocol is JSON-RPC based, running over stdio for local setups or Streamable HTTP for remote ones. That’s the whole point: you write the integration once, describe what it does in terms an LLM can reason about, and every agent in your stack gets access without a bespoke connector per vendor.

What changed

Two different timelines are worth separating here.

The governance question is already settled. In December 2025, about seven months ago now, Anthropic handed control of the protocol to the Linux Foundation’s Agentic AI Foundation. Combined with MCP support shipped by OpenAI, Google, and Microsoft into their own tooling over the same period, this settled the “is this a real standard or an Anthropic side project” question that used to slow procurement conversations down. That objection is largely gone now.

What’s actually moving this quarter is the practical side. Streamable HTTP is replacing the older SSE-based remote transport across the ecosystem, which matters if you’re planning a server that runs centrally rather than locally on each developer’s machine. And as more of these servers move from local experiments to shared infrastructure, enterprise teams are increasingly asking for registry, approval, and audit layers before granting an agent write access to anything: not read-only demos, but the kind of access that lets an agent close a ticket, update a record, or trigger a deployment.

None of this changes what MCP is. It changes what “good” looks like when you build one. A server designed six months ago, before this shift, is the kind of thing teams are now finding they need to rework.

The integration tax you’re probably already paying

Consider a mid-size platform team supporting three agent tools across engineering. Without MCP, each agent needs its own way of calling the internal ticketing API, the deployment system, and the internal knowledge base. That isn’t three integrations, it’s three integrations per system, and the number compounds every time someone adopts a new agent or a new internal tool enters the mix.

The cost isn’t only development time. It’s maintenance. When the ticketing API changes its authentication scheme, someone has to update it in three places, each tested against a different agent’s quirks. Bugs surface inconsistently because each integration was written by a different person, at a different time, against a different understanding of the API.

An MCP server collapses this back to one integration, maintained once, consumed by every agent that speaks the protocol. The work doesn’t disappear (someone still has to decide which operations are safe to expose and what the failure behavior looks like), but it stops multiplying with every new tool.

What building one looks like

Building a production MCP server is a scoping exercise before it’s a coding exercise. Three decisions tend to determine whether the result is useful or a liability.

What gets exposed as a tool. Not every API endpoint should become an agent-callable tool. Read operations (look up a ticket, fetch a record, query a knowledge base) are usually safe to expose broadly. Write operations (close a ticket, push a deployment, modify a customer record) need a narrower scope and, in most production setups, a human-in-the-loop checkpoint before the action executes.

Authentication and identity. An MCP server exposed beyond a single developer’s laptop needs proper OAuth 2.1-based authorization, not a shared API key sitting in a config file. This is where a surprising number of early MCP implementations cut corners, and it’s the first thing a security review will flag.

Logging and audit trail. If an agent can take an action, someone will eventually ask what it did and why. Structured logging of every tool call (what was requested, what was returned, which agent and which user session triggered it) stops being optional the moment the server handles anything beyond read-only lookups.

Where this shows up outside the whiteboard

Theory aside, here’s what this looks like once it’s actually built.

MCP Farmer is an open-source MCP server we maintain and publish on npm: a working example of exposing a defined set of tools rather than an entire API surface, with the scoping decisions above made explicit in the code instead of left as an afterthought. It’s a reference point for teams who want to see the pattern before committing engineering time to their own version.

On a client project, we used an MCP server to automate a Netlify CMS workflow: content structuring, validation, and publishing tasks that previously required someone manually working through the CMS interface. The server was live in three days, not because the underlying API was trivial, but because most of the effort went into deciding what to expose, not into writing the JSON-RPC plumbing.

An MCP server on its own is only half the picture. It needs a generation layer worth connecting it to, or it’s exposing tools that nothing calls intelligently.

We also run a public MCP server that handles RFQ (request for quote) intake: a production example of a server accessible outside a single company’s internal network, with the authentication and rate-limiting decisions that requires. It’s a useful case for anyone wondering whether MCP servers are strictly a local-developer-tool pattern. They aren’t.

When MCP server development isn’t the right first move

MCP isn’t the answer to every integration problem, and teams that reach for it reflexively tend to end up with more infrastructure than their use case justifies.

• If your team runs a single AI agent with no plan to add a second, a direct API integration is simpler to build and easier to reason about. The abstraction layer MCP provides earns its cost only once more than one client needs it.
• If the systems you’d expose are still changing shape weekly, building a stable MCP interface on top of them is premature. Standardize the underlying API first.
• If governance and security review haven’t yet answered who owns write-access approval, building the server before that conversation happens just moves the risk earlier. It doesn’t remove it.

Where to start

If your engineering team is already juggling more than one AI agent, and each one needs its own way into your systems, the integration tax described above is probably already showing up in your sprint estimates, even if nobody’s called it that yet.

The next useful step is usually a short scoping conversation: which systems are worth exposing, what should stay read-only, and what a first server could realistically look like on your actual stack. That’s what our MCP Server Development practice is built around, including the governance and audit questions covered above, not just the JSON-RPC plumbing.

For a broader view of how different vendors approach this space, our review of MCP implementation companies in 2026 is a reasonable place to compare notes before choosing a partner.

FAQ

What’s the difference between an MCP server and a regular REST API?
A REST API is built for a developer to read documentation and write client code against it. An MCP server is built for an LLM to discover what it can do at runtime and call it correctly without a human writing the integration by hand. The underlying system can be the same. The interface layer on top is what’s different.

Do we need a separate MCP server for every AI tool we use?
No. That’s the point of the protocol. One MCP server, once it’s built and authenticated properly, can serve Claude, Cursor, OpenCode, or any other MCP-compatible client without changes.

Is MCP tied to Anthropic, or can we use it with any AI vendor?
MCP was introduced by Anthropic, but it’s now governed by the Linux Foundation’s Agentic AI Foundation, and OpenAI, Google, and Microsoft have all shipped support for it in their own tooling. Building an MCP server does not lock you into a single model vendor.

How do we control what an agent is allowed to do through an MCP server?
Through scoping, not trust. Expose read operations broadly, gate write operations behind narrower permissions, and put a human-in-the-loop checkpoint in front of anything that changes state in a system that matters. The server is the enforcement point, so the access model has to be decided before the code is written, not after.

How long does it take to build a production MCP server?
It depends far more on how many systems you’re scoping and how clean the underlying APIs already are than on the protocol itself. A single, well-documented system with a narrow set of read operations can be live in days. A server spanning several internal systems with write access and audit requirements is a multi-week engagement.

Does MCP replace our API gateway or existing integration platform?
No. An API gateway manages traffic, rate limiting, and access at the network level. An MCP server sits above that as an agent-facing interface, describing what’s available in a way a model can act on. Most production setups run both, with the MCP server calling through the existing gateway rather than around it.