bug(core): `wait_for_previous` is forwarded to MCP and discovered tool arguments

[fallintoplace]

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

• bug(core): redundant parallel tool calls due to wait_for_previous default #26643 tracks default wait_for_previous behavior causing redundant parallel calls.
• Missing JSON schema key intermittently #17235 and closed PR fix(core): strip $schema from MCP tool parameters for API compatibility #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.

[gemini-cli]

This issue appears to be a bug in how scheduler metadata is handled during tool execution. We have categorized it as a significant issue. Could you please provide the CLI version you are using to help us investigate?

[Keesan12]

Reserved fields should probably be stripped before forwarding arguments into MCP discovery. If wait_for_previous is a local control flag, keeping it out of the tool payload would reduce ambiguity and prevent downstream adapters from having to guess which fields are operational versus user-facing. That is a small interface cleanup with outsized debugging value.