Skip to content

[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

Open
Open
[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
Labels
area:cliThe Codebuff/Freebuff terminal clientbot:triagedClassified by the community triage bottype:bugA defect in the code with a reproducible failure

Description

@dvelm
dvelm
opened on Sep 9, 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-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:

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.

Activity

  1. dvelm commented on Sep 9, 2026

    @dvelm
    dvelm
    on Sep 9, 2026
    Author

    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.

  2. dvelm commented on Sep 9, 2026

    @dvelm
    dvelm
    on Sep 9, 2026
    Author

    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.

  3. dvelm commented on Sep 9, 2026

    @dvelm
    dvelm
    on Sep 9, 2026
    Author

    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.
  4. codebuff-team
    added
    bot:triagedClassified by the community triage bot
    type:bugA defect in the code with a reproducible failure
    on Sep 9, 2026

  5. dvelm commented on Sep 14, 2026

    @dvelm
    dvelm
    on Sep 14, 2026
    Author

    are you able to fix or I do?

  6. codebuff-team
    added
    area:cliThe Codebuff/Freebuff terminal client
    on Sep 14, 2026

  7. dvelm commented on Sep 14, 2026

    @dvelm
    dvelm
    on Sep 14, 2026
    Author

    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 in run-agent-step.ts).
    • Session-free: 72/72 regression tests green (agent-runtime 35/35 incl. the schema._zod.parent crash that fails on clean main, common MCP 5/5 incl. real-stdio wiring test, llm-providers 32/32). Full agent-runtime suite: 616 pass, 2 fail -- both fail identically on clean main (missing agents-graveyard/researcher file, pre-existing). Typecheck: zero errors from any of the 23 fix files.
    • Live: built freebuff.exe from the patched tree and ran a full session on glm-5.3-flash (one of the two failing models) with tavily, brave-search and chrome-devtools configured -- 18 MCP calls, every parameterized call (tavily_search with 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.

  8. github-actions
    added 3 commits that reference this issue on Sep 16, 2026

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    076c47a

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    c2edf30

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    086eea4
  9. dvelm
    added a commit that references this issue on Sep 18, 2026

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    1ce0010
  10. github-actions
    added 3 commits that reference this issue on Sep 18, 2026

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    9261a17

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    afd1f11

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    633ccd2

  11. 27 remaining items

  12. github-actions
    added 15 commits that reference this issue on Sep 26, 2026

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    5b699fb

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    0cd7628

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    926a013

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    93c4723

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    ac5a4d1

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    065fb97

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    ab5b7e9

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    3336f7c

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    1f9c221

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    814375a

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    85c8078

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    57a82e5

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    c24c4f9

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    5bc083d

    Apply MCP schema fixes for parameterized tools on strict models (see C…

    f925c41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:cliThe Codebuff/Freebuff terminal clientbot:triagedClassified by the community triage bottype:bugA defect in the code with a reproducible failure

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions