Skip to content

fix!: answer non-object tools/call params instead of ending the server - #19

Merged
Martin Bens (SpiGAndromeda) merged 1 commit into
mainfrom
fix/tools-call-params-object-gate
Sep 12, 2026
Merged

Martin Bens (SpiGAndromeda) merged 1 commit into
mainfrom
fix/tools-call-params-object-gate

Conversation

@SpiGAndromeda

@SpiGAndromeda Martin Bens (SpiGAndromeda) commented Sep 12, 2026 •

Copy link
Copy Markdown
Collaborator

Fixes #15.

handle_tools_call read .name and .arguments before checking the type of params. Under set -o posix bash inherits errexit into the command substitutions those extractions run in, so jq's failure to index a number, string, array or true ended the whole server with no response, and the request that followed was never answered. In the default mode the server survived and answered -32602 Invalid tool name: , but jq wrote its Cannot index ... diagnostics straight to the process's stderr, outside log.

params is now gated as an object at the top of handle_tools_call, on the same footing as process_request's request-object gate, so the extractions cannot fail in any shell mode and the call answers -32602 Invalid params: expected an object. The gate also fails closed for a direct caller passing invalid JSON. A present null or false params is normalized to {} before dispatch and keeps the Invalid tool name: answer. POSIX mode is not a configuration the SDK claims to support, but it no longer ends the server on this path.

Breaking: the answer for a tools/call whose params is a number, string, array or true changes from -32602 Invalid tool name: to -32602 Invalid params: expected an object. A consumer matching on that message text updates it; the error code is unchanged.

New suite tests/tools_call_params.bats (5 tests): the -32602 envelope for number/string/array params through process_request, server survival plus a follow-up ping answered under set -o posix through run_mcp_server, and a clean stderr in the default mode.

The sibling defect where a non-object tools or config file document ends the server is #18 and stays separate.

handle_tools_call read `.name` and `.arguments` before checking the type of params. Under `set -o posix` bash inherits errexit into the command substitutions those extractions run in, so jq's failure to index a number, string, array or `true` with those keys ended the whole server with no response, and the request that followed was never answered. In the default mode the server survived and answered `-32602 Invalid tool name: `, but jq wrote its `Cannot index ...` diagnostics straight to the process's stderr, outside `log`.

params is now gated as an object before either field is read, on the same footing as process_request's request-object gate, so the extractions cannot fail in any shell mode and the call answers `-32602 Invalid params: expected an object`. A present `null` or `false` params is normalized to `{}` before dispatch and keeps the `Invalid tool name: ` answer. POSIX mode is not a configuration the SDK claims to support, but it no longer ends the server on this path.

BREAKING CHANGE: the answer for a tools/call whose params is a number, string, array or `true` changes from `-32602 Invalid tool name: ` to `-32602 Invalid params: expected an object`. A consumer matching on that message text updates it; the error code is unchanged.

Fixes #15.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@SpiGAndromeda
Martin Bens (SpiGAndromeda) merged commit 9cde708 into main Sep 12, 2026
3 checks passed
@SpiGAndromeda
Martin Bens (SpiGAndromeda) deleted the fix/tools-call-params-object-gate branch September 13, 2026 10:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

a tools/call whose params is not an object ends the server under set -o posix

1 participant