The short answer
MCP is an open protocol from Anthropic that standardises how AI models talk to external tools and data. Build an MCP server when you have a tool multiple AI clients will use; skip it for one-off integrations where a direct API call is simpler. The 500+ public servers cover most enterprise systems already — check before building.
We use MCP daily — Claude Code is our main coding interface, and it speaks MCP to filesystem, git, GitHub, and a handful of internal servers we've written. That's our credential. The rest of this post is a builders' decision framework, not a tutorial. If you want to write your first MCP server in 6 steps, the official docs are excellent. If you want to know whether to write one at all, keep reading.
Watch first: Anthropic's MCP workshop
Mahesh Murag's full workshop is the best one-source explainer. He covers the three primitives, the transport options, and (importantly) the design philosophy — what MCP optimises for and what it doesn't.
What MCP actually is (1-paragraph version)
MCP is a JSON-RPC 2.0 protocol that defines how an AI client (Claude Desktop, Cursor, Claude Code, custom agents) talks to an external server that provides three kinds of capabilities: Tools (functions the LLM can call with user approval), Resources (file-like data the client can read), and Prompts (pre-written templates). The transport is either stdio (the client spawns the server as a subprocess) or HTTP/SSE (the server is a remote service). That's the entire protocol surface.
The three primitives at a glance
| Primitive | What it is | Who initiates | Typical use |
|---|---|---|---|
| Tools | Functions with typed args | Model decides to call | "Run this query", "Create this PR", "Send this Slack message" |
| Resources | Read-only data exposed by URI | User or model selects | "Read this file", "Read this dashboard config", "Read this DB schema" |
| Prompts | Parameterised prompt templates | User selects | "Run code review prompt with these args", "Generate weekly report" |
Most builders only ship Tools at first. Resources matter when the LLM needs context the user can't paste in. Prompts matter when the same task pattern repeats and you want a clean "user picks from a menu" UX. The official servers repository has 30+ reference implementations — reading them is the fastest way to absorb the primitives in practice.
The 4-question decision framework: should you build an MCP server?
1. Is there already a public MCP server for this?
Before building anything, check the official servers repo and search the community lists. As of mid-2026, there are public MCP servers for GitHub, Slack, Postgres, Stripe, Linear, Notion, Figma, Docker, Kubernetes, Sentry, Cloudflare, AWS, Google Drive, and ~200 other things. If a public one exists and meets your auth/data-isolation requirements, use it. Building your own is rarely the right call here.
If the public server doesn't meet your security model (common reason to roll your own) or you need a customised tool surface, then yes, build one. The most common "roll your own" cases we've shipped: internal admin tools, customer-data lookup with audit logging, and bespoke deployment workflows that don't map to any public server.
2. Will multiple AI clients need this?
This is the question that flips the build/don't-build decision more than any other.
Yes, multiple clients (Claude Desktop, Claude Code, Cursor, your own agent, internal tooling): MCP server is correct. One implementation, many clients.
No, single integration (you're building a feature in your Rails app that calls Claude with one specific function-calling tool): skip MCP. Use Anthropic's native function-calling API directly. The protocol overhead isn't worth it for one client.
This is the "engineering question" most MCP advocacy posts skip. Function calling already exists. MCP earns its complexity when you have many clients, not when you have one.
3. Is the tool stable enough to ship as an interface?
MCP servers have no built-in versioning. If your tool signatures change weekly, you'll break every client that depends on you. For internal MCP servers this is manageable (you control the clients). For public-facing ones, ship a v1 only when the tool surface is genuinely stable.
We've watched teams build MCP servers around APIs that were still in flux, then spend more time managing compatibility breaks than building features. Wait until the underlying interface has hit "we won't redesign this for 6 months" status.
4. Who handles auth?
MCP does not enforce auth. If the server is local (stdio), auth is "the user runs the binary, so they have whatever permissions the binary has". If the server is remote (HTTP/SSE), you implement OAuth, API keys, or whatever pattern fits — the protocol doesn't help.
For internal-only MCP servers reachable inside a VPN or local-only, this is fine. For anything internet-facing, you need a real auth story before launch. Most production MCP-server bugs we've debugged trace back to auth assumptions that didn't hold.
When NOT to build an MCP server
The contrarian section. Skip MCP when:
- You're integrating with one model from one app. Anthropic's function-calling API or OpenAI's tools API are simpler. Save MCP for when client variety matters.
- Your tool surface is unstable. Better to iterate on raw API calls until the surface is stable, then wrap with MCP.
- You need fine-grained per-user permissions. MCP servers are typically "one process per user" (stdio) or auth-token-keyed (HTTP). Complex RBAC inside the server is your problem to design.
- You're building a chatbot for your own product. For that case, embed Claude or GPT in your app, use function calling, ship faster. MCP shines for cross-client tool reuse, not single-app embedding. See our take on this in how to build an AI chatbot for your business.
- You don't have an MCP-capable client in your stack. If everyone's on a custom GPT-4 wrapper, MCP buys you nothing. The value is in the standardisation across MCP-aware clients.
Production gotchas (the things we wish we'd known)
Transport choice locks in deployment shape
The two transports look interchangeable in tutorials. They're not, operationally:
- stdio means the client launches your server as a child process. Simpler to write, no network code, no port management. But: only works when the client and server are on the same machine. No multi-tenant. No remote deployment. Fine for Claude Desktop integrations, dev-tools, anything that runs locally.
- HTTP/SSE means the server is a long-running process accessible over the network. You write a proper web service with auth, rate limiting, observability. Required for any multi-user deployment, any cloud-hosted server, anything customers consume.
Decide which one in design, not mid-implementation. Switching costs a rewrite.
Auth is your problem (and most public examples skip it)
The protocol spec doesn't define auth. Most tutorials don't either. For HTTP transport you need:
- A token or OAuth flow to authenticate clients
- Per-user data scoping (multi-tenant servers can leak cross-customer data if you don't)
- Audit logging (you'll need this for compliance regardless of MCP)
- Rate limiting (LLM clients can call your tools in tight loops — a model that misunderstands a task can hammer you)
This is roughly what you'd build for any REST API. MCP doesn't change the work, it just bundles the calling convention.
Versioning isn't built in
Add a new required tool argument and existing clients break. The protocol has no semantic-versioning baked into tool schemas. Mitigations: keep old tools alongside new ones with different names (create_issue_v2), or use the "deprecated" flag in tool descriptions to warn clients.
For internal servers (you control all clients) this is mild. For public servers it's the same backward-compatibility discipline as any public API — just without the SDK conventions to lean on.
Tool descriptions are part of the prompt
LLMs decide whether to call a tool based on its description. If your tool description is vague, the model won't use it, or will use it wrong. Treat tool descriptions like UX copy: precise, actionable, with examples.
"Search the database" is bad. "Search the orders database by customer_id, order_status, or date range. Returns up to 50 matching orders with full line items. Use this when the user asks about specific orders." is good. The model reads both before deciding to invoke.
Token cost of MCP tool inventories
Every connected MCP server's tools (with their descriptions) get sent to the model as part of every request. Connect 5 servers with 10 tools each, and you're shipping ~5K tokens of tool schemas per turn. On Sonnet pricing that's ~$0.015 per turn before the actual conversation. Multiply by sessions and it adds up.
Mitigations: keep tool counts low per server, write tight descriptions, use a thin gateway server that exposes only the tools relevant to the current task.
What we use MCP for
Concretely, the MCP servers we've shipped or rely on daily:
- GitHub server (public): PR creation, issue triage, code review from Claude Code. Single most-used.
- Postgres server (public): schema introspection and read-only query execution for debugging production data.
- Custom Rails-app server (internal): exposes a read-only view of our admin tools so we can ask Claude "what's the status of order #X" without leaving the terminal. Built in ~2 days of Rails work.
- Custom Rankloop server (internal): the Rankloop AI SaaS exposes content-generation triggers and CMS-publishing status via an MCP server so our agents can orchestrate the platform from a single Claude conversation.
The pattern: public servers for ecosystem tools, internal servers for our own systems. We have not built any customer-facing MCP servers yet — the auth-and-multi-tenancy story isn't worth the engineering for our current client mix. That calculus might change as more end-user products adopt MCP.
Where MCP fits in a broader AI stack
MCP is one layer in the AI-integration stack. It sits above raw function calling (which is per-model) and below full agent frameworks (LangGraph, Claude Agent SDK, etc.). For a broader take on where this stack fits in business use cases, see our AI agents for business guide. For the tool-vs-tool comparison in your developer environment, our Cursor vs Claude Code comparison covers which AI coding assistants speak MCP and how that changes the workflow.
FAQ: MCP servers for builders
Is MCP only for Claude / Anthropic?
No. It's an open protocol. Anthropic created it, but Cursor, Sourcegraph Cody, Continue, Zed, and a growing list of other AI clients support it. OpenAI's tools API isn't MCP-compatible directly, but adapters exist. Treat MCP as cross-client, not Anthropic-only.
Should I build an MCP server or use function calling?
Use function calling when one app talks to one model. Build an MCP server when the same tool will be reused across multiple AI clients (Claude Desktop, an internal agent, third-party tools). Don't pay the MCP overhead for single-client integrations.
How is MCP different from OpenAPI / tool definitions in OpenAI?
OpenAPI describes REST APIs for humans and code generators. OpenAI tool definitions are JSON schema for one model's function calling. MCP is a transport-plus-schema protocol designed to be consumed by many AI clients, with built-in primitives for resources and prompts beyond just tools. Different problem spaces with surface overlap.
Can MCP servers be public-internet-facing?
Yes, via the HTTP/SSE transport. But the protocol doesn't enforce auth — you have to add OAuth, API keys, or whatever scheme fits, plus rate limiting and per-user data scoping. Most production MCP servers in 2026 are internal (VPN-only) for exactly this reason.
What languages have MCP SDKs?
Official SDKs exist for TypeScript, Python, C#, Java, and Swift. Community SDKs cover Go, Rust, and Ruby (with varying maturity). For Rails apps building internal MCP servers, the Ruby SDK works but the TypeScript SDK has the deepest ecosystem support if you can run a small Node sidecar.
How we can help
At TechVinta, we build Rails-based AI integrations and have shipped multiple MCP-aware systems — internal tools that connect Claude Code to our codebases, the Rankloop platform's automation layer, and client projects where Claude is part of the production workflow. We can help you decide whether MCP fits your architecture before you write a line of server code.
Planning AI integration into your Rails app and trying to figure out whether MCP, direct function calling, or a full agent framework fits? Talk to our engineering team, or get a free project estimate — we'll review your use case, client mix, and security model and propose a stack within 48 hours.
