MCP No Server Info Found: Fix the Initialize Response in Cursor
No server info found means the client never retained a valid initialize result containing server identity and capabilities, even if the process appears to run.
If Cursor says “No server info found,” inspect the raw MCP initialize exchange first. The server process may be running, but Cursor has not retained a valid JSON-RPC result with server identity and capabilities. Check framing, matching request ID, serverInfo, protocolVersion, capabilities, and the follow-up initialized notification in that order.
Table of contents
- What Cursor is missing
- Check the initialize response
- Stdio framing and startup races
- Version and capability mismatches
- Cursor-specific isolation
- Verification checklist
- FAQ
What Cursor is missing
Cursor is missing a valid initialize result, not necessarily a running server. The handshake provides the server identity, protocol version, and capability map required before the client can list offerings.
This explains why the message can appear while a terminal still shows the server process running. Process launch proves only that something started; it does not prove that the MCP transport delivered a valid JSON-RPC response.
At the protocol layer, Cursor sends an initialize request and expects a response with the same request ID. The response must contain a valid result or error object under the JSON-RPC envelope defined in the JSON-RPC 2.0 specification.
At the MCP lifecycle layer, the client sends an initialized notification after successful initialization. If the response is missing, malformed, mismatched, or rejected, Cursor may never retain server information or proceed to list tools. The MCP client glossary explains the distinction between client, server, and transport.
Start with the handshake, not individual tools. A failed tool call is downstream evidence and cannot repair a missing server identity.
Check the initialize response
The fastest diagnostic path is to capture the exact exchange and verify the envelope, ID, result shape, server identity, protocol version, capabilities, and lifecycle notification.
| Check | What to confirm | Failure implication |
|---|---|---|
| JSON-RPC envelope | The response is a JSON-RPC response and its id exactly matches the request | Cursor cannot associate it with initialize |
result | The response contains a result rather than an error | Initialization failed |
serverInfo | Server identity is present in the expected object shape | The client may have no identity to retain |
protocolVersion | The value is supported by both client and server | Version negotiation may be rejected |
capabilities | The value is a valid capability object | Cursor may discard the result |
initialized | The client sends the notification after the response | The lifecycle sequence is incomplete |
The request ID must match exactly, including its type. A response with correct-looking fields but a different ID is unrelated from the client’s perspective.
Preserve the raw request, response, stderr, and process exit status. A prettified log may remove line boundaries or hide errors. The MCP initialization specification defines the exchange Cursor must complete before normal operation.
Do not begin by editing tool definitions. First establish that the response is structurally valid, semantically acceptable, and followed by initialized.
Stdio framing and startup races
Stdio failures often come from extra stdout, delayed startup, immediate exit, or competing readers. The protocol stream must remain separate from human-readable diagnostics.
A startup banner, debug line, progress message, or accidental serialization on stdout can be interpreted as an MCP message. Send diagnostics to stderr and reserve stdout for protocol traffic, as described in the MCP transport specification.
Timing can produce the same symptom. A server that takes too long to become ready, exits after launch, or writes its response only after an initialization failure may appear present without completing the exchange.
Competing readers are another possibility. A wrapper, logger, shell integration, or second process may consume the response first, leaving Cursor with an incomplete stream even though the server produced valid data.
Use this narrow diagnostic sequence:
- Capture stdout and stderr separately.
- Confirm the first protocol exchange is Cursor’s
initializerequest. - Confirm the response is not preceded by unrelated output.
- Check that the process stays alive through the response and
initialized. - Repeat with the same command and environment after a cold launch.
- Change one layer at a time and preserve every result.
Do not weaken security to hide the symptom. Keep authentication and certificate verification enabled while diagnosing; a connection that works only after security checks are removed is not a completed fix. The MCP debugging guide recommends collecting transport and protocol evidence before drawing conclusions.
Version and capability mismatches
A syntactically valid response can still be rejected when its protocol revision or capability map is incompatible. Valid JSON is necessary, but it is not sufficient if the values violate the MCP lifecycle contract.
The protocolVersion value participates in initialization negotiation. Compare the exact revision emitted by the server with the revision accepted by the Cursor integration. Do not assume that any MCP-looking string is valid.
Then inspect capabilities as a structured object. A string, array, null value, misspelled capability, or incorrectly nested member can make the result unusable even when the surrounding JSON parses correctly.
The same applies to serverInfo. It must be an object with the expected identity fields, not a log message, display label outside result, or metadata attached at the wrong level.
Make one controlled change at a time:
- Correct the response envelope and matching ID.
- Correct the protocol revision.
- Correct
serverInfo. - Verify the capability map against features the server actually exposes.
Do not declare capabilities merely to make the UI advance. A false capability can move the failure into tool discovery or invocation. The lifecycle contract is a better reference than a guessed response shape.
Cursor-specific isolation
The most useful client comparison is Cursor versus MCP Inspector using the same command and environment. Hold the transport, working directory, environment variables, authentication context, and startup path constant.
MCP Inspector provides an independent way to inspect initialization and available operations. If both Cursor and Inspector fail, focus on server framing, response structure, version, and capabilities.
If Inspector succeeds while Cursor reports no server info, compare launch details before declaring a Cursor defect. Different environment variables, executable paths, working directories, wrappers, or authentication contexts can change the bytes Cursor receives.
A Cursor forum report about the same “No server info found” symptom may reveal a related pattern, but it cannot replace your own raw exchange. Preserve evidence from both clients and compare the first divergent message.
MCPtrove’s guide on how to test an MCP server offers a repeatable comparison path. The goal is isolation: determine whether the defect occurs before the server responds, in the response itself, or in Cursor’s handling of an otherwise valid exchange.
Verification checklist
A complete fix survives a cold restart and consistently shows tools after initialization. The final test must verify the lifecycle, not merely that a process appears in a task list.
Use this checklist:
- Save the raw
initializerequest and response. - Confirm the response ID matches the request ID exactly.
- Confirm
result.serverInfo,result.protocolVersion, andresult.capabilitiesare correctly shaped. - Confirm stdout contains protocol messages only and diagnostics are separate.
- Confirm the server stays alive through
initialized. - Compare the same launch in Cursor and Inspector.
- Fully restart Cursor and repeat without relying on cached state.
- Confirm tools appear consistently after initialization.
For the practical next step, run the configuration through MCPtrove’s Config Doctor, then compare it with the Cursor MCP setup guide. Preserve each diagnostic result, change one layer at a time, and keep security verification intact.
The decisive signal is not “the process started.” It is a valid initialize response accepted by the client, followed by initialized and stable tool discovery.