Repository navigation
[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 #1306
Description
Activity
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:
- Family 1 — lodash
cloneDeepdrops zod v4's non-enumerable_zodengine → silent fallback serves an empty schema (this is MCP Tool inputSchema.properties stripped when registering tools from external MCP servers #912'sproperties: {}, ourOriginal tool call input: {}). - 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()substitutesz.object({}).passthrough()→ model-facing schema has no named properties, so constrained decoding emits{}and the MCP server receives no arguments. - Family 6 — string-encoded union members (relevant to
chrome-devtoolsunion params).
PR status as of 2026-09-09: force-pushed rebuilt series (clean
mainbase, one semantic commit per fix, two-sided regression tests + live end-to-end overserver-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.Reacted by kooks28- Family 1 — lodash
New control data point (2026-09-09) — same CLI (0.0.93), same MCP servers, different model: with
deepseek-v4-flashselected, 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_searchquery, max_results, search_depth ❌ arrives as {}✅ works brave__brave_web_searchquery ❌ arrives as {}✅ works chrome-devtools__navigate_pagepageId, url ❌ arrives as {}✅ works (real navigation) context7__resolve-library-idquery, 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.
Reacted by kooks28New 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_searchquery❌ arrives as {}brave__brave_web_searchquery❌ arrives as {}chrome-devtools__navigate_pagepageId,url❌ arrives as {}context7__resolve-library-idquery,libraryName❌ arrives as {}chrome-devtools__list_pages(none) ✅ works PR #1259 fix files in installed package — ❌ not present (no zod-safe-clonein bundle)Conclusions:
- Reinstall does not fix the bug — consistent with it being shipped-code behavior, not local corruption.
- 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.
- Model-dependence unchanged: parameterized MCP calls succeed on
deepseek-v4-flashin the same environment (previous comment), fail onglm-5.3-flashon 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.
Reacted by kooks28are you able to fix or I do?
Independent verification that #1259 fixes this, tested 2026-09-14 on current
main(69030b5, 159 commits ahead of the PR base):- Applied all 11 commits cleanly (
git cherry-pick, only overlap auto-merged inrun-agent-step.ts). - Session-free: 72/72 regression tests green (
agent-runtime35/35 incl. theschema._zod.parentcrash that fails on cleanmain,commonMCP 5/5 incl. real-stdio wiring test,llm-providers32/32). Fullagent-runtimesuite: 616 pass, 2 fail -- both fail identically on cleanmain(missingagents-graveyard/researcherfile, pre-existing). Typecheck: zero errors from any of the 23 fix files. - Live: built
freebuff.exefrom the patched tree and ran a full session onglm-5.3-flash(one of the two failing models) with tavily, brave-search and chrome-devtools configured -- 18 MCP calls, every parameterized call (tavily_searchwith query+depth+filters+time_range,brave_web_search,navigate_page,take_screenshot) arrived with args intact. Zero{}/zod errors. Only failures were page-render issues (old.reddit bot detection), unrelated to schema.
So the fix works end-to-end on the exact failing setup from this issue. Question for maintainers: what is blocking the merge? Happy to help rebase/retest if needed.
- Applied all 11 commits cleanly (
- added 3 commits that reference this issue
on Sep 16, 2026 - added a commit that references this issue
on Sep 18, 2026 - added 3 commits that reference this issue
on Sep 18, 2026 27 remaining items
- added 15 commits that reference this issue
on Sep 26, 2026
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-clonein 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 likeexpected 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-flashand was independently observed ongpt-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.propertiesstripped 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
tavily,brave-search,context7,chrome-devtools).tavily__tavily_search) or "open https://example.com in the browser" (chrome-devtools__navigate_page).{"query": "X"}).Controls in the same session (proves the model emits parameters correctly):
chrome-devtools__list_pages(zero params): SUCCESSweb_search {query, depth}: SUCCESS (dozens of calls)read_files [{path}, {path, offset, limit}]: SUCCESSask_user {questions: [{question, header, options: [{label, description}], multiSelect}]}(deeply nested schema): SUCCESSSo: 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
Same signature for every affected tool:
brave__brave_web_search["query"]context7__resolve-library-id["query", "libraryName"]chrome-devtools__navigate_page["pageId"]chrome-devtools__new_page["url"]Similar upstream bugs where tool-call arguments were dropped in the client→MCP path, for reference:
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
cloneDeepKeepingZodfix in #1259.