Every time you see "MCP server" in an AI tool's settings, what you are really looking at is a small HTTP conversation. Underneath all the marketing, MCP is just a set of rules for how an AI app and an external service talk to each other, and those rules are written in JSON-RPC 2.0. This guide reads that conversation line by line, using IPIPAI's MCP endpoint as the example.
The One Big Idea
MCP (Model Context Protocol) standardizes one thing: giving an AI model access to tools and data that live outside the model. Before MCP, every integration was custom — one plugin shape for one app, another for another. With MCP, a server exposes a standard list of "tools," and any client that speaks the protocol can discover and call them. The server does not care whether the client is Claude, Cursor, or a script you wrote at 2 AM.
JSON-RPC 2.0 in One Paragraph
JSON-RPC 2.0 is a request/response protocol where every message is a small JSON object. A request has three parts: jsonrpc: "2.0", a method name, and an id you choose. The response comes back with the same id so you always know which request it answers. No streams, no state, no ceremony. If you can read JSON, you can debug it with your eyes.
The Handshake: initialize
The first thing any MCP client does is introduce itself. It sends an initialize request:
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": {},
"clientInfo": { "name": "my-client", "version": "1.0" }
}
}The server replies with its name, version, and the protocol version it supports. Once both sides agree, the client sends notifications/initialized and the session is ready. Nothing clever happens here — it is the "hello, I support these things, you?" of the protocol.
Discovering Tools: tools/list
Next, the client asks what is actually available:
{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }IPIPAI's server answers with an array of tool definitions, each containing a name, a description, and a JSON Schema describing the arguments it expects. For example, lookup_ip takes an ip string and an optional lang. You can see the exact same list, in a browser-friendly form, at /mcp-tools.json. The client renders this list into the tool choices an AI model sees.
Running a Tool: tools/call
When the model decides to use a tool, the client sends a tools/call request:
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "lookup_ip",
"arguments": { "ip": "8.8.8.8", "lang": "en" }
}
}The server executes the lookup and returns a structured result inside a content array. The client hands that content back to the model, which can then reason over the live data. That is the whole magic trick: one POST, structured JSON in, structured JSON out.
Errors Look Like Normal Responses
One thing that surprises people: failures are not HTTP errors. A request that fails still returns HTTP 200 with a JSON-RPC error object containing a code and a message. That is deliberate — it keeps error handling uniform across clients. When you debug, read the error field in the body, not the HTTP status.
Why Bother Learning This?
Because the same three messages — initialize, tools/list, tools/call — appear in every MCP integration you will ever touch. Once you can read them, "connect my AI tool to IPIPAI" stops being a configuration mystery and becomes a five-line curl command. If you are setting one up right now, the connection guide walks through Claude, ChatGPT, and Cursor specifically, and how AI models call IP tools shows the model's side of the conversation.
Wrapping Up
MCP is not magic, it is structure: a fixed handshake, a tool catalog, and a call/response loop, all expressed as JSON-RPC 2.0. If you can follow one request from your client to IPIPAI's /mcp endpoint, you understand the protocol well enough to build on top of it. The tools themselves are cataloged at /mcp-tools.json, and the rest of the toolkit lives on the IPIPAI articles page.