[Bug]: mcp tool "number" field incorrect format

[createthis]

Is there an existing issue for the same bug? (If one exists, thumbs up or comment on the issue instead).

• I have checked the existing issues.

Describe the bug and reproduction steps

I'm using https://github.com/createthis/diffcalculia_mcp

My AI says this:

You're absolutely right - the parameters should be numbers, not strings. Let me try again with the correct parameter types:

<function=read_file>
<parameter=path>/workspace/path/to.js</parameter>
<parameter=line_number>540</parameter>
<parameter=lines_after>40</parameter>
</function>

And Open Hands does this:

MCP Tool Call: read_file

Thought: You're absolutely right - the parameters should be numbers, not strings. Let me try again with the correct parameter types:

Arguments:

{
  "path": "/workspace/path/to.js",
  "line_number": "540",
  "lines_after": "40"
}

McpError: MCP error -32602: Invalid arguments for tool read_file: [ { "code": "invalid_type", "expected": "number", "received": "string", "path": [ "line_number" ], "message": "Expected number, received string" }, { "code": "invalid_type", "expected": "number", "received": "string", "path": [ "lines_after" ], "message": "Expected number, received string" } ]
McpError: MCP error -32602: Invalid arguments for tool read_file: [ { "code": "invalid_type", "expected": "number", "received": "string", "path": [ "line_number" ], "message": "Expected number, received string" }, { "code": "invalid_type", "expected": "number", "received": "string", "path": [ "lines_after" ], "message": "Expected number, received string" } ]

OpenHands Installation

Docker command in README

OpenHands Version

a7cec86-nikolaik

Operating System

MacOS

Logs, Errors, Screenshots, and Additional Context

No response

[tawago]

I've installed https://github.com/github/github-mcp-server and openhands fails to use it correctly.
eg. get_pull_request errors {"meta": null, "content": [{"type": "text", "text": "parameter pullNumber is not of type float64", "annotations": null}], "isError": true}

I initially thought this might be on the github-mcp side of issue but it actually works when openhands call the toll from command line like below:

GitHub MCP Server running on stdio
{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"logging":{},"resources":{"subscribe":true,"listChanged":true},"tools":{"listChanged":true}},"serverInfo":{"name":"github-mcp-server","version":"version"}}}
{"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"{\"id\":2501744831,\"number\":66,\"state\":\"open\",\"locked\":false,\"title\":\"Add ...

Openhands 0.39.1 on claude sonnet 4 says,

Root Cause Analysis
The MCP tool failure was indeed an OpenHands-specific issue:
Direct MCP call: ✅ Works perfectly with pullNumber: 66
OpenHands MCP tool: ❌ Fails with "parameter pullNumber is not of type float64"
This confirms that OpenHands has a bug in its MCP parameter serialization that should be reported to the OpenHands development team. The GitHub MCP server itself is working correctly.

Looking at the test cases, I can see that OpenHands is passing arguments directly without any type conversion. For example, in line 148
mcp_action = MCPAction(name='fetch', arguments={'url': 'http://localhost:8000'})
And in line 184:
mcp_action = MCPAction(name='list_directory', arguments={'path': '.'})
The problem is that when the LLM calls a function with numeric parameters, they come through as JSON which preserves the integer type, but the MCP server expects them to be converted to the appropriate types based on the tool schema.
The fix would be to add type conversion logic in OpenHands that converts numeric parameters to the appropriate types based on the tool schema before calling the MCP server.

[github-actions]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[patonw]

I'm encountering this as well. With debug logging turned on it seems that this is happening at a lower level than OpenHands' MCP client. I'm not sure if it's ollama, LiteLLM, or something in between is doing the stringifying, but the response is incorrect by the time it reaches OpenHands:

codeact_agent.py:198 - Response from LLM: ModelResponse(id='chatcmpl-28c4cb42-16eb-4583-
8326-6149804c5952', created=1751656660, model='.../qwen3:30b', object='chat.completion', system_fingerprint=None,
choices=[Choices(finish_reason='stop', index=0, message=Message(content='\nOkay, the user is trying to fetch
resource 3 using the everything_getResourceReference function, but there's a recurring error where the resourceId
is being treated as a string instead of a number. Let me check the function parameters again.\n\nThe function everyt
hing_getResourceReference requires the resourceId to be a number. The user's previous attempts might have used "3"
as a string. So the correct approach is to pass 3 as an integer. Let me make sure the function call uses a numeric v
alue for resourceId.\n\nI'll adjust the function call to use resourceId=3 without quotes. That should resolve the t
ype error. Let me try that.\n', role='assistant', tool_calls=[ChatCompletionMessageToolCall(index=1, functio
n=Function(arguments='{"resourceId": "3"}', name='everything_getResourceReference'), id='toolu_15', type='function')
], function_call=None, provider_specific_fields=None))], usage=Usage(completion_tokens=153, prompt_tokens=11148, tot
al_tokens=11301, completion_tokens_details=None, prompt_tokens_details=None))

I've tried this with several families of models with the same result: the LLM observes that string arguments fail and tries to generate numeric arguments only to have them get stringified somewhere in the stack.

OS: Linux/NixOS
OpenHands: 0.48
LLM provider: ollama
MCP server: @modelcontextprotocol/server-everything

[createthis]

@patonw I worked around it in my MCP server by just changing the field type to string and validating internally. Sucks, but it was an option for me since I wrote the code.

[patonw]

I've traced the issue to openhands.llm.fn_call_converter.

The proximate cause is that _extract_and_validate_params() only supports "integer" but not "number" as stated by JSON Schema. It would be simple enough to add extra cases for number and boolean:

            elif param_name_to_type[param_name] == "number":
                try:
                    float_value = float(param_value)
                    if float_value.is_integer():
                        param_value = int(float_value)
                    else:
                        param_value = float_value
                except ValueError:
                    raise FunctionCallValidationError(
                        f"Parameter '{param_name}' is expected to be an number."
                    )
            elif param_name_to_type[param_name] == "boolean":
                try:
                    param_value = bool(param_value)
                except ValueError:
                    raise FunctionCallValidationError(
                        f"Parameter '{param_name}' is expected to be an boolean."
                    )

Taking a step back though, it seems this module is converting function calls to/from an XML-ish syntax instead of using API support for tool calling or even JSON-formatted responses. The better solution would be to fix this.

[github-actions]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[patonw]

The fix is stalled due to "performance degradation". I'm not sure about the statistical significance or methodology and if it points to a real problem or just random variance. However, it doesn't seem this will move forward until someone with more knowledge on the topic can troubleshoot this.

[github-actions]

This issue is stale because it has been open for 40 days with no activity. Remove the stale label or leave a comment, otherwise it will be closed in 10 days.

[mamoodi]

Is this issue still happening?

[patonw]

I would like to move forward with this, but have yet to receive guidance on diagnosing the regression. The volume of the log outputs makes the difficult to understand without tooling.

My guess is that it's something simple like needing another alias for "true"/"false". I could also take out boolean coercion and leave in the numeric part, but that wouldn't be ideal.

[github-actions]

This issue is stale because it has been open for 40 days with no activity. Remove the stale label or leave a comment, otherwise it will be closed in 10 days.

[mamoodi]

Moving this to agent-sdk. Let me know if this was a mistake agent team.