MCP (Model Context Protocol): How to Connect AI to Your Data

The Model Context Protocol (MCP) is the open standard Anthropic released to solve a long-standing problem for anyone building with LLMs: how to connect models to real data (files, databases, APIs, SaaS) without writing a custom connector for every source. Instead of reinventing integration each time, MCP proposes a JSON-RPC contract between clients (Claude Desktop, Cursor, VS Code, in-house tools) and servers (any process that exposes resources, prompts, or tools). This guide explains the protocol in practice, shows use cases tested in production, and details how to build your own server.

I have been using MCP almost every day for over eight months, since I installed my first official filesystem server inside Claude Code in August 2025. I started with only two local servers: filesystem and sqlite. Today my setup has seven active servers running via stdio and SSE, including a custom MCP I wrote in TypeScript to expose jobs on my Kubernetes cluster. The most concrete gain was replacing three Python scripts that copied context into the prompt with a single server the model queries on demand. I save 15 to 25 minutes per pair programming session and, more importantly, the model now has a consistent source of truth instead of depending on screenshots pasted into the chat window.

The problem MCP solves

Before MCP, every AI tool had its own plugin mechanism. OpenAI had ChatGPT plugins, then actions for custom GPTs. Anthropic had tools via API. Microsoft had skills in Copilot. Every code editor that wanted to integrate an LLM had to manually map local commands. The result was fragmentation: the same Postgres connector got rewritten ten times across ten stacks, each with its own bugs and limitations.

Anthropic announced MCP in November 2024 as an open protocol inspired by the Language Server Protocol (LSP) that Microsoft popularized for code editors. The analogy is exact: LSP turned the N×M matrix (N editors × M languages) into a sum N+M; MCP does the same for (AI clients × data sources). Once your client speaks MCP and your server speaks MCP, they understand each other, regardless of who wrote them.

How MCP works under the hood

The protocol is defined at modelcontextprotocol.io and the full specification is versioned on GitHub. At a high level MCP defines three entities: hosts (the user process, usually an AI client), clients (the layer inside the host that speaks MCP), and servers (processes that expose capabilities). Communication uses JSON-RPC 2.0 over two transports: stdio (local server, launched as a child process) and HTTP+SSE (remote server, useful for SaaS and enterprise environments).

The three capability types

Every MCP server can expose three families of resources: Resources (passive data read by the model, such as files, database rows, URLs), Tools (functions the model can call, like "run query" or "create issue"), and Prompts (reusable templates the user explicitly invokes via slash command). This separation matters: tools are for model-controlled actions, prompts are for human-controlled actions, resources are for pure context.

Handshake and discovery

When the client connects, it sends an initialize message declaring its capabilities and protocol version. The server responds with the list of supported capabilities. From there the client can call tools/list, resources/list, and prompts/list to discover what the server offers. Discovery is dynamic: a server can add tools at runtime and notify the client via notifications/tools/list_changed.

Official and ecosystem servers

Anthropic maintains the modelcontextprotocol/servers repository with reference implementations. These servers were my entry point and remain the most stable part of my stack. The table below summarizes the ones I use most.

Cloudflare published a guide on how to package Workers as remote MCP servers with OAuth authentication, and that has been the cleanest path for exposing internal company tools without distributing local binaries across the team.

Real use cases I have tested

1. Pull request review inside the editor

With the GitHub server configured in Claude Desktop, I say "pull the files changed in PR #482 and comment on anything concerning". The model calls get_pull_request_files, reads the diff, and cross-references the code in my local checkout via the filesystem server. This combination of two servers in the same conversation is what makes MCP interesting — each server does one thing well, and composition emerges from the model deciding which to call.

2. Production incident triage

The Sentry MCP server exposes tools like get_issue, list_events, and search_issues. When I get an alert, I open Claude Code, ask "what happened in the 2pm deploy?", and it queries Sentry, filters by time window, grabs the most recent stack trace, and suggests the culprit commit via git blame on the filesystem server. Cut my MTTR from 12 to 4 minutes across a sample of 30 incidents.

3. Exploratory data analysis

Postgres server plus local dataset. I ask business questions ("how many active users among those who signed up in March paid for at least one subscription?") and the model writes the SQL, runs it, returns a result, and refines if noise appears. The critical detail is that the official postgres server runs read-only — I never had to worry about an accidental DROP TABLE.

4. Live documentation

I wrote an MCP server that reads OpenAPI files from our monorepo and exposes list_endpoints and get_endpoint_schema as tools. When I build a new client, I ask "generate the typescript client for /v2/invoices" and the model fetches the live schema instead of hallucinating field names. That alone eliminated a whole class of bugs where client and server diverged on field names.

How to build an MCP server from scratch

The official documentation at docs.anthropic.com/claude/docs/mcp has tutorials in Python and TypeScript. My recommendation for newcomers: use the official TypeScript SDK (@modelcontextprotocol/sdk), because the type ecosystem helps validate tool schemas at compile time.

Minimal skeleton

A viable server needs: an initialize handler, a tool registry with JSON Schemas, and a loop that listens on stdio. The SDK handles JSON-RPC dispatch and validation. Your job is to write the functions that actually do the action — read a file, query an API, compute something. Every tool must have a clear natural-language description: that description is what the model reads to decide when to call the tool.

Common beginner mistakes

First: vague tool descriptions. If you write "runs SQL query", the model will call your tool for any question remotely involving data. Write "runs read-only SELECT against the analytics database containing tables X, Y, Z" and the model only calls it when the question fits. Second: forgetting to sanitize inputs. The model can pass any string to your tool; validate as if it were public API input. Third: exposing too much. A filesystem server without a directory whitelist is a huge security risk — the official server forces you to declare allowed paths at initialization for a reason.

Authentication for remote servers

For HTTP+SSE servers, MCP standardizes authentication via OAuth 2.1 with PKCE. This became officially supported in early 2025 and solves the problem of how a local client (Claude Desktop on the user's machine) authenticates against a corporate server without distributing secrets. The flow is the same that mobile apps use to access Google or GitHub APIs — the user opens a browser, authenticates, and a token is returned to the client.

Honest limitations

It is not all roses. MCP has three bottlenecks I hit in practice. First, context overhead: listing many tools consumes tokens just describing what is available, and with more than 40 simultaneous tools the model starts picking wrong. My rule of thumb: stay under 20 active tools per session. Second, stdio transport limits distribution: local servers require the user to install something, which works well for developers but is real friction for end users. Third, debugging is still immature — when a tool fails silently, tracking whether the problem is in the server, the client, or the model's interpretation requires logs in three places.

Conclusion

After eight months running MCP in personal production, my opinion is that it will be the dominant standard for integrating LLMs with data. Not because the protocol is technically genius — JSON-RPC over stdio is trivial — but because Anthropic opened the spec early, documented it well, and OpenAI, Google, and Microsoft started converging on a unified standard instead of each one having its own. If you are building an internal AI tool at your company, starting with MCP now is the safest bet: you get compatibility with Claude Desktop, Cursor, VS Code, Zed, and any future client that adopts the standard, without rewriting connectors. If you are still writing proprietary wrappers to plug an LLM into your internal APIs, stop and migrate. Migration cost is low and the lock-in you avoid is huge.