Qdrant MCP: -32602 Invalid request parameters in Cursor (stale client connection

Not specified by the original author.

TL;DR: -32602 Invalid request parameters in Cursor, while the same server works in tests, is a stale client connection. Cursor cached the old schema or connection. Restart Cursor, or reload the Qdrant server entry in Cursor's MCP settings.

MCP error -32602: Invalid request parameters

Fix it

1. In Cursor, open Settings, navigate to MCP Servers, and reload or reconnect the Qdrant server entry.
2. If that does not clear it, fully quit and restart Cursor. MCP connections initialize at client startup.

3. Retry the tool call.

   Expected: the -32602 error is gone and tools execute normally.

When to use this

• The server works when tested directly (stdio test, inspector) but fails in Cursor with -32602.
• The error appeared right after you changed the server config or updated the server.

When NOT to use this

• The error happens everywhere, including direct tests. Then the request parameters genuinely are invalid. Check the tool schema.
• The error is -32603. That is a server-side failure, different problem.

Compatibility

• Any MCP server used through Cursor, including qdrant/mcp-server-qdrant.

Why it happens

MCP clients cache the tool list and schemas from when they first connected. If the server restarts with a changed schema (or the connection goes stale), the client keeps validating calls against the old schema and rejects them with -32602 before they ever reach the server. Reconnecting forces a fresh tools/list.

Edge cases

• If you run the server from source and rebuild often, expect this regularly. Reconnect after each rebuild.
• Multiple Cursor windows can hold different cached schemas. Restart all of them.
• The same staleness affects Claude Desktop and other clients. The fix is always: reconnect or restart the client.

The mcp-qdrant-custom troubleshooting guide (cedriccmh/mcp-qdrant-custom docs/TROUBLESHOOTING.md) documents this exact issue: Cursor MCP Tool Error with symptom MCP tool works in tests but shows error in Cursor, Error: MCP error -32602: Invalid request parameters. The listed causes are Cursor caching the old connection, the server restarted but Cursor not reconnected, or schema mismatch between Cursor and server. The fix is restarting Cursor to refresh the MCP server connection, or reloading/reconnecting the Qdrant server in Cursor settings. Source: https://github.com/cedriccmh/mcp-qdrant-custom/blob/HEAD/docs/TROUBLESHOOTING.md

Not specified by the original author.

TL;DR

Assume a unique stable ordering key; otherwise use a stable composite key in both the query and cursor. Check token format, authentication tag, version, and expiry; then compare its bound scope, resource, normalized filters, direction, page-size policy, and snapshot with the current request. The client should clear its cursor when the selected resource, filters, or direction changes.

When to use

You are seeing this: Authorize the initial request, normalize every query-affecting filter and default, and choose a server-issued snapshot. Use this skill when you run into "Bind backward pagination cursors to request context".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Use this when an API selects older records in descending order with a one-row lookahead, returns each page chronologically, and accepts a user-controlled continuation token. Assume a unique stable ordering key; otherwise use a stable composite key in both the query and cursor.

Preserve the page boundary

Fetch the requested page size plus one in descending order. The extra oldest row establishes whether another page exists but is not returned. Reverse the retained rows for presentation. When another page exists, the next cursor carries the oldest retained ordering key, not the lookahead row. The following query uses a strict older-than predicate.

Issue an opaque authenticated cursor

Authorize the initial request, normalize every query-affecting filter and default, and choose a server-issued snapshot. Store the authorization scope, resource binding, canonical filter fingerprint, direction, snapshot reference, retained boundary key, token version, and expiry in server-side cursor state. Give the client a random handle with a server message authentication code. The handle reveals no internal resource or row identifiers. A standard authenticated-encrypted stateless token is an alternative, but a plain signed readable payload is not confidential.

Bind the page size too if changing it during traversal is disallowed. Sign with a managed key and allow bounded key rotation. Limit token length and lifetime. A token is a continuation hint, never an authorization grant.

Validate before any page query

Authenticate the caller and reauthorize access to the requested resource. Check token format, authentication tag, version, and expiry; then compare its bound scope, resource, normalized filters, direction, page-size policy, and snapshot with the current request. Reject a mismatch or invalid token using one generic invalid-cursor response. Do not echo the token, internal identifiers, or which comparison failed. Do not build a data query from unverified fields.

The client should clear its cursor when the selected resource, filters, or direction changes. If an old cursor is nonetheless sent and rejected, restart from a fresh first page and snapshot rather than silently repurposing it.

Define snapshot semantics explicitly

For immutable append-only records with immutable filter membership, a first-page high-water ordering key can exclude later inserts. It is not a full snapshot if records may be edited, deleted, or move into or out of filters. In that case use a database-supported as-of version or equivalent immutable view, and reject expired snapshot references.

Basis

This combines the exclusive older-than ordering invariant with a trust-boundary analysis of user-controlled cursors. It is design reasoning only; no code was run or inspected and no runtime tests were executed.

Reasoned analysis of exclusive keyset boundaries and untrusted-token replay across request contexts. No runtime tests, repository inspection, or configuration inspection were performed.

Rationale: The prior guidance selected the correct page boundary but did not prevent a valid cursor from being replayed against another resource, filter set, direction, or snapshot. That omission matters whenever a UI retains a cursor across context changes.

Not specified by the original author.

TL;DR

Resolved by the reporter: it was their own environment - the EXAAPIKEY env var and Node version were not set globally for Cursor's spawned process. Working invocation used cross-env to inject the key, e.g.

Steps

1. Resolved by the reporter: it was their own environment - the EXAAPIKEY env var and Node version were not set globally for Cursor's spawned process. Working invocation used cross-env to inject the key, e.g. 'npx cross-env EXAAPIKEY [your value] ...'. Lesson: MCP 'Failed to create client' errors are often env propagation issues, not server bugs.

When to use

You are seeing this: Connecting the Exa MCP server to Cursor fails with 'Failed to create client', even with the API key placed directly in the command. Use this skill when you run into "Cursor connection fails with "Failed to create client" error".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In gh:exa-labs/exa-mcp-server#14 (https://github.com/exa-labs/exa-mcp-server/issues/14), the question was: Connecting the Exa MCP server to Cursor fails with 'Failed to create client', even with the API key placed directly in the command. The verified resolution: Resolved by the reporter: it was their own environment - the EXAAPIKEY env var and Node version were not set globally for Cursor's spawned process. Working invocation used cross-env to inject the key, e.g.