Cursor MCP invalid parameter

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am receiving an Invalid parameter names found error in Cursor’s Model Context Protocol (MCP) for my tool search_transactions. The specific parameters flagged are filter.customFields and filter.metadata, with the error message stating they contain invalid characters or are too long.
This tool definition is being generated by converting an OpenAPI specification to MCP using fast-mcp. The same tool definition works as expected and does not produce any errors when used with Claude.
Here is the OpenAPI specification for the filter.metadata parameter, which is causing the issue:

  "name": "filter.metadata",
  "required": false,
  "in": "query",
  "explode": true,
  "description": "Filter on transactions based on metadata values. For example, `filter.metadata[metadataKey]=$in:metadataValue1,metadataValue2`. Supported operators (`$eq:` or `$in:`).",
  "style": "deepObject",
  "schema": {
    "type": "object",
    "additionalProperties": { "type": "string" }
  }
}

Steps to Reproduce

Generate a tool with parameter that has “.” in the parameter defiintion

Screenshots / Screen Recordings

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.46 (Universal)
VSCode Version: 1.99.3
Commit: b9e5948c1ad20443a5cecba6b84a3c9b99d62580
Date: 2025-10-14T01:21:46.830Z (2 days ago)
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the report. This is a known issue with MCP parameter validation in Cursor.

The problem: Cursor’s MCP implementation applies stricter parameter name validation than the MCP spec requires. Parameter names with dots (.) are rejected, even though they’re valid in OpenAPI and work correctly with Claude.

Workaround: rename parameters to camelCase or snake_case without dots:

  • filter.metadata → filterMetadata or filter_metadata
  • filter.customFields → filterCustomFields or filter_custom_fields

This is similar to other MCP validation bugs (e.g., integer vs number and complex parameters) that the team is already investigating.

I’ll pass this to the team, since it blocks valid OpenAPI specifications from working with fast‑mcp.

Any workaround suggestions for integer vs number and complex parameters?