When a new MCP server is added in Cursor, the first interesting thing is not a tool call. Cursor starts by probing the server shape, negotiating the MCP session, and discovering what the server exposes. The screenshots below capture that startup sequence for a simple local PyMCP server over Streamable HTTP.
This trace uses the published MCP lifecycle specification version 2025-11-25 as the reference point. That lifecycle still defines three phases: initialization, operation, and shutdown. Initialization is where the client and server agree on protocol version, exchange capabilities, and share implementation details. After the server answers initialize, the client sends notifications/initialized before normal operation begins.
The first two requests are probes against standard OAuth protected-resource metadata endpoints:
/.well-known/oauth-protected-resource/mcp
/.well-known/oauth-protected-resource
Both return 404 Not Found in this run. For this local unauthenticated server, that is expected: the server is not exposing OAuth metadata. Cursor then opens the MCP session with initialize.
In the observed initialize request, Cursor identifies itself as:
{
"name": "cursor-vscode",
"version": "1.0.0"
}
It also advertises client capabilities, including elicitation, roots, and an extension capability for MCP UI/App-style content:
io.modelcontextprotocol/ui
text/html;profile=mcp-app
That is the important signal in this trace: Cursor is not just asking for tools. It is announcing capability-level support for richer MCP UI/App content negotiation.
After the server responds to initialize, Cursor sends:
notifications/initialized
That marks the end of the handshake and the start of normal MCP operation.
Once initialized, Cursor immediately performs discovery:
resources/list
tools/list
resources/list
prompts/list
resources/subscribe
The duplicate resources/list is visible in the trace. Cursor first reads available resources, then tools, then resources again, then prompts. Finally, it subscribes to the resource:
memo://welcome
The server responds with a resource named welcome_memo, several tools, and a prompt template. At this point Cursor has enough inventory to decide what it can show or call in the client.
After discovery, user or client activity can produce normal operation requests. In this screenshot Cursor calls:
tools/call
The tool is addNumbersTool, with arguments a = 5 and b = 6. The server returns a JSON-RPC result containing:
Sum of 5 + 6 = 11
That shows the request has moved out of startup discovery and into ordinary MCP operation.
The last screenshot shows two useful follow-up behaviors. First, Cursor sends:
ping
The server returns an empty result, confirming the session is still alive. Then Cursor calls another tool:
multiplyNumbersTool
The response contains:
Product of 4 x 7 = 28
So the complete observed startup and early operation flow is:
OAuth metadata probe
initialize
notifications/initialized
resources/list
tools/list
resources/list
prompts/list
resources/subscribe
ping
tools/call
The final client connection complete log means Cursor stopped sending startup discovery requests after the initial MCP session setup. From a server author's point of view, this is a useful baseline: do not treat the OAuth metadata probes as failures, do not assume tools/list is the first MCP method you will see, and expect clients to discover resources and prompts even when the feature you care about is tool calling.
The lifecycle details may continue to evolve through the MCP SEP process. Until the published spec changes, servers should still implement initialization, capability negotiation, notifications/initialized, and transport-level shutdown behavior according to the current lifecycle document.