anthropics
[BUG] Claude Code no longer passing parameters to MCP
Environment
- Platform (select one):
- [ X] Anthropic API
- [ ] AWS Bedrock
- [ ] Google Vertex AI
- [ ] Other:
- Claude CLI version: 1.0.24
- Operating System: EndeavourOS
- Terminal: Alacritty
Bug Description
Claude code is not able to call an MCP tool that has always worked in the past. I have an MCP task manager that has been build along with a tool to track tasks. It's no longer able to pass a body and update the task properly:
can you also mark 366 as done ⎿ Error: MCP error -32602: failed to deserialize parameters: missing field
task_id
● I keep making the same mistake. Let me include the parameters properly:
⎿ Error: MCP error -32602: failed to deserialize parameters: missing field task_id
● I'm not including the body parameters. Let me do this correctly:
⎿ Error: MCP error -32602: failed to deserialize parameters: missing field task_id
⎿ API Error: Request was aborted.
can you check the tool definition and the required body and try again?
● Let me check the tool definition for update_task:
Looking at the function definition from earlier, mcp__memory-bank-mcp__update_task requires:
- task_id (required, integer)
- status (optional, string)
Let me call it with the proper parameters:
⎿ Error: MCP error -32602: failed to deserialize parameters: missing field task_id
● I'm still not passing the parameters correctly. Looking at how I successfully called it before for task 362, I need to use task_id
● Let me try again with the correct format based on my successful call earlier:
⎿ Error: MCP error -32602: failed to deserialize parameters: missing field task_id
⎿ API Error: Request was aborted.
Additional Context
There have been no updates to this MCP server. Other tools for the MCP server are working properly and parameters are being passed. I have cleared project history and context history and it continues to fail.
Hey!
Developer here helping with MCP issue triage.
This looks like a parameter serialization regression in Claude CLI 1.0.24. Since your other MCP tools work and this used to function properly, this points to how the CLI is constructing JSON-RPC calls for specific schemas.
Quick diagnostic to help the Anthropic team:
1. MCP Server Debug Logging Add logging to your update_task handler to capture what's actually being received:
python# Python MCP example
import json
import logging
logging.basicConfig(level=logging.DEBUG)
@app.call_tool()
async def update_task(arguments: dict):
logging.debug(f"Raw incoming request: {json.dumps(arguments, indent=2)}")
logging.debug(f"Available keys: {list(arguments.keys())}")
# ... rest of handler
2. Schema Context
Can you share your MCP tool schema definition for update_task? The CLI thinks it's sending the right parameters, but your server isn't receiving task_id.
3. Working Tool Comparison
Since other tools work fine, can you share the schema for one that's currently working? This will help identify if it's specific to certain parameter types (integers, required fields, etc.).
For Anthropic team:
Version: Claude CLI 1.0.24, EndeavourOS Pattern: Complete parameter serialization failure for specific tool, other tools on same MCP server work Regression: Tool worked previously, no server-side changes
This should give much better diagnostic info for a fix.
Thanks for helping with triage! Here's the diagnostic information requested:
1. MCP Server Debug Logging Output
Added logging to my Rust MCP server's update_task handler. The raw stdio request shows:
Failing call:
{"method":"tools/call","params":{"name":"update_task","arguments":{}},"jsonrpc":"2.0","id":2}
Working call (for comparison):
{"method":"tools/call","params":{"name":"get_task","arguments":{"task_id":999}},"jsonrpc":"2.0","id":13}
The arguments object is completely empty for update_task.
2. Tool Schema Definitions
update_task (failing):
"update_task": {
"description": "Request struct for updating a task",
"required": ["task_id"],
"properties": {
"task_id": {
"type": "integer",
"format": "int64",
"description": "ID of the task to update"
},
"title": {
"type": "string",
"description": "Updated task title",
"nullable": true
},
"description": {
"type": "string",
"description": "Updated task description",
"nullable": true
},
"status": {
"type": "string",
"description": "Updated Task status (Triaged, Planning, Planned, Design In Progress, Ready for Implementation, In Progress, Under Review, Revisions Needed, Feedback Failed, Revision In Progress, Partially Merged, Done, Archived, Abandoned, Superseded, Blocked, Knowledge Extraction)",
"nullable": true
},
"priority": {
"type": "integer",
"format": "int64",
"description": "Updated task priority",
"nullable": true
},
"complexity_fibonacci": {
"type": "integer",
"format": "int64",
"description": "Updated task complexity",
"nullable": true
}
}
}
3. Working Tool Schema for Comparison
get_task (working):
"get_task": {
"description": "Request struct for getting a task by ID",
"required": ["task_id"],
"properties": {
"task_id": {
"type": "integer",
"format": "int64",
"description": "Task ID to retrieve"
}
}
}
Additional Context
- Server: Rust-based MCP implementation
Let me know if you need any other diagnostic data!
Hi, I'm having a similar issue in both Claude Desktop and Claude Code. When an MCP tool is expecting multiple arguments, Claude sends none. If a tool is expecting a single argument, Claude sends it with no issue.
If I direct Claude to call the problematic tool call(s) with a single argument, Claude successfully sends off the request with a single argument.
When trying to call tool calls with multiple arguments in the problematic MCP, Claude Desktop's UI disappears leaving a blank window.
I'm seeing this in the CLI. I had an MCP server implementation via SSE, switched it to streamable HTTP (using claude!), and now tools hosted on the MCP server fail because the client-side environment isn't serializing and passing arguments in the MCP protocol request. The server correctly receives tool invocation requests, but the arguments payload is always an empty object ({}).
You can see it in the HTTP request from client to MCP server. The JSON-RPC payload for tool calls contains an empty arguments object, even when parameters were in the initial call.
{
"method": "tools/call",
"params": {
"name": "navigate",
"arguments": {} <-- Where'd they go?
},
"jsonrpc": "2.0",
"id": 8
}
Version: 1.0.30 (Claude Code)
I can reproduce the same too with version 1.0.30 (Claude Code).
I'm running a FastMCP (TS) server: https://github.com/walterra/eddoapp/blob/main/packages/server/src/mcp-server.ts
It works for quite simple arguments like this:
{
"method": "tools/call",
"params": {
"name": "createTodo",
"arguments": {
"title": "write bug report"
}
},
"jsonrpc": "2.0",
"id": 2
}
But it passes empty arguments for more complex tasks:
{
"method": "tools/call",
"params": {
"name": "createTodo",
"arguments": {}
},
"jsonrpc": "2.0",
"id": 6
}
I can ask Claude Code to draft the arguments object, it understands the MCP server's requirements, for example:
{
"title": "the-title",
"description": "the-description",
"context": "code",
"tags": ["bug"],
"link": "https://github.com/walterra/eddoapp/issues/28"
}
But it doesn't pass it on to the request. This is the error message I see:
Let me create the todo for GitHub issue #28 with the proper parameters:
⎿ Error: MCP error -32602: MCP error -32602: Tool 'createTodo' parameter validation failed: title: Required. Please check the parameter types and
values according to the tool's schema.
@walterra Out of curiosity, was that using the Streaming HTTP or SSE flavor? Is everything there needed for a reproduction for @adamkwhite there if he needs one?
I'm starting the FastMCP server like this:
import { FastMCP } from 'fastmcp';
const server = new FastMCP({
name: 'eddo-mcp',
version: '1.0.0',
ping: {
logLevel: 'info',
},
instructions:
'...',
});
await server.start({
transportType: 'httpStream',
httpStream: {
port: 3001,
},
});
This is how I added the mcp server to Claude Code:
# 3001=plain server, 3002=reverse proxy for logging
claude mcp add --transport http eddo-server http://localhost:3002/mcp
When Claude Code connects, FastMCP logs this message:
[mcp-proxy] establishing new SSE stream for session ID 194c2e03-6f4d-448c-8e9d-1dbe8be1d173
1. MCP Server Debug Logging
I'm using mtmproxy as a reverse proxy to log the requests: mitmweb --mode reverse:http://localhost:3001 -p 3002
In mcp-server.ts you should see the zod schemas, esp. for createTodo where I'm having the issue.
2. Schema Context
From mcp-server.ts:
// Create Todo Tool
server.addTool({
name: 'createTodo',
description: `Create a new todo item in the Eddo system.
Creates a TodoAlpha3 object with:
- Auto-generated ID (current ISO timestamp)
- Empty time tracking (active: {})
- Not completed status (completed: null)
- Default due date of end of current day if not specified
Returns: "Todo created with ID: <generated-id>"`,
parameters: z.object({
title: z
.string()
.describe('The main title/name of the todo item (required)'),
description: z
.string()
.default('')
.describe(
'Detailed description or notes for the todo. Can include markdown formatting',
),
context: z
.string()
.default('private')
.describe(
'GTD context category for organizing todos (e.g. "work", "private", "errands", "shopping", "calls")',
),
due: z
.string()
.optional()
.describe(
'Due date in ISO format (YYYY-MM-DDTHH:mm:ss.sssZ). Defaults to 23:59:59.999Z of current day if not provided',
),
tags: z
.array(z.string())
.default([])
.describe(
'Array of tags for categorization and filtering. Can be used for projects, priorities, or custom categories',
),
repeat: z
.number()
.nullable()
.default(null)
.describe(
'Number of days to repeat this todo after completion. Set to null (default) for no repeat. When completed, a new todo will be created with due date shifted by this many days',
),
link: z
.string()
.nullable()
.default(null)
.describe(
'Optional URL or reference link related to this todo. Can be used for documentation, tickets, or external resources',
),
}),
execute: async (args, { log }) => {
log.info('Creating new todo', { title: args.title, context: args.context });
...
3. Working Tool Comparison
So far I haven't seen similar problems with the other commands defined in mcp-server.ts.
Claude Code version: 1.0.31 (Claude Code)
Same issue here, random tool calls are run as expected and others simply aren't getting passed any arguments. Number of arguments defined for the tool call don't seem to matter, e.g. different tool calls with identical params (same names and/or types) seem to arbitrarily succeed or fail.
I'm surprised this ticket's been open as long as it has, it seems like it'd be a massive blocker for a lot of customer's workflows (it is for mine), but hopefully it gets resolved soon.
EDIT: some further detail, I went ahead and updated the MCP tools that had one only one arg to require at least two, and that seemed to resolve a lot of the problems with CC using those tools properly, but it's not 100%. It often/randomly still just fails to pass any args, all of which are flagged as required.
EDIT 2: Updated to latest (1.0.48) hoping for the best, but no such luck. The worst part of these failures is as soon as it fails it just immediately begins bludgeoning the MCP server repeatedly without any args, I have to carefully monitor it instead of letting it run with tasks so I can kill the process. Once it gets into this state, it does not evaluate the errors returned from the MCP that explicitly state the issue or attempt to alter its behavior.
+1, same issue here. here is what claude code says about it...
⏺ Claude Code MCP Tool Parameter Bug Report
Summary
Claude Code fails to pass parameters when invoking the update_page MCP tool, despite the same parameter passing mechanism working correctly for other tools like create_page, get_page, and flip_coin.
Environment
- Claude Code Version: 1.0.53 (from User-Agent header)
- MCP Protocol Version: 2024-11-05
- Server: Doxyde MCP server (custom implementation)
- Date: July 16, 2025
Bug Description
When invoking the update_page MCP tool through Claude Code's interface, the parameters are not passed to the server. The server consistently receives an empty arguments object {} regardless of what parameters are provided in the Claude Code interface.
Expected Behavior
When invoking an MCP tool with parameters like: mcp__doxyde__update_page page_id: 10 title: "New Title"
The server should receive: { "id": 2, "jsonrpc": "2.0", "method": "tools/call", "params": { "arguments": { "page_id": 10, "title": "New Title" }, "name": "update_page" } }
Actual Behavior
The server receives: { "id": 2, "jsonrpc": "2.0", "method": "tools/call", "params": { "arguments": {}, "name": "update_page" } }
Evidence
- Network Packet Capture (tcpdump)
Raw HTTP request captured showing empty arguments: {"method":"tools/call","params":{"name":"update_page","arguments":{}},"jsonrpc":"2.0","id":5}
- Server Logs
Multiple attempts showing consistent empty arguments: 2025-07-16T11:28:39.572843Z INFO doxyde_web::handlers::mcp_http: MCP RAW REQUEST BODY: {"id":2,"jsonrpc":"2.0","method":"tools/call","params":{"arguments":{},"name":"update_page"}} 2025-07-16T11:28:53.387255Z INFO doxyde_web::handlers::mcp_http: MCP RAW REQUEST BODY: {"id":3,"jsonrpc":"2.0","method":"tools/call","params":{"arguments":{},"name":"update_page"}} 2025-07-16T11:29:42.282998Z INFO doxyde_web::handlers::mcp_http: MCP RAW REQUEST BODY: {"id":3,"jsonrpc":"2.0","method":"tools/call","params":{"arguments":{},"name":"update_page"}}
- Working Examples with Other Tools
The same Claude Code instance successfully passes parameters for other tools:
flip_coin with parameters: 2025-07-16T11:22:20.370665Z INFO doxyde_web::handlers::mcp_http: MCP RAW REQUEST BODY: {"id":9,"jsonrpc":"2.0","method":"tools/call","params":{"arguments":{"times":3},"name":"flip_coin"}}
get_page with parameters: 2025-07-16T11:17:26.891744Z INFO doxyde_web::handlers::mcp_http: MCP RAW REQUEST BODY: {"id":6,"jsonrpc":"2.0","method":"tools/call","params":{"arguments":{"page_id":10},"name":"get_page"}}
- Tool Definition
The update_page tool is defined identically to working tools:
{ "name": "update_page", "description": "Update page title, slug, or template", "inputSchema": { "type": "object", "properties": { "page_id": { "type": ["integer", "null"], "description": "ID of the page to update (required)" }, "title": { "type": ["string", "null"], "description": "New page title (optional)" }, "slug": { "type": ["string", "null"], "description": "New URL-friendly identifier (optional)" }, "template": { "type": ["string", "null"], "description": "New page template (optional)" } }, "required": ["page_id"] } }
- Verification via curl
The tool works correctly when called directly via curl:
curl -s -X POST http://localhost:3000/.mcp/45a8ae64-3ad7-49b6-b9a8-0d1e2e097fa4
-H "Content-Type: application/json"
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "update_page",
"arguments": {
"page_id": 10,
"title": "Fidgets Foo - Amazing Spinning Toys"
}
}
}'
Response: { "id": 1, "jsonrpc": "2.0", "result": { "content": [ { "text": "{\n "id": 10,\n "slug": "fidgets-foo",\n "title": "Fidgets Foo - Amazing Spinning Toys",\n "path": "/fidgets-foo",\n "parent_id": 3,\n "position": 1,\n "has_children": false,\n "template": "default"\n}", "type": "text" } ] } }
Reproduction Steps
- Connect Claude Code to an MCP server with an update_page tool
- Invoke the tool using Claude Code's interface with parameters
- Observe server logs showing empty arguments object
Impact
This bug prevents users from using any MCP tools that follow the update_page pattern through Claude Code, requiring workarounds like direct HTTP calls.
Additional Notes
- The issue persists across multiple Claude Code restarts
- The issue persists across multiple server rebuilds and restarts
- Tool definitions were modified to match working tools (e.g., changing "type": "integer" to "type": ["integer", "null"]) with no effect
- The MCP server implementation correctly handles errors and returns proper JSON-RPC error responses
Workaround
Users must use curl or other HTTP clients to call the affected tools directly, bypassing Claude Code's tool invocation mechanism.
I have the same problem.
I input "Show me more from the file," and Claude correctly calls get_chunks_around once with all required parameters. However, when it tries to call the same tool again shortly after, the visible JSON payload appears complete in the UI, but the actual request logged by the backend is missing required parameters like filepath_id.
The UI shows that parameters were included, but the actual request sent lacks the arguments object, resulting in validation errors on the server.
first call log is OK 2025-07-23T08:01:06.722Z [doc-searcher] [info] Message from client: {"method":"tools/call","params":{"name":"get_chunks_around","arguments":{"filepath_id":2,"chunk_id":0,"window":10}},"jsonrpc":"2.0","id":8} { metadata: undefined }
second call log is FAILED
2025-07-23T08:01:10.543Z [doc-searcher] [info] Message from client: {"method":"tools/call","params":{"name":"get_chunks_around"},"jsonrpc":"2.0","id":12} { metadata: undefined } 2025-07-23T08:01:10.545Z [doc-searcher] [info] Message from server: {"jsonrpc":"2.0","id":12,"result":{"content":[{"type":"text","text":"Input validation error: 'filepath_id' is a required property"}],"isError":true}} { metadata: undefined }
