JSON Schema can constrain the shape of an agent’s tool arguments; it cannot decide whether those arguments are authorized, timely or factually correct. Treat structured calling as the first validation layer, followed by resource ownership checks, side-effect approval and state reconciliation.
Three validation levels
At the syntax level, parse the model-proposed call and ensure valid JSON. At the contract level, validate enum membership, types, bounds and the exact supported schema revision. At the policy level, confirm the authenticated user, resource ownership, destination, amount and allowable state transition. A call may pass strict schema validation while asking to refund another customer’s order. The last check must happen in application code or the destination API, not in a model’s response text.
Design a small safe interface
Prefer a tool such as create_refund_proposal(order_ref, reason_code) over send_arbitrary_http_request(url, body). Resolve the account identity on the server rather than inviting the model to supply it. Distinguish a proposed action from a committed action; use enums for finite transitions and require idempotency tokens for writes. OpenAI documents strict tool parameter constraints, but those guarantees apply to the shape of accepted arguments, not the correctness of the underlying business decision.
Worked example: currency in an invoice
An extractor may return amount=1200 and currency=USD while the invoice visually shows CAD. Both values might satisfy a strict schema. Before payment, compare them with the source document, vendor master record and selected settlement currency. Fail closed if the evidence conflicts. Present a structured diff to the approver showing source line, parsed value, final destination and expected economic effect; revalidate the state if the approval is delayed.
Version migration and failure treatment
Pin the schema and the calling API variant; some interfaces normalize tool parameters while others require explicit strict declarations. Reject unknown properties, missing required values, ambiguous dates, oversized strings and unsupported tool versions. When a model generates a schema-invalid call, return a bounded validation error and allow at most a controlled retry for read-only or proposal actions. Do not let a retry bypass a rejected authorization decision.
Testing what matters
Construct tests for boundary numbers, lookalike IDs, cross-tenant resources, strings that attempt to smuggle instructions, enum drift, duplicate calls and changes to a record between proposal and commit. Measure schema rejection rates and unauthorized backend write rates separately. If a task only needs deterministic transformation, a conventional parser or rules engine may be cheaper and more auditable than tool-calling inference.
Make schema design a policy exercise
A tool name is not an access-control list. Document who can invoke it, whether its parameters can identify other users, and what the smallest acceptable output shape is. Prefer separate tools for viewing, proposing and executing changes. A programmatic executor can enforce amount ceilings, source-account checks and allowed status transitions even when the model tries to submit a perfectly formed but unauthorized call.
Production acceptance and review test
Maintain golden argument files for every schema revision, together with invalid boundary cases. A new model is accepted only if the calls validate, have correct application semantics and stay within a measurable unsafe-call budget. Distinguish errors caused by the model from errors caused by a stale schema definition, and do not automatically repair a forbidden call into a permitted-looking call without user consent.
Scope, version and availability
Features documented by a current vendor page are not assumed to have existed in earlier releases. Where a historical launch date is provided, it is supported by a dated first-party publication. Exact subscription tier, market availability, quotas, API billing, licensing permissions and deployment regions are not asserted without a directly applicable record. This is researched editorial guidance rather than a claim of independent hands-on testing, deployed operation or statutory certification.
Sources and Further Reading
- OpenAI — Function calling guide (source reviewed 2026-10-25)
- Microsoft — Playwright MCP README and configuration (source reviewed 2026-10-25)