[Bug] MCP tool parameters arrive at MCP servers as {} — affects tavily/brave/context7/chrome-devtools on glm-5.3-flash and gpt-5.6-luna; built-in tools unaffected

[dvelm]

Status (2026-09-09): Still reproduces on 0.0.172 after a clean reinstall. Root cause is covered by PR #1259 (bug families 1, 5, 6); fix files are not yet present in the 0.0.172 package (no zod-safe-clone in the shipped bundle).

What happened

Every tool call to any MCP-server-provided tool arrives at the MCP server with an empty arguments object ({}) — the model's parameters never reach the tool. Validation fails with zod errors like expected string, received undefined.

Built-in tools (read_files, write_file, run_terminal_command, web_search, ask_user with deeply nested schemas, …) accept identical multi-parameter payloads with zero problems in the same session. The failure is model-independent: it reproduces on glm-5.3-flash and was independently observed on gpt-5.6-luna (separate session, same user), so this looks like a client/tool-bridge serialization bug rather than a model issue.

Repro rate: ~100% — zero successful parameterized MCP calls in the entire session, retried across many turns and tool servers.

This looks like the same root cause as #912 (tool inputSchema.properties stripped at registration → empty schema → expected string, received undefined). Filed as a standalone report because it reproduces on 4 mainstream servers (not just a niche Dart server) and 2 different models, which widens the blast radius. A fix for #912 is already pending in #1259 — this report adds reproduction evidence for merging it.

Steps to reproduce

1. Start a freebuff session with any MCP server configured (tested: tavily, brave-search, context7, chrome-devtools).
2. Ask the agent anything that triggers an MCP tool call, e.g. "search the web for X" (tavily__tavily_search) or "open https://example.com in the browser" (chrome-devtools__navigate_page).
3. The model emits a well-formed tool call with parameters (e.g. {"query": "X"}).
4. The MCP server receives an empty arguments object and returns a zod validation error (see Logs).

Controls in the same session (proves the model emits parameters correctly):

• chrome-devtools__list_pages (zero params): SUCCESS
• built-in web_search {query, depth}: SUCCESS (dozens of calls)
• built-in read_files [{path}, {path, offset, limit}]: SUCCESS
• built-in ask_user {questions: [{question, header, options: [{label, description}], multiSelect}]} (deeply nested schema): SUCCESS

So: zero-param MCP tools work; 1+-param MCP tools receive {}; built-in tools with equal or more complex schemas work flawlessly. The parameters exist in the model's tool call but the object delivered to the MCP server is {}.

Where does this happen?

MCP servers or tools

Operating system

Windows

Version

0.0.172 (also reproduces on 0.0.93; retested after clean reinstall on 2026-09-09)

Model

glm-5.3-flash (also reproduced on gpt-5.6-luna in a separate session)

Logs or screenshots

Error during tool call: Invalid parameters for tavily__tavily_search: [
  { "expected": "string", "code": "invalid_type", "path": ["query"],
    "message": "Invalid input: expected string, received undefined" }
]
Original tool call input: {}. Please check the tool name and arguments and try again.

Same signature for every affected tool:

Tool	zod path	expected
brave__brave_web_search	["query"]	string
context7__resolve-library-id	["query", "libraryName"]	string
chrome-devtools__navigate_page	["pageId"]	number
chrome-devtools__new_page	["url"]	string

Similar upstream bugs where tool-call arguments were dropped in the client→MCP path, for reference:

• [BUG] Claude Code no longer passing parameters to MCP anthropics/claude-code#2089 ("no longer passing parameters to MCP")
• [BUG] MCP tool calls with empty string "" parameter drop ALL parameters anthropics/claude-code#58281 (empty-string param drops ALL parameters)
• [BUG] MCP Tools Receive Empty Arguments When Using Permission Approval Flow anthropics/claude-agent-sdk-python#320 ("MCP Tools Receive Empty Arguments")
• MCP tools with no arguments fail with "Tool call not found" when using OpenAI (compatible) API zed-industries/zed#48955
• bug: MCP tools with no arguments fail: empty string not handled in tool call argument parsing open-webui/open-webui#23778

Debugging pointers: dump the raw tool_call arguments at the agent-loop boundary vs. what is dispatched to the MCP server; check any serializer that drops the whole arguments object on a falsy/empty value; check the strict JSON-schema↔zod conversion of MCP inputSchema (an unparseable conversion can make the client discard provided args before dispatch) — cf. the cloneDeepKeepingZod fix in #1259.

[dvelm]

Update after reading the full #1259 thread — the root cause of this issue is now known, and our symptoms map onto three of the six bug families fixed there:

1. Family 1 — lodash cloneDeep drops zod v4's non-enumerable _zod engine → silent fallback serves an empty schema (this is MCP Tool inputSchema.properties stripped when registering tools from external MCP servers #912's properties: {}, our Original tool call input: {}).
2. Family 5 — loose JSON Schemas amputated by the zod round-trip. @quwin's comment traces the exact chain we hit: getToolSet() → zod-from-json-schema → loose objects/unions become zod custom types → z.toJSONSchema() throws → ensureJsonSchemaCompatible() substitutes z.object({}).passthrough() → model-facing schema has no named properties, so constrained decoding emits {} and the MCP server receives no arguments.
3. Family 6 — string-encoded union members (relevant to chrome-devtools union params).

PR status as of 2026-09-09: force-pushed rebuilt series (clean main base, one semantic commit per fix, two-sided regression tests + live end-to-end over server-everything's 13 tools), open, no formal reviews on the new head yet.

No further action needed on this issue beyond merge tracking — it stands as the 4-mainstream-server (tavily, brave-search, context7, chrome-devtools) / 2-model (glm-5.3-flash, gpt-5.6-luna) reproduction evidence for #1259.

[dvelm]

New control data point (2026-09-09) — same CLI (0.0.93), same MCP servers, different model: with deepseek-v4-flash selected, every parameterized MCP call in the same test matrix succeeds:

Tool	Params sent	Result on glm-5.3-flash	Result on deepseek-v4-flash
tavily__tavily_search	query, max_results, search_depth	❌ arrives as {}	✅ works
brave__brave_web_search	query	❌ arrives as {}	✅ works
chrome-devtools__navigate_page	pageId, url	❌ arrives as {}	✅ works (real navigation)
context7__resolve-library-id	query, libraryName	❌ arrives as {}	✅ works
chrome-devtools__list_pages	(none)	✅	✅

Interpretation: this rules out a blanket client-side serializer drop of tool arguments (a pure serializer bug would fail identically for every model). It is consistent with the empty model-facing schema path from #1259 (families 1 and 5): the schema presented to the model has no named properties, and models that use strict/constrained decoding (glm-5.3-flash, and per report gpt-5.6-luna) then emit literal {}, whereas deepseek-v4-flash fills arguments from tool descriptions / looser decoding and therefore "works" in spite of the empty schema.

Net effect: the bug still lives in the schema-presentation layer this PR fixes, but its user-visible impact is model-dependent — worth noting in the PR description so it is not mistaken for a model-side issue when triaging similar reports.

[dvelm]

New retest after user's clean reinstall (2026-09-09) — CLI 0.0.172 (npm uninstall -g freebuff && npm install -g freebuff):

Tool	Params sent	Result on 0.0.172
tavily__tavily_search	query	❌ arrives as {}
brave__brave_web_search	query	❌ arrives as {}
chrome-devtools__navigate_page	pageId, url	❌ arrives as {}
context7__resolve-library-id	query, libraryName	❌ arrives as {}
chrome-devtools__list_pages	(none)	✅ works
PR #1259 fix files in installed package	—	❌ not present (no zod-safe-clone in bundle)

Conclusions:

1. Reinstall does not fix the bug — consistent with it being shipped-code behavior, not local corruption.
2. 0.0.172 (latest npm, published Sep 8) does not yet contain the PR Fix six bug families in MCP tool schema and result handling #1259 fix.
3. Model-dependence unchanged: parameterized MCP calls succeed on deepseek-v4-flash in the same environment (previous comment), fail on glm-5.3-flash on both 0.0.93 and 0.0.172 — matching the model-facing-schema failure mode from the Fix six bug families in MCP tool schema and result handling #1259 analysis.