gemini-cli - 💡(How to fix) Fix bug(core): `wait_for_previous` is forwarded to MCP and discovered tool arguments

Summary

wait_for_previous is scheduler metadata, but the runtime forwards it to external tools unchanged. That breaks the external tool contract for strict MCP servers or discovered-tool commands that validate exact input schemas, because they receive an extra property that was not part of the original tool definition.

Related but distinct from #26643: that issue is about default scheduling behavior and redundant parallel calls. This one is about scheduler-only metadata leaking into the payload sent to external tools.

Why this happens

At commit a00d03efc62de08274619cf7da96569ae51ecbf3:

• BaseDeclarativeTool.addWaitForPreviousParameter() injects wait_for_previous into object parameter schemas.
• The scheduler reads request.args['wait_for_previous'] to decide whether a tool call should wait.
• Discovered-tool execution then writes JSON.stringify(this.params) to the subprocess stdin without stripping reserved fields.
• MCP tool execution constructs a function call with args: this.params, and McpClient.callTool() forwards that object as the MCP arguments payload.

Reachability

This is reachable in normal operation, not dead code:

• The prompt instructions explicitly tell the model to set wait_for_previous when sequencing dependent tool calls.
• Scheduler tests already build tool requests that include wait_for_previous: true.

Reproduction

1. Register an MCP tool or discovered tool command that validates inputs strictly, for example with additionalProperties: false or equivalent.
2. Invoke that tool with wait_for_previous: true so the scheduler will sequence it.
3. Observe that the external tool receives wait_for_previous in its input payload and can reject the call as an unexpected property.

Expected behavior

wait_for_previous should influence scheduler behavior only. It should not be forwarded to external tool implementations.

Actual behavior

The same args object is used both for scheduling and for the payload sent to discovered tools / MCP servers, so scheduler-only metadata leaks across the tool boundary.

Related history

• #26643 tracks default wait_for_previous behavior causing redundant parallel calls.
• #17235 and closed PR #21963 are useful precedent for stripping MCP-facing metadata fields for compatibility, but they address $schema, not runtime argument forwarding.

Possible fix

Strip reserved scheduler fields before tool.build(...), or at least before each external executor forwards params to discovered tools and MCP calls.