Limit an AI tool to an explicit argument schema

A read-only lookup tool can still expose too much data if its arguments allow arbitrary filters, SQL or unlimited result counts. Give the tool a narrow contract that matches the task the model is allowed to request.

For a synthetic order lookup, accept an order ID and a small limit. Keep the tenant and permitted fields under server control. The tool should return a defined summary rather than an entire database row containing internal notes.

{
  "type": "object",
  "properties": {
    "order_id": { "type": "string", "minLength": 1, "maxLength": 64 },
    "limit": { "type": "integer", "minimum": 1, "maximum": 5 }
  },
  "required": ["order_id", "limit"],
  "additionalProperties": false
}

This is an application-level JSON Schema fragment, not a provider SDK request. The JSON Schema references document object properties and numeric bounds. A provider may impose additional schema restrictions.

Narrow tool schema surrounding an allowed lookup call.

Enforce the contract after generation

Validate the actual arguments received by the server. A prompt describing permitted arguments does not prevent a model from producing another shape. Reject extra keys such as tenant_id, include_secrets or raw_sql.

Use parameterized database queries and obtain tenant scope from the authenticated request. A short valid string can still contain punctuation that would be unsafe in a string-built SQL query. Schema length limits do not replace query parameterization.

Select the returned fields explicitly. If a future database migration adds a sensitive column, a serializer that returns every field can expose it through a tool whose argument schema has not changed.

Test permission and resource limits

Try a valid order owned by the caller, a nonexistent order and another tenant's order. Decide whether the latter two should produce the same public response to avoid revealing existence. Keep internal diagnostic records under appropriate access control.

Exercise zero, negative and oversized limits, an empty order ID and a request with unknown keys. The validator should reject those before the lookup runs. Apply request-rate and response-size limits too, since several small permitted calls can still consume resources or enumerate data.

Avoid adding a generic escape hatch whenever the model struggles. If the application needs another lookup shape, design and review that capability separately.

This contract has not been run against a live model or database. It establishes a reviewable intended boundary. Tool correctness also depends on the implementation's authorization, logging and output handling, including how results are shown to the user or passed back into model context.