Introduction to Model Context Protocol

The Island Problem

Here’s what nobody tells you about building AI agents: the model is the easy part. Getting it to talk to your actual data, your actual tools, your actual systems that’s where most projects die.

LLMs know a lot about the world. They’ve read the internet. They can write code, analyze documents, even tell you a joke. But they can’t see your calendar. They can’t query your database. They can’t send an email through your company’s API. They’re smart but stuck on an island.

And until recently, bridging that island was painful. Every integration was custom code, custom auth, custom prompts that barely held together. You built one connector and prayed the API didn’t change, the model didn’t change, or your requirements didn’t change. Usually all three changed anyway.

Enter MCP

Model Context Protocol is an open standard that fixes this mess. Instead of writing one-off integrations for every AI-tool combination, you write an MCP server once. Any compatible AI client can connect to it.

Think USB-C, but for AI. You plug in, it works.

The Math Problem (and Why Your Integrations Cost So Much)

Before MCP, if you had four AI models (Claude, GPT-4, Gemini, local Llama) and six company systems (Drive, storage, logs, SQL, calendar, documents), you had a problem:

4 AI models × 6 systems = 24 custom integrations

This is the N×M problem. Here’s how it plays out in practice:

1. Glue code everywhere: Every new model means rewriting connections for every system
2. Maintenance nightmare: One API change breaks everything at once
3. Vendor lock-in by accident: Switching models costs months of work
4. Inconsistent security: Twelve integrations with twelve different credential patterns

MCP flips the math. Now it’s:

4 AI models + 6 systems = 10 components

You change models, your integrations stay intact. You change systems, your AI clients stay intact. The contract between them is stable.

How It Works

Three pieces:

MCP Host: The AI app. Claude Desktop, Cursor, your custom agent.

MCP Client: Lives inside the host. Handles the protocol.

MCP Server: Your adapter. Exposes your database, your API, your files through MCP.

┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│   AI Host   │◄────►│ MCP Client │◄────►│ MCP Server  │
│  (Claude)  │      │   (SDK)    │      │  (Adapter) │
└─────────────┘      └─────────────┘      └─────────────┘
                                               │
                                               ▼
                                        ┌─────────────┐
                                        │ Your Data  │
                                        │(SQL, API, │
                                        │ Files)    │
                                        └─────────────┘

Three primitives matter:

Resources: Data the AI can read. Tables, files, API responses. Exposed as URIs.

Tools: Actions the AI can call. Defined with JSON schemas. The model picks the tool, MCP handles execution.

Prompts: Template prompts the server provides. Consistent patterns like “summarize this” or “analyze that.”

Communication is JSON-RPC 2.0 over stdio or HTTP/SSE. Auth is transport-level, not protocol-level.

What It Actually Feels Like

Picture a movie ticket booking scenario:

1. User: “Book tickets for tonight.”
2. AI queries the Movie Server: what can you do?
3. Server: “Browse movies, check seats, process payments.”
4. AI: “Show 7 PM seats.”
5. Server: “Rows B and C available.”
6. AI: “C5, confirm.”
7. Server: “Payment processed. Confirmed.”

The AI didn’t have the movie API hardcoded. It discovered capabilities through MCP and figured out the flow. That’s the difference.

Why It Matters

We built an MCP server for a Salesforce connection in one day with the Python SDK. The same integration took three weeks on a previous project using custom API code. That’s not hyperbole. That’s what happens when you stop writing boilerplate and start writing business logic.

Three reasons to care:

1. Speed: Weeks to days per integration
2. Model flexibility: Swap models without rewriting tools
3. Security boundaries: One audit per server, not twelve custom integrations

Alternatives

Not the only path:

Direct API integration: Fine for 1-2 integrations. Gets messy at scale. You’re coupling your agent to specific APIs permanently.

LangChain/LlamaIndex: Has tool abstractions. If you’re already using them, MCP might feel redundant. The abstractions differ across frameworks though, which hurts portability.

Model-specific function calling: OpenAI’s, Anthropic’s. Works out of the box but locks you to that provider.

We picked MCP because one client needed to evaluate three models in parallel. The tool layer stayed identical across all three. Try doing that with function calling.

Where It Falls Short

MCP is young. Be honest about that:

• SDKs: Python, TypeScript, Go exist. Others are experimental.
• Discovery: Manual configuration. No registry yet.
• Auth: Complex flows (OAuth2, mTLS) need custom work.
• Scale: Not battle-tested the way REST APIs are.

The protocol is solid. The ecosystem is still growing. Budget integration time if you’re evaluating for production.

How to Try It

Claude Desktop is the fastest demo. File system and GitHub servers work out of the box.

For enterprises:

1. List every data source your agent needs
2. Group by auth type (API keys, OAuth, database credentials)
3. Build one MCP server per group
4. Test tool discovery separately

Spec is at modelcontextprotocol.io. Python SDK is mcp[dev] on PyPI.

The Takeaway

We standardized cables with USB. We standardized networking with TCP/IP. AI integration was due for the same treatment.

MCP won’t fix your grounding problem or your prompt quality issues. But it makes adding tools declarative instead of architectural. That matters when you’re shipping AI agents faster than your integration layer can keep up.

If you’re building agents and the glue code is the bottleneck, MCP is worth your time.

This article originally appeared on lightrains.com