Argument validation before execution

The failure it prevents

In production: Malformed arguments execute, or the model burns turns guessing the format you wanted.

A model produces arguments that are almost right: a relative path where the tool needed an absolute one, a date in the wrong format, an enum value from a different tool. If the tool executes anyway, you get a confusing downstream failure. If the tool rejects with a raw stack trace, the model guesses again, and again, and each guess costs a turn.

Anthropic has published exactly this loop. In their agent evaluations, large numbers of invalid-parameter errors pointed at unclear tool descriptions, not at a weak model. On their SWE-bench agent, switching to absolute filepaths after watching relative-path mistakes made the model use the tool flawlessly. Validation in the harness catches the same class of error before it costs a real call.

How it works

The schema is the contract. MCP tool definitions carry an inputSchema (JSON Schema) for parameters, and the specification puts validation duties on both sides: servers must validate all tool inputs, and clients should show tool inputs to the user before calling on sensitive operations. A harness that checks arguments against the inputSchema before dispatch gets the same protection without a network round trip.

Check more than types. Required fields, enum membership, ranges, string formats (dates, paths, URLs), and cross-field rules (end after start) catch the errors models actually make. Then fail with an error written for the model: what was wrong, what shape was expected, one example. Anthropic is direct about this: error responses should communicate specific, actionable improvements rather than opaque error codes or tracebacks.

Design formats the model cannot get wrong (poka-yoke, in Anthropic's term). Prefer absolute paths over relative ones, unambiguous parameter names (user_id, never user), and enums over free text. Every format you tighten is a validation error that never happens.

When to use it

• Every tool call, unconditionally; this is the cheapest pattern in the pillar.
• Tools with stringly-typed inputs: paths, dates, queries, URLs, identifiers.
• Write operations, where a malformed argument does damage instead of returning data.
• Tools fed by user content, where argument shape is least predictable.

When to skip or soften it

• Read-only exploratory calls in a sandbox, where a failed call is cheap and the model is meant to probe the interface.
• Tools whose schema changes faster than your harness copy; validate against the schema the server publishes at runtime instead of a cached copy.

Tradeoffs

Strict validation rejects borderline calls that might have worked, and every rejection is a model turn spent recovering. Too strict is its own failure mode: validate the shape, not the semantics you cannot know. The second cost is maintenance. Schemas drift from tools; a harness validating against last month's schema manufactures errors. Fetch the schema from the tool (MCP tools/list) or generate the check from the same definition the server uses.

Tool input schema (MCP)

MCP tools declare an inputSchema as JSON Schema. The harness validates outgoing arguments against this before tools/call runs. additionalProperties: false closes the most common hole, arguments the tool never asked for.

{
  "name": "book_room",
  "description": "Book a meeting room. Dates are ISO 8601 with timezone.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "room_id": { "type": "string" },
      "start_iso": { "type": "string", "format": "date-time" },
      "duration_min": { "type": "integer", "minimum": 15, "maximum": 480 }
    },
    "required": ["room_id", "start_iso"],
    "additionalProperties": false
  }
}

Shape source: MCP specification 2025-06-18: tools. Placeholders only; adapt names and numbers to your stack.

Implementation checklist

• Arguments are checked against the published inputSchema before dispatch, not after a failure.
• Path, date, and identifier formats are pinned in the schema (format fields, patterns, enums).
• Rejection messages name the field, the expected shape, and one valid example.
• Invalid-parameter errors are counted per tool; a rising count triggers a description review, not a bigger retry budget.
• Sensitive calls show validated inputs to a human or an approval gate before execution.

Related patterns and directory links