An agent may guess a parameter with a plausible name. If a program discards it and executes the remaining input, the user can believe that the entire request was honored. I chose to reject unknown fields at the execution boundary.
An ignored condition can create a misleading success
If a date arrives under the wrong key and is discarded, a program can execute its default behavior. Without an error, the caller may report that scheduling was honored too. The rest succeeds while a condition important to the user disappears.
A strict object rejects keys outside the declared contract. It cannot detect every natural-language misunderstanding, but it prevents silent progress with a condition the implementation does not recognize. Permissive input is not always a friendlier API. Exposing the mismatch lets the caller inspect the current contract and correct it.
Validate the outer envelope and the inner operation
The MCP intermediary checks tool name, top-level arguments and required keys. The browser pipe then parses ExternalRequest and the internal ToolCall. I do not describe the outer JSON Schema as complete runtime validation of every nested condition. Host-side contracts continue the stronger checks.
Tests reject an extra JavaScript field in a call and a nonexistent arbitrary browser evaluation operation. A valid envelope does not establish a valid inner tool. Distinguishing the two stages prevents limited intermediary checks from being advertised as complete input validation.
Valid shape still needs action-specific and live checks
The plugin request supports actions such as list, inspect, run and status. A field optional in the shared schema can still be required for a specific action. A correctly shaped task UUID is rejected if it is not the current execution. Format validation and live-state validation cannot replace each other.
Context requires nonempty profile, workspace and tab strings, but strings do not prove ownership. The actual host state must agree. The public contract defines what can be supplied; the execution layer determines whether that input is currently valid for this operation.
Size limits are part of the workflow contract
Goals, parameter names and input bodies have length bounds. The generated-file entry accepts a name and explicit bytes rather than an arbitrary local path. Silently truncating an oversized string could discard important content or conditions, so a contract violation should return an error instead.
These limits are not complete filesystem access control. Existing Python execution retains local user permissions. A length bound protects a particular API message boundary. I describe that narrow restriction separately from surrounding execution privileges so an integrator does not infer the wrong guarantee.
Change the caller-facing and host contracts together
Adding a field takes more than one new line in a description. Discovery schema, host parser, action handler and error messages need alignment. Updating only one side can make discovered input fail elsewhere or acquire a different meaning.
This article reads the current schemas and concrete rejection cases in the integration test. It is not a new fuzzing campaign for every combination. Evidence that unknown fields and arbitrary execution tools are rejected differs from a claim that every semantic mistake is prevented. Details such as date format versus calendar validity still require the relevant individual contract.
An explainable rejection helps the next input become correct
An agent-friendly tool does not need to accept every string. It needs to expose what is missing and which contract should be read again. Rejecting one unknown field clearly is a smaller problem than repairing an unintended default action after it runs.
Other work APIs can use the same principle: define fields, bounds and live-state conditions, and keep discovery and execution aligned. Passing format validation is not workflow completion; outcome verification remains a separate step. Precise input is an interface that helps the agent make a better decision.