Every MCP session moves through the same five steps. The client initialises a connection, discovers what the server can do, negotiates the shared capability set, invokes individual tools or resources, and waits for typed responses.

1. 1

   Initialize

2. 2

   Discover

3. 3

   Negotiate

4. 4

   Invoke

5. 5

   Respond

MCP carries its JSON-RPC payload over one of three transports. Pick based on whether the server runs locally with the client, as a daemon, or on the edge.

MCP is JSON-RPC 2.0 with a small set of well-known methods. Here is a typical tools/list exchange:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "posts.create",
        "description": "Create a new WordPress post",
        "inputSchema": { ... }
      }
    ]
  }
}

Three primitives, three jobs:

• Tools — verbs 14
• Resources — data 8
• Prompts — recipes 5

During the initialize step, server and client exchange a capability map. The client learns what verbs the server exposes; the server learns which features the client supports (sampling, roots, log levels, progress notifications).

A single user prompt usually triggers a small graph of tool calls. The agent plans, calls a tool, reads the response, optionally fetches a resource, calls another tool, and finally returns text to the user. Every step is logged and replayable.

Without MCP, every AI integration is bespoke — a custom prompt, a custom JSON shape, a custom auth flow per client. MCP collapses that into a single typed protocol so the WordPress server you build once works in Claude, ChatGPT, Cursor, and every future client.