← Back to articles

What Is MCP

MCP (Model Context Protocol) is an open protocol that standardizes how AI assistants connect to external data and tools. Instead of a separate integration for every service (GitHub, a database, CRM, the file system), you run an MCP server and the client - Cursor, Claude Desktop, Zed, and others - connects through a single contract. Below is what MCP is, how the architecture works, and why the protocol matters in production.

Definition in plain terms

The Model Context Protocol is a specification for exchange between an AI application (host) and an external context source (server). A server can expose:

  • Resources - readable data: files, database rows, API documents
  • Tools - actions the model can call: API requests, SQL, index search
  • Prompts - ready-made prompt templates for common scenarios

The protocol is open and not tied to one LLM vendor. The host chooses which model to use; the MCP server chooses which data and tools to provide. Communication uses JSON-RPC 2.0 - the same style as many APIs - with transport over stdio, HTTP, or SSE.

Anthropic's idea (November 2024): replace a "zoo" of custom plugins with one way to attach context to agents.

Architecture: host, client, server

A typical three-role setup:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  MCP Host   │────▶│ MCP Client  │────▶│ MCP Server  │
│ (Cursor,    │     │ (inside     │     │ (GitHub,    │
│  Claude)    │     │  the app)   │     │  Postgres…) │
└─────────────┘     └─────────────┘     └─────────────┘
  • MCP Host - the app with the LLM: IDE, chat client, agent platform. It manages the session, calls the model, and decides when to invoke a tool.
  • MCP Client - a component inside the host that talks to one or more servers via MCP.
  • MCP Server - a process or service that exposes resources, tools, and prompts. It can be local (files on disk) or remote (a corporate API).

One host can hold several clients - one per MCP server. In Cursor, for example, servers for the file system, browser, GitHub, and custom MCP entries from config may run at once.

What MCP delivers in practice

One contract instead of N integrations

Before MCP, each product wrote its own connectors: its own format for "read a file," its own for "call an API." MCP fixes:

  • how tools are declared (name, parameter schema, description)
  • how results are returned
  • how resources are requested and change subscriptions work

The same PostgreSQL MCP server can serve Claude Desktop and another host if that host supports the protocol.

Security and access boundaries

The server runs in a separate process or container. The host does not get direct access to the whole system - only what the server explicitly exposes. For enterprise, that matters: you can give an agent read-only access to a data mart without full production database access.

Local and cloud scenarios

  • Local - stdio transport: the host starts the server binary as a child process (typical for IDEs and desktop clients).
  • Remote - HTTP/SSE: a shared MCP server in VPN or cloud for the whole team.

Both are in the spec; the choice depends on security policy and where data lives.

MCP and function calling

Function calling (tool use) is the LLM-side mechanism: the model returns a structured request to "call function X with arguments Y." MCP is a lower, broader layer: it standardizes where those functions and data come from, how they are registered, and how the host talks to them.

Interaction flow:

  1. The host connects to an MCP server and gets the tool list.
  2. The list is passed to the model in a format the provider understands (OpenAI tools, Anthropic tools, etc.).
  3. The model picks a tool; the host runs the call via MCP client → server.
  4. The result goes back into the model context for the next step.

MCP does not replace model reasoning - it unifies the "wiring" between the agent and the outside world.

Where MCP is already used

Environment MCP role
Cursor Built-in and custom MCP servers: files, terminal, browser, third-party APIs
Claude Desktop Official connectors and community servers via claude_desktop_config.json
Zed, Continue, Cline MCP support to extend context in the editor
Enterprise agents Custom servers on internal APIs, ticket systems, wikis

The community ships ready-made servers: GitHub, Google Drive, Slack, Puppeteer, SQLite, Postgres, Brave Search, and hundreds more in registries such as modelcontextprotocol/servers on GitHub.

How to build or connect an MCP server

A minimal path for developers:

  1. Pick an SDK: official libraries exist for TypeScript, Python, C#, Java, and other languages.
  2. Describe tools and resources in server code (name, inputSchema, handler).
  3. Run the server with stdio or HTTP transport.
  4. Add config in the host (in Cursor - .cursor/mcp.json or IDE settings).

Example tool logic in Python (simplified):

@server.tool()
async def get_weather(city: str) -> str:
    """Current weather for a city."""
    return await weather_api.fetch(city)

On session start the host requests server capabilities; the model sees get_weather with a description and JSON schema for city.

Teams without custom dev often get by with a ready server from a registry plus config and secrets (API keys via env, not in the repo).

Limitations and what to watch

MCP solves integration standardization, but not:

  • model reasoning quality
  • orchestration of complex multi-step workflows (that's agent framework territory)
  • authorization between users (you need a separate OAuth/RBAC layer on the server)

In practice, consider:

  • Latency - each tool call is a round trip; chains of 10+ calls need time and token budgets.
  • Versioning - servers and hosts should align on spec version (2025-03 and newer are actively evolving).
  • Reliability - a down MCP server cuts off data access; production needs health checks and fallback.

MCP vs RAG vs custom APIs

Approach Strength Weakness
MCP Standard tools/resources for any host Requires MCP support in the client
RAG Search large corpora without loading everything into context No arbitrary actions (write, API mutate)
Custom API Full control Duplicate work for every AI client

Mature setups often use MCP + RAG: RAG for document knowledge, MCP tools for live queries to databases, tickets, deploys.

Summary

MCP is an open context protocol for AI agents: the host connects to servers, gets resources and tools, and the model invokes them through one contract. That lowers integration cost, makes scenarios portable between Cursor, Claude Desktop, and other clients, and gives clear data access boundaries.

A practical order for developers: start with community servers for your stack, then wrap internal APIs in your own MCP server when the same tools are needed across several host apps.

Frequently asked questions

How is MCP different from a regular REST API?

A REST API is a specific service interface for your HTTP calls. MCP is a protocol between the AI host and an "adapter" to such services: it describes how the host discovers tools, calls them, and reads resources in an agent-friendly format. One MCP server can wrap GitHub or Jira REST APIs; the host does not write a separate integration per product.

Do I need MCP if I only use one chat (e.g. ChatGPT)?

If your whole workflow lives in one closed product with built-in plugins - not necessarily. MCP pays off when you use several hosts (IDE + desktop + your own agent), want to reuse the same tools, or keep sensitive data on your server with explicit access control.

Is it safe to connect MCP servers to work data?

It depends on the server and configuration. Trusted community servers with open source, read-only access, and secrets via environment variables are a baseline. For production: separate process, least privilege, audit tool calls, and no agent write access without human approval.

Can I use MCP with local models (Ollama, LM Studio)?

Yes, if the host supports both MCP and your local provider. MCP is not tied to a cloud API - it supplies context and tools; the model can be local. The limit is on the host side: not all clients combine local LLMs and full MCP tool sets equally well.

How do I start setting up MCP in Cursor?

  1. Open MCP settings in Cursor (or .cursor/mcp.json in the project).
  2. Add a ready server from the docs (e.g. filesystem, GitHub) with launch command and env for tokens.
  3. Restart Cursor and check the server shows as connected.
  4. In the agent chat, explicitly ask to use a tool - confirm the call works and the result appears in the reply.

Next, add one custom server for your internal API - that teaches the full loop without rewriting integration logic for every tool.

Contacts