Why must arguments be a string?

Because OpenAI models emit the arguments as a JSON string, and a training example has to match what the model produces. Writing them as a nested object is the most common reason a tool-calling upload is rejected — and the error message names the line, not the field.

Does it check my arguments against the schema?

Partly. It checks that every property the schema marks required is present, and — when the schema sets additionalProperties: false — that no unknown property was passed. It does not check types or formats; that is a job for a full JSON Schema validator .

No. Everything is parsed and checked in your browser.

Tool-Call JSONL Validator

updated 30 August 2026

Function calling is where the upload fails. The conversation validators check roles and content; none of them checks that arguments is a string rather than an object, that every tool_call_id is answered, or that the tool being called was ever declared. Those are the three that get a file rejected — after the upload, in a message that names neither the line nor the field.

Validate

Format Show warnings and notes

Drop a .jsonl file here, or In your browser · nothing uploaded

Input

Full report

Why this is separate from the other validators

The OpenAI and Anthropic validators check the conversation: roles, alternation, empty content, an assistant turn that exists. Tool calling adds a second structure on top of that — a declaration list, an id that has to round-trip, and an argument payload with its own encoding rules — and it is checked here rather than bloating both.

— S., [email protected]

What it checks — OpenAI

arguments is a JSON string. Not an object. "{\"city\":\"Paris\"}", not {"city":"Paris"}. It also has to parse, and to parse to an object.
Every tool_calls[].id is answered by exactly one later message with role: "tool" and a matching tool_call_id. A call with no result teaches the model to call and stop.
Every tool message answers a real call. An orphan role: "tool" message — usually left behind when a conversation was trimmed — is rejected.
Names are declared and legal. A call to a function missing from tools[] is an error; so is a name outside [A-Za-z0-9_-]{1,64}, and a name declared twice.
Parameter schemas are objects. "type": "object" at the top, properties present, and every entry in required actually in properties — the mismatch that makes a model omit an argument it was told to send.
Arguments satisfy the declared schema's required list, and respect additionalProperties: false when it is set.
The deprecated shapes are flagged: top-level functions and message-level function_call still work in some places and are not what to write in 2026.

What it checks — Anthropic

input is an object, not a JSON string. This is the mirror image of the OpenAI rule and the reason a file converted from one to the other fails.
input_schema, not parameters. Using OpenAI's field name is the most common single mistake in an Anthropic tools array.
Every tool_use block is answered by a tool_result with a matching tool_use_id, in a user message, as its first content block.
Blocks are in the right role — tool_use only from the assistant, tool_result only from the user.
Ids are unique and never answered twice.

Mixed formats

Auto-detect works per record, which means it will happily read a file with some OpenAI records and some Anthropic ones — and then say so in the summary, in red. A fine-tune file has one format; a mixture is usually two exports concatenated, and the fix is to convert one side with the chat format converter before merging.

What it does not check

Types inside the arguments, string formats, enum membership, and anything else a full JSON Schema validator does. It checks the structure a provider rejects on, not the semantics of your tool. It also cannot tell you that the result you recorded is the result the tool would really return — a training file full of plausible but invented tool outputs validates perfectly and teaches the model to hallucinate confidently.