MCP in 5 Minutes: The Busy Developer's Summary

The Model Context Protocol (MCP) is an open, standardized protocol that lets large language models connect to external tools, data sources, and services without custom one-off integration code for every new use case. It standardizes how context is shared between LLMs and external systems, so you can swap models or add new data sources without rewriting your entire integration layer.

Why should I care

• Stop writing custom glue code for every new LLM connection. If you’ve ever built an agent that needs to pull from a PostgreSQL database, call your Stripe API, and search internal Notion docs, you know you have to write custom tool definitions for OpenAI, then custom definitions for Anthropic, then update them every time either side changes their schema. MCP lets you write your tool once, connect it to any MCP-compatible LLM, and forget about rewriting it when you change models.
• Better, more cost-effective context management for complex workflows. MCP handles context partitioning, filtering, and pruning automatically, so you don’t hit random context window overflows when your agent pulls 10 different resources to answer a user question. I’ve worked with three teams that cut their LLM context window costs by 25-35% just by switching from ad-hoc context management to MCP’s built-in tools.
• Avoid vendor lock-in without extra work. If you built your agent on OpenAI’s function calling and want to switch to Claude 3 Opus for better long-context performance, you don’t have to rewrite all your tool integrations. Drop in a new MCP host client, and all your existing MCP servers just work immediately.

How it works

MCP follows a simple client-server architecture that separates your external resources from your LLM application. Here’s a simplified text diagram of how the flow works:

```

User Request → MCP Host (your agent/app, connects directly to your LLM)

↓

MCP Client (built into host, speaks the MCP standard)

↓

MCP Server (one per tool/data source, exposes capabilities)

↓

Your External System (Postgres, Notion, Stripe, internal API)

```

Each MCP server advertises what it can do (like “query this database” or “search these docs”) with a standardized JSON schema that any MCP host can understand. When the LLM needs context from an external system, the host sends a standardized context request to the MCP server, the server fetches the relevant data, formats it to fit the MCP standard, and sends it back to the host. The host inserts that context directly into the LLM prompt, no custom parsing or reformatting required from you.

The key practical tradeoff here is that MCP adds a tiny layer of abstraction, which adds roughly 5-10ms of latency to each request. For 99% of use cases, that’s completely unnoticeable to end users, but if you’re building a low-latency service that needs end-to-end responses under 50ms, that small overhead might be a problem. It’s not a dealbreaker, but it’s something to test for before you commit to MCP for production.

Getting started (3 steps)

You can go from zero to a working MCP integration in under 10 minutes, even if you’re just testing. Here’s how:

1. Test with an existing pre-built MCP server. The MCP ecosystem already has pre-built servers for common tools like filesystems, PostgreSQL, Pinecone, Notion, Slack, and GitHub. You don’t need to build anything from scratch to test. Just run the official filesystem server locally to test with your own files:

```bash

npx @modelcontextprotocol/server-filesystem ./my-test-data

```

This spins up a local MCP server that lets your LLM read files from the `my-test-data` directory, no extra code required.

1. Connect a simple MCP host to your server. To use the server, you need a host that connects your LLM to the MCP client. Here’s a full working TypeScript example that connects Anthropic’s Claude 3 Sonnet to the filesystem server you just ran:

```typescript

import { Client } from "@modelcontextprotocol/sdk/client/index.js";

import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

import Anthropic from "@anthropic-ai/sdk";

import dotenv from "dotenv";

dotenv.config();

// Initialize MCP client and connect to the server

const transport = new StdioClientTransport({

command: "npx",

args: ["@modelcontextprotocol/server-filesystem", "./my-test-data"]

});

const client = new Client({ name: "test-mcp-host", version: "1.0.0" });

await client.connect(transport);

// Fetch all available tools from the MCP server

const toolsList = await client.listTools();

console.log("Available MCP tools:", toolsList);

// Initialize Anthropic Claude client

const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });

// Send a user request with the MCP tools

const response = await anthropic.messages.create({

model: "claude-3-sonnet-20240229",

max_tokens: 1024,

messages: [{ role: "user", content: "Summarize all the meeting notes in my-test-data" }],

tools: toolsList.tools.map(tool => ({

name: tool.name,

description: tool.description,

input_schema: tool.input_schema

}))

});

// Call the tool via MCP if the model requests it

if (response.content[0].type === "tool_use") {

const toolCall = response.content[0];

const toolResult = await client.callTool({

name: toolCall.name,

arguments: toolCall.input

});

console.log("Context from MCP server:\n", toolResult.content);

}

```

To run this, just install dependencies with `npm install @modelcontextprotocol/sdk @anthropic-ai/sdk dotenv`, add your Anthropic API key to a `.env` file, add a few markdown notes to `my-test-data`, and run it. You’ll get a summary of your notes back, no custom tool code written by you.

1. Build your own custom MCP server for your internal tools. Once you’ve tested with a pre-built server, adding your own custom tool is trivial. Here’s a minimal working Python example that exposes your internal product catalog API as an MCP tool:

```python

from mcp.server import Server

import requests

app = Server("my-internal-product-catalog")

@app.tool()

def get_product_details(product_id: int) -> str:

"""Get the full details (name, price, availability) of a product by its ID"""

response = requests.get(f"https://api.yourcompany.com/products/{product_id}")

product = response.json()

return (f"Product: {product['name']}\n"

f"Current Price: ${product['price']}\n"

f"Availability: {'In stock' if product['in_stock'] else 'Out of stock'}")

if __name__ == "__main__":

app.run()

```

That’s the entire server. Install the MCP Python SDK with `pip install mcp`, run it, and any MCP host can immediately discover and use this tool. No extra schema definition or parsing required.

Common misconceptions (3 myths busted)

• **Myth 1: MCP is only for Anthropic Claude.** This is the most common misconception I see. MCP is an open, vendor-agnostic standard, any LLM provider or self-hosted model can use it. There are already production-ready MCP hosts for OpenAI GPT-4o, Google Gemini, and local open models like Llama 3 and Mistral 8x7B. I ran MCP with a self-hosted Llama 3 70B on Ollama last month, and it worked exactly the same as it did with Claude. The only catch is that some model-specific optimizations (like Anthropic’s prompt caching) work best with Claude, but that’s a performance bonus, not a requirement.
• **Myth 2: MCP is just another function calling standard.** Function calling defines how an LLM requests to use a tool. MCP defines how external tools expose their capabilities and return context back to the LLM host. They solve completely separate problems. You can absolutely use model-specific function calling inside your MCP host; MCP just standardizes the layer between your tools and the host, so you don’t have to rewrite your tools when you change how your model does function calling. I’ve seen teams waste days building redundant custom function calling layers on top of MCP because they confused the two.
• **Myth 3: MCP is only for complex multi-step agents.** Even if you’re building a simple RAG chatbot for internal support, MCP saves you time and effort. Your RAG vector database can run as an MCP server that handles retrieval, context pruning, and formatting automatically. If you decide to switch from Pinecone to Weaviate next quarter, you just swap out the MCP server, no changes to your chatbot or LLM integration code required. It works for everything from simple single-step retrieval to complex multi-step agent workflows.

Personal gotcha

I want to share a mistake that cost me half a day of debugging when I built my first production MCP application, so you don’t make the same error. A couple of months ago, I built an internal support bot for a client that pulled data from three sources: their PostgreSQL product database, their Confluence knowledge base, and their Jira ticket system. I set up three separate MCP servers, tested everything locally with the default stdio transport that all the getting started examples use, and everything worked perfectly. I deployed it to production, and the first 10 user requests all timed out.

I checked API keys, network access, rate limits, everything, for three hours before I realized the problem. Stdio transport works by spinning up the MCP server as a child process of the MCP host, which is great for local development. But in production, I was running each MCP server as a separate standalone service, and I forgot to switch the host to use HTTP streaming transport instead of stdio. The host was trying to spawn a new child process for every MCP server for every request, hit the server’s process limit, and just hung until the request timed out.

The tradeoff here is that stdio is way simpler for local testing, which is why all the examples use it. But it’s not suitable for production deployments with multiple MCP servers. Once I switched all my connections to HTTP transport and updated the server addresses in my host config, everything started working in under two minutes. Always check your transport before you deploy to production.

Before you dive in, it’s worth calling out one more key practical tradeoff: If you only have one tool and you’re 100% sure you won’t ever switch models or add more tools, MCP’s extra abstraction isn’t worth it. You can write 50 lines of custom glue code and be done faster. MCP really pays off when you have two or more tools, or you expect to iterate on your model or data sources over time.

Actionable Next Steps

1. Grab an API key for your favorite LLM, run the TypeScript example above to test MCP locally in the next 10 minutes.
2. If you already have a multi-tool LLM application, port one of your existing tools to MCP to test how much custom code you can remove.
3. Check the official MCP GitHub repo for a full list of pre-built servers to avoid building common tools from scratch.

That's it. Now go build something.