Skip to content

[Bug]: MCP tool call with an optional argument set to null fails via OpenClaw but succeeds via other MCP clients #96716

Description

@yybht155

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

An MCP tool call where an optional string argument is set to JSON null fails with a
server-side error via OpenClaw, while the identical call (same arguments, same server URL
and token) sent from another MCP client (Cursor) succeeds — indicating OpenClaw transmits
the optional null argument differently.

Steps to reproduce

  1. Configure an MCP server over streamable-http that exposes a tool with an OPTIONAL string
    argument whose JSON Schema is anyOf [string, null] with default null
    (concrete case: awslabs eks-mcp-server get_eks_insights, arg insight_id).
  2. Have the agent call the tool in "list" mode, i.e. with insight_id = null.
  3. Observe the tool result is the server's "describe one item" error path, and the
    OpenClaw trajectory records the arguments with insight_id: null.
  4. Send the identical arguments from another MCP client (Cursor) to the same server URL +
    bearer token -> it returns the list successfully.

Expected behavior

Calling the tool with the optional argument = null (or absent) should behave as "not
provided". Grounded reference: the identical arguments sent from another MCP client (Cursor)
to the same server return the list successfully, and the tool's JSON Schema defines null as
the default ("no id" => list mode).

Actual behavior

The call fails. OpenClaw trajectory recorded the tool arguments as:
{"category":null,"cluster_name":"testenv-cluster","insight_id":null}
and the tool returned:
Error retrieving insight details: An error occurred (AccessDeniedException) when calling
the DescribeInsight operation: Unable to determine service/operation name to be authorized

Against that same server, this error is reproducible ONLY when insight_id is sent as an
empty string "" — sending null, absent, or the string "null" all return the list. So the
server distinguishes "" from null, and OpenClaw's null call behaves like "".

OpenClaw version

2026.6.10 (aa69b12)

Operating system

Ubuntu Linux (kernel 7.0.0-1006-aws), x86_64 EC2

Install method

npm global (~/.npm-global)

Model

gpt-5.5

Provider / routing chain

openclaw -> gateway -> gpt-5.5

Additional provider/model setup details

MCP path relevant to this bug: openclaw -> mcphub (streamable-http) -> awslabs eks-mcp-server.

Logs, screenshots, and evidence

# OpenClaw trajectory: tool call arguments (insight_id is null) and the error result
get_eks_insights","arguments":{"category":null,"cluster_name":"testenv-cluster","insight_id":null}
get_eks_insights","content":[{"type":"text","text":"Error retrieving insight details: An error occurred (AccessDeniedException) when calling the DescribeInsight operation: Unable to determine service/operation name to be authorized"}],"details":{"mcpServer":"mcphub","mcpTool":"eks-apn1-get_eks_insights","status":"error"}

# Same server, same token, sent from another MCP client (Cursor):
#   {cluster_name}                      -> list OK
#   {cluster_name, insight_id: null}    -> list OK
#   {cluster_name, insight_id: "null"}  -> list OK
#   {cluster_name, insight_id: ""}      -> SAME DescribeInsight error as above

Impact and severity

Affected: any MCP server that distinguishes null/absent from "" for an optional argument.
Severity: High for affected tools (the "list" form of get_eks_insights is impossible from
OpenClaw; it always errors).
Frequency: Always (reproduced repeatedly, including a forced single-call test).
Consequence: A logically valid tool call is unusable via OpenClaw while working from other
MCP clients.

Additional information

Hypothesis (NOT yet confirmed by a captured wire payload): OpenClaw may serialize optional
arguments set to JSON null as empty strings "" when calling MCP tools over streamable-http.
We could not capture the raw wire request: openclaw proxy run blocked the model provider
endpoint via SSRF protection, so the run could not reach the MCP call under capture.
Downstream defensive fix filed at awslabs/mcp#4036 (server side treating "" as list mode),
but the originating behavior appears to be on the OpenClaw client side.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.bugSomething isn't workingbug:behaviorIncorrect behavior without a crashclawsweeper:linked-pr-openClawSweeper found an open linked pull request for this issue.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:otherThis issue has meaningful maintainer-visible impact outside the owned taxonomy.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions