How MCP works

A 3-section primer for visitors who haven't worked with MCP before.

What problem MCP solves

Before MCP, every AI client (Claude Desktop, ChatGPT, Cursor) needed a hand-built integration for every tool or data source. Each integration was a one-off: different auth, different request shape, different response shape, different way of describing what the tool did. The result was that most agents had access to a tiny set of tools — whichever ones their vendor had pre-integrated.

The Model Context Protocol standardizes that interface. A tool server speaks one protocol — JSON-RPC over either Streamable HTTP or stdio — describing its tools in a fixed shape. Any MCP-aware client can use any MCP-aware server. The full spec lives at modelcontextprotocol.io.

How a request actually moves

Concretely, here's what happens when a teacher asks their agent to find K-12 standards related to fractions, and the agent decides to call list_standards:

The request body that crosses the wire (truncated):

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "list_standards",
    "arguments": { "query": "fractions, grade 4", "limit": 5 }
  }
}

The response is the same shape with the tool's result inside result.content. No magic — just plain JSON-RPC.

Why we picked it

Who Knows What is infrastructure for ASU Prep teachers using AI tools. We don't want to build a new web app — we want our standards corpus to be reachable from any AI tool a teacher already uses, today and a year from now. MCP gives us that. The corpus is the product; the surface is whatever the teacher's already using.

We use Streamable HTTP transport (not stdio) because we host the server on Vercel — anyone with a token can connect from anywhere. Stdio would force teachers to run the server locally, which we don't want.