MCP invalid type for parameter 'params' in tool update_worksapce

[severity1]

There appears to be a conflict when using 'params' as a parameter name in Cursor's MCP implementation.

Working example in Claude Code: terraform-cloud-mcp:update_workspace (MCP)(organization: "slalom-au", workspace_name: "rollersk8s-test", params: {"description":"FOO BAR BAZ"})

Error in Cursor: "Parameter 'params' must be of type undefined, got object"

Potential Issue:

• 'params' might be a reserved keyword in Cursor's MCP implementation
• This could explain why we're getting a type mismatch error even though the format is correct
• The same exact format works in Claude Code but fails in Cursor

Code Reference:

async def update_workspace(
    organization: str,
    workspace_name: str,
    params: Optional[WorkspaceParams] = None
) -> APIResponse:

[juanarrow]

try: async def update_workspace( organization: str, workspace_name: str, params: WorkspaceParams = None ) -> APIResponse:

[ceuity]

Type Mismatch Error in MCP echo_params API Implementation

Issue Description

When trying to use the echo_params API in the MCP implementation, I'm encountering a type mismatch error. The API fails to handle the nested object structure defined in the JSON schema.

Current Behavior

When calling the echo_params API with a valid params object, it returns:

Error calling tool: Parameter 'params' must be of type undefined, got object

Expected Behavior

The API should accept a params object matching the schema definition:

{
    "$defs": {
        "Params": {
            "properties": {
                "name": {"type": "string"},
                "age": {"type": "integer", "maximum": 100, "minimum": 0}
            },
            "required": ["name", "age"],
            "type": "object"
        }
    },
    "properties": {
        "params": {
            "anyOf": [
                {"$ref": "#/$defs/Params"},
                {"type": "null"}
            ],
            "default": null
        }
    }
}

Tool Definition

The echo_params tool is defined in the function list as follows:

class Params(BaseModel):
    name: str = Field(description="The name of the voice")
    age: int = Field(description="The age of the voice", ge=0, le=100)


@mcp.tool("echo_params", "Echo the parameters")
def echo_params(params: Params = None) -> dict:
    """Echo the parameters

    Args:
        params: Optional[Params] = None

    Returns:
        dict: The echoed parameters
    """
    if params is None:
        return {"name": "John Doe", "age": 30}
    return {"name": params.name, "age": params.age}

Technical Details

• The schema clearly defines params as accepting either a Params object or null
• The Params object is properly defined with required name and age properties
• However, the MCP implementation seems to interpret this nested structure as requiring an "undefined" type instead of an object

Steps to Reproduce

1. Try to call the echo_params API with a valid params object:

{
    "name": "test",
    "age": 25
}

2. Observe the type mismatch error

Would appreciate any guidance on whether this is a known limitation of the MCP implementation or if there's a workaround available.

[bobtista]

I'm having the same issue passing the optional string "q" as a parameter to a tool. The q search string needs to be omitted from the tool call when using cursor. If I try to set it to a string or null, I get an error that it must be undefined "Error calling tool: Parameter 'q' must be of type undefined, got string." Has anyone found a fix or workaround? The code is correct in the MCP server, it seems to only be a problem when cursor tries to use the tool. The mcp server is "honeybadger-mcp-server" on pypi, and it works fine from Claude Desktop

[morganmcg1]

Also getting this error in Cursor's mcp using our Weights & Biases MCP server https://github.com/wandb/wandb-mcp-server

[severity1]

This could potentially be a name collision issue where params or certain keywords/names are being used internally by the MCPs client or cursor itself. And when a tool expects the same keywords/names then the values that might be being passed to the MCPs tools are actually cursor internal values. This could be a bigger security risk if cursor has secrets or sensitive values in their params or q names and the MCPs server is not doing any type checking and just accepting those values.