MCP Servers Explained: How to Give Claude and Cursor Real Tools

An LLM in a chat window can write you a script that queries your database. It cannot query your database. That gap, between knowing how and being able to, is what the Model Context Protocol closes.

MCP is an open standard introduced by Anthropic in November 2024. It gives AI applications one consistent way to reach external tools and data. By late 2025 there were more than 10,000 active public MCP servers and over 97 million monthly SDK downloads across the Python and TypeScript packages, with native support in Claude, ChatGPT, Gemini, Microsoft Copilot, VS Code, and Cursor.

This post explains what a server actually is, what it is not, and what building one involves.

The problem MCP solves

Before MCP, every AI product built its own integration layer. If you wanted your assistant to read Postgres, you wrote a Postgres plugin for that specific assistant. If you then wanted the same capability in a different editor, you wrote it again against a different plugin API.

This is the N times M problem: N assistants times M tools equals N times M integrations. MCP turns it into N plus M. Write one server, and every MCP-capable client can use it without any glue code from you.

That is the entire pitch, and it is a boring infrastructure pitch, which is usually a sign the standard is a good one.

What a server actually exposes

An MCP server offers three kinds of thing. The distinction matters because clients treat them differently.

Tools are functions the model can call. They have a name, a description, and a JSON schema for arguments. format_json, create_invoice, search_tickets. The model decides when to call one, so the description is not documentation, it is the prompt that determines whether the tool gets used correctly. Vague descriptions are the most common reason a working server behaves badly.

Resources are data the client can read. A file, a database row, a config. The application decides when to load these, not the model.

Prompts are reusable templates the user can invoke deliberately, usually surfacing as slash commands.

Most servers in the wild are tools-only. Resources and prompts are underused, and resources in particular are the right answer when you want the model to have context without spending a tool call to get it.

The architecture, briefly

MCP uses a client-server model over JSON-RPC 2.0. The host application (Claude Desktop, Cursor) runs a client, and each client holds a connection to one server.

Two transports matter:

• stdio, where the server runs as a local subprocess and messages travel over standard input and output. This is the default for anything touching local files or local credentials.
• HTTP-based transport, for remote servers, where auth and network exposure become your problem.

The practical consequence: a stdio server inherits the permissions of whoever launched it. A remote server does not. That single difference should drive most of your design decisions.

Building one: what it actually takes

The SDKs handle the protocol. Your work is almost entirely in three places.

1. Tool descriptions. This is where servers succeed or fail. The model reads the description to decide whether to call the tool and what to pass. Write them as instructions to a competent stranger, not as API reference. State what the tool does, when to use it, when *not* to use it, and what the arguments mean in domain terms.

2. Input validation. Treat every tool call as untrusted input, because it is. The arguments were generated by a language model that may have been influenced by content it read earlier in the conversation. Schema-validate everything, and never build a shell command or SQL string by interpolating a tool argument.

3. Error messages. When a call fails, the model reads your error and decides what to do next. Error: 400 teaches it nothing. Invoice date must be ISO 8601, got "next tuesday" gets the retry right on the first attempt. Good error text measurably reduces the number of round trips.

The security part people skip

An MCP server is a remote code execution surface that a language model drives. That framing is uncomfortable and it is accurate.

The specific risk is that the model is influenced by content it processes. If your server has a read_webpage tool and a send_email tool, a page containing instructions aimed at the model can potentially chain them. This is prompt injection, and MCP does not solve it. It is your job.

Practical mitigations:

• Scope credentials narrowly. A read-only database role for a server that only reads.
• Keep destructive and data-reading tools out of the same server where you can.
• Require confirmation for irreversible actions rather than trusting the model to be careful.
• Log every tool call with its arguments. You will need this.

We wrote more on this failure mode in prompt injection and AI chat widgets.

Where MCP is not the answer

Honest limits, because the ecosystem is in its hype phase:

• For a single tool used by a single app, MCP is overhead. Just call the function.
• For high-volume automated pipelines, the model deciding which tool to call is a liability, not a feature. Write the pipeline.
• For anything latency-critical, you are adding a model round trip to a decision a switch statement could make.

MCP earns its keep when a human is in the loop, the task is open-ended, and you cannot predict in advance which tools will be needed. That is a real and common situation, but it is not every situation.

Trying one without writing code

ToolBox runs an MCP server exposing a set of its tools, so you can point Claude Desktop or Cursor at it and see the interaction model before committing to building your own. It is a reasonable way to develop intuition for what tool descriptions the model handles well, which is the part that is hard to learn from documentation.

Sources

• What Is the Model Context Protocol, Descope
• MCP Adoption Statistics 2026
• The MCP Ecosystem in 2026

Adoption figures as reported December 2025. Ecosystem numbers in this space move fast, so treat them as a floor.

If you have built a server: did the model call your tools the way you expected, or did you end up rewriting the descriptions three times?