Clear guide to MCP servers: how they expose tools, resources, and prompts via JSON-RPC, plus security, use cases, and when to choose MCP.
MCP servers cut AI tool integrations from an M × N mess to M + N. That means one AI app can connect to many tools through one shared protocol, instead of needing a custom build for every single pairing.
If I had to explain it in one line, I’d say this: an MCP server is a controlled middle layer between an AI client and a system like GitHub, PostgreSQL, Slack, or your own API. It exposes a fixed set of actions and read-only data, then sends back structured results the model can use.
Here’s the article in plain English:
- What MCP is: an open protocol for connecting AI apps to tools and data
- What an MCP server does: wraps an API, database, file system, or service in a standard interface
- Why it matters: it cuts repeated integration work and lets one server work across many MCP-ready hosts
- What it exposes: tools for actions, resources for read-only context, and prompts for reusable workflows
- How it works: handshake, capability discovery, JSON-RPC calls, then structured responses
- Where it fits: IDE agents, support copilots, internal assistants, DevOps flows, database access, and business workflows
- When to use it: when one model-driven workflow needs access to multiple systems
- When not to use it: when the flow is fixed, fully scripted, or very latency-sensitive
- What to watch for: scope limits, input validation, prompt injection from tool output, and safe local or remote deployment
A few facts stand out. MCP uses JSON-RPC 2.0 for message exchange, remote servers often use OAuth 2.1, and long-running tasks often return a job ID plus status checks. Those details matter because they show MCP is not “magic AI plumbing.” It’s a defined protocol with rules, limits, and security concerns.
If you’re choosing between MCP, plugins, and plain APIs, the short answer is simple: use MCP when you want one integration to work across multiple AI hosts; use a plain API when your flow is fixed and the model doesn’t need to choose tools on its own.
In other words: MCP is less about giving AI raw system access and more about giving it a safe, structured way to work.
What MCP is and what an MCP server does
Model Context Protocol in plain English
MCP is an open standard for how AI apps find and use outside capabilities - tools, data, and services - through one common interface. Put simply, it gives AI apps one shared way to connect to tools and data, so a single client can work with many servers.
The official docs put it this way:
"Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems."
That’s the core idea. MCP gives AI apps a common connector, and the server is the piece that turns that standard into something a model can actually use.
What an MCP server actually is
An MCP server is a thin layer between an AI client and an underlying system, such as a database, file system, API, or internal service. It takes standardized requests from the AI, translates them into something the underlying system understands, and sends back structured results the model can work with.
In other words, MCP wraps existing tools and data sources in a structured layer the model can call.
A basic MCP setup has four parts:
- A host runs the AI app
- A client makes the connection
- The server exposes capabilities
- The underlying system does the work
One detail matters a lot here: the server does not give the AI raw access to a system. Instead, it defines which actions are allowed and what data can be read. So this is a controlled interface, not direct access.
That’s what the server is. The next piece is how requests move through it.
Why MCP exists
This structure solves a problem AI apps hit without a shared standard: every new tool connection can turn into its own one-off integration.
There’s a useful parallel here for developers. Before the Language Server Protocol (LSP), each code editor needed its own plugin for each programming language. LSP fixed that by standardizing the relationship, so one language server could work across many editors. MCP does the same kind of job for AI and outside tools.
The result is simple: a GitHub MCP Server can work with Claude, Cursor, and any other MCP-compatible host without modification. That shared standard is what makes MCP servers practical. The next step is how they expose tools, resources, and prompts.
How MCP servers work under the hood
Capabilities: tools, resources, and prompts
MCP servers expose three primitives: tools, resources, and prompts.
| Primitive | Triggered By | Use | Typical Use Case |
|---|---|---|---|
| Tools | Model | Action | Running queries, creating tickets, sending emails |
| Resources | Application | Read-only | File contents, database schemas, API docs |
| Prompts | User | Reusable prompt | Slash commands like /summarize or /triage-issues |
Here’s the simple way to think about it.
Tools are controlled by the model. The LLM decides when to call them, and they can change state. That makes them the part of MCP that does things.
Resources are controlled by the application. The host pulls them in as read-only context, so they don’t cause side effects. They’re there to give the model information, not authority.
Prompts are controlled by the user. They act like reusable instruction templates for set workflows, such as slash commands.
Those three pieces shape the full request flow.
The request flow from client to backend
After the host knows what the server exposes, it can discover, rank, and call those capabilities.
First, the client and server perform a handshake to negotiate protocol versions and capabilities. Then the client checks what the server can do by calling tools/list, resources/list, or prompts/list and getting schemas back. The host passes that information to the model so it can decide what to use.
When the model needs to take action, it calls tools/call. When the host needs read-only context, it uses resources/read. The server runs the request and returns structured data or errors over JSON-RPC 2.0.
For long-running tasks, the usual pattern is a job ID plus a status resource .
Security, permissions, and performance
MCP sits between the model and the backend, so permissions and isolation matter a lot.
Local servers use stdio. Remote production servers use Streamable HTTP and OAuth 2.1. Local servers run as subprocesses, inherit the OS user’s identity, and usually have low latency. Use Roots to limit filesystem access to specific project directories. For remote servers, ask for the narrowest OAuth scopes possible and run the server in a container.
Treat every tool argument as untrusted input. Runtime schema validation helps block SQL injection and shell injection. On stdio servers, always write logs to stderr, never stdout. stdout is reserved for JSON-RPC messages, and anything else written there can corrupt the communication stream.
For remote servers, structured logs with OpenTelemetry help you see what’s happening in production. Track fields like mcp.tool.name, duration, and success or error status.
There’s one more risk that’s easy to miss. If a tool reads outside data - like a GitHub issue, a document, or an email - that content might include instructions meant to hijack the model through prompt injection in tool output. Sanitize tool outputs before they reach the model’s context, and never pass raw outside content through without validation.
What you can build with MCP and when to use it
Now that the protocol basics are clear, the next step is simpler: where does MCP fit in an actual product?
Common use cases and real MCP server examples
MCP matters because it turns standard capabilities into working flows. And when you look at the most common server types, you can see where teams are putting it to work today.
| Category | Example Servers | What They Enable |
|---|---|---|
| Code & DevOps | GitHub, GitLab, Linear, Sentry | PR management, issue tracking, error triage |
| Infrastructure | Docker, Terraform, AWS, Azure | Container management, orchestration tools, cloud resource management |
| Databases | PostgreSQL, MongoDB, Snowflake | Schema introspection, safe data querying |
| Productivity & Knowledge | Slack, Notion, Google Drive, Atlassian | Document retrieval, internal knowledge search |
| Workflow Automation | Stripe, GitHub, Linear | Payments, task creation, controlled business actions |
Those buckets show up again and again in product design. It’s the same idea in different clothes: give one assistant access to the tools people already use, then let it handle work that would otherwise bounce between tabs, APIs, and humans.
What developers can build with MCP
The primitives from the previous section map cleanly to products teams are already shipping. For example, an internal assistant can read Notion and Slack, create Jira tickets, and put together weekly triage reports. An IDE agent can pull Sentry traces and inspect PostgreSQL schemas. A support copilot can read a knowledge base and trigger approved Stripe or Linear actions.
That’s where MCP starts to click. It shines when one assistant needs safe access to multiple systems inside one workflow. Instead of wiring each connection from scratch, teams can use MCP as the glue.
When to build your own MCP server
Public servers cover many common services. But they won’t get you all the way into private systems.
If your team has a private REST or GraphQL API, a legacy system, or a private data warehouse, building your own MCP server usually makes sense. The big upside is reuse: one server can support many MCP-compatible clients.
Use MCP when the workflow is reusable and model-driven. If the pipeline is fully deterministic, where the API call order is fixed, or if you’re dealing with a latency-sensitive path where putting a model in the loop adds too much delay, a standard REST call is the better choice instead .
MCP vs plugins vs APIs, and where to start
How MCP differs from a plugin or a plain API
After you get the basics of tools, resources, and prompts, the next step is simple: should you use MCP, a plugin, or just a plain API?
Plain APIs are direct. But they also put more work on each AI client. Every client needs its own integration code to find endpoints, read schemas, and call the right actions. MCP adds a standard layer for AI clients on top of that. So a client that supports MCP can discover what a server offers, read its tool schemas, and call those capabilities in a structured way. That means less host-specific adapter code and more reuse.
Platform-specific plugins work differently. They’re usually tied to one platform. So if you build a plugin for one assistant, there’s a good chance you’ll need to rebuild it for another. MCP is built to separate the client from the integration, which makes reuse across hosts much easier.
| Integration Model | Reuse Across Clients | Permissions and Governance |
|---|---|---|
| MCP Server | High | Standardized, user-consent based |
| Platform-Specific Plugin | Low | Platform-managed |
| Plain API | Medium | Developer-managed |
The best option depends on what you need. If the same integration needs to work across more than one AI host, MCP is the right fit.
How to get started with MCP servers
If MCP fits your use case, start with the spec and a local reference server.
The best place to begin is the official docs at modelcontextprotocol.io. They cover terminology, capability definitions, message flow, and security guidance .
From there, keep it small. A good first step is to expose one internal system through a local server. The @modelcontextprotocol/server-filesystem and @modelcontextprotocol/server-git packages can be started with npx in a few minutes . That’s often the moment it clicks.
After that, you can move to a small custom server using the official Python or TypeScript SDK with stdio transport before you shift to remote production deployments. Official SDKs are also available for Go, Java, C#, Kotlin, and PHP .
Before you build from scratch, check the existing server directories. You may find something close to what you need already.
Conclusion: key takeaways for developers
Choose MCP for reusable, multi-host integrations. Choose a plain API for fixed, deterministic workflows.
FAQs
Do I need an MCP server for every tool?
No. You don’t need a separate MCP server for every tool.
An MCP server can expose one or more capabilities, like tools, resources, or prompts. That means you can group related tools in one server instead of splitting them into a bunch of small ones.
For example, a single GitHub MCP server can handle repository search, issue creation, and pull request management.
Can MCP servers safely perform write actions?
Yes. MCP servers can handle write actions safely, but that safety depends on human oversight and controls in the app.
Developers can label tools as destructive or read-only. That lets the host app show approval prompts before an action runs. Apps can also pre-approve some operations and keep activity logs, which makes it easier to review what happened.
Read-only resources are the safer option for giving context. But MCP tools are built to support write actions too, as long as those actions happen under clear controls.
How do I know if MCP is better than a plain API?
MCP is a better fit than a plain API when you need tools to work across multiple platforms and AI assistants.
With a plain API, you usually have to build separate integrations for each model or app. That means more setup, more maintenance, and more chances for things to break.
With an MCP server, you build the integration once. Then any MCP-compatible AI client can find it and use your tools and data.
Put simply:
- An API is a fixed endpoint
- MCP is an AI-friendly layer for discovery and actions
That’s the big difference. An API gives access. MCP helps AI systems understand what’s available and how to use it.
