July 2, 2026 · 7 min read
MCP — the Model Context Protocol — is showing up in every AI tool conversation. Claude supports it. Cursor supports it. There's a growing ecosystem of servers you can plug in. But the explanations are usually written for people who already know what it is. This one isn't.
An LLM by itself can only work with what's in the conversation — the messages you've sent, the context window. It can't read files on your computer. It can't query a database. It can't call an API. It just generates text based on what it knows.
Tools change that. When you give Claude a tool — say, "search the web" or "run this code" — Claude can call that tool as part of generating its response, use the result, and continue. This is what makes AI agents actually useful for real tasks.
MCP is a standard for how those tools are defined and how an AI client (like Claude Desktop or Cursor) connects to them. Before MCP, every tool was bespoke. After MCP, there's a common protocol — one format, one connection method, works across clients.
An MCP server is a program that exposes tools — functions the AI can call. The server runs locally (or remotely over HTTP) and handles the actual execution. The AI client connects to it, gets a list of available tools, and can call them during a conversation.
A tool definition looks roughly like this:
{
"name": "ask_site",
"description": "Query an indexed website by domain and question",
"inputSchema": {
"type": "object",
"properties": {
"domain": { "type": "string" },
"question": { "type": "string" }
},
"required": ["domain", "question"]
}
}The AI sees this definition, decides when to call it, constructs the arguments, and the MCP server handles execution and returns a result.
There are two transport modes in MCP: stdio and HTTP with SSE (server-sent events).
stdio — The AI client starts the server as a subprocess and communicates via stdin/stdout. This is the most common setup for local tools. When you add an MCP server to Claude Desktop via npx, it's using stdio.
HTTP + SSE — The server runs as an actual HTTP server (local or remote). The client connects over HTTP. This is how remotely-hosted MCP servers work — and it's what AgentReady uses under the hood. The npm package is a lightweight stdio bridge that forwards to our hosted Next.js server.
AgentReady exposes three tools:
submit_site(url) — crawls and indexes a website. Call this once per site, or let ask_site do it automatically.
list_sites() — returns all indexed sites with their summaries. Useful for knowing what's available.
ask_site(domain, question) — runs a semantic search over the indexed content for a domain and returns a cited answer. This is the main tool.
Before MCP, if you wanted to build a tool for Claude you'd build a Claude plugin. For Cursor you'd build a Cursor extension. For each client, a separate integration. MCP collapses that — build the server once, works everywhere that speaks MCP.
The ecosystem is growing fast. There are now hundreds of MCP servers on GitHub: databases, file systems, code execution, search, calendars, GitHub, Slack. The pattern is the same for all of them: a server exposes tools, clients connect, the AI uses the tools.
Build an MCP server if you have data or actions that would be useful to AI agents in your users' workflows. A few good candidates:
— Your product's API, exposed as tools so Claude can call it directly.
— Your docs, indexed and queryable (this is what AgentReady does for you).
— Internal data sources (databases, internal APIs) for company-internal AI agents.
The protocol is simple. Anthropic has SDKs for TypeScript and Python. The hardest part is usually deciding what tools to expose, not implementing the protocol itself.