invalid_arguments

What it means

The Platform API returned HTTP 400 with code invalid_arguments. The arguments in your POST /api/platform/v1/tools/:name request do not match the input schema the tool declares.

Arguments are validated before anything is called. When you get this code, the tool did not run and no side effects were produced, so you can correct the request and send it again without worrying about a partial call. The response follows the standard error shape: an error object with code, message and hint. Match on the code value, since codes are stable and messages are not written for parsing.

Why you are seeing it

Four situations produce this code: an argument the schema does not declare, a missing required argument, a value of the wrong type, or a value outside its range, enum or pattern. A request that sends q to a tool that does not accept q, omits a required field, passes a string where a number is expected, or sends limit above its maximum all land here.

Only the first problem is reported. The message names it, for example "unknown argument: q" or "limit must be at most 50". If your request has several issues, you will fix them one at a time across successive calls.

How to fix it

Fetch the tool definition with GET /api/platform/v1/tools and read that tool's inputSchema. Send only the arguments the schema declares, include every required one, and give each value the declared type and a value inside its range, enum or pattern.

Then send the corrected request again. Because validation happens before execution, a rejected request changes nothing, so there is no cleanup step and no need to reconcile state.

If the message points at an argument you believe you sent correctly, check the shape of the value rather than its intent. A number quoted as a string, an array where a single value is expected, and a value just past a stated limit are all common causes.

Handling it in code

Treat invalid_arguments as a request-side error and do not retry it unchanged. Read the code field of the error object and branch on it; never match on the message text. Log the message and hint, since they name the first problem and make the fix obvious in your logs.

A practical pattern is to validate locally against the inputSchema before you call the tool, so obvious mistakes never leave your service. If you build arguments dynamically, guard against extra keys slipping in from shared or default objects.

Do not surface this to end users as a server fault. It indicates a malformed request from your integration, and the appropriate response is to correct the payload, not to back off or alert on platform availability.