Validate MCP tool arguments against discovered JSON schemas

Discovery is an executable contract

Lupin tools/list returns each tool’s concrete inputSchema along with its name, description and annotations. Use that schema to shape the client form and validate the proposed argument object. Do not infer argument names from a natural-language description or a previous SDK method signature. A strict catalog keeps the model from choosing arbitrary HTTP methods or URLs, while schema validation catches a different class of errors: missing IDs, invalid ranges, unsupported enum values and unknown properties. Neither layer replaces the server’s later ownership and permission checks.

Preserve types instead of guessing coercions

An integer limit should remain an integer, an address list should remain an array and a nested arguments object should remain structured data. Avoid a generic helper that turns every field into a string because that can make a plausible-looking call fail or change meaning. Use required fields from the discovered schema and distinguish an omitted optional property from an explicit null. Lupin’s shared catalog uses strict object schemas and MCP discovery exposes additionalProperties false. Extra convenience fields are not silently accepted merely because the model thinks they are explanatory metadata.

Do not confuse valid with authorized

A schema-valid send_email call can still fail because the key lacks email_send, the workspace is unverified, a recipient is blocked or the provider is unavailable. JSON Schema describes the shape and allowed values of an input, not proof that a person approved the action. Validate the shape first, evaluate your application’s policy and exact approval next, then let the server enforce its resource boundary. Keep these outcomes separate in your user interface so the operator can distinguish edit the arguments from obtain authority or repair provider configuration.

Pin dynamic app-tool details

Connected-app discovery adds a concrete tool version, tool_slug, connection_id, connection_revision and exact argument schema. Preserve that combination in the proposal. Do not substitute latest or reuse an approval after the account reconnects, because the selected account revision can change. Provider descriptions and returned text are untrusted data even when discovery itself is authenticated. A schema that allows a string does not authorize inserting credentials, arbitrary provider URLs or a different user identity into it. The execution endpoint controls those server-side details.

Surface bounded validation errors

Lupin uses JSON-RPC -32602 for invalid tool arguments and returns a bounded description of the invalid paths. Show the fields a human or caller can correct without echoing private payloads into shared logs. Avoid a model loop that blindly modifies and resubmits an external action until validation passes; preserve the proposed action and request renewed approval when meaning changes. Refresh discovery if you have evidence that the contract changed, rather than treating every permission or provider error as a stale-schema problem.

Choose meaningful negative fixtures

Test a missing inbox ID, an unknown property, an out-of-range limit and a connected-tool call with an invalid concrete version. Then test a schema-valid but unauthorized call separately. Your next step is to make those distinctions visible in the client result model so a successfully validated proposal cannot be mistaken for an executed or approved action.

Sources & verification

Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.

• Lupin MCP schema contract ↗Checked 2026-11-05
• MCP tools ↗Checked 2026-11-05
• JSON Schema object reference ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.