An Anthropic tool definition is flatter than the OpenAI equivalent. It carries a name, a description and an input_schema, without the enclosing function object that the OpenAI format uses.
The input_schema field holds a standard JSON Schema object describing the tool arguments. As with the OpenAI format, the $schema keyword does not belong inside it — the API expects a schema body rather than a standalone schema document.
The description does more work here than developers expect. It is the primary signal the model uses to decide whether a tool applies to the current turn, and when several tools are available a vague description is the usual cause of the wrong one being selected. Describe when to use the tool, not only what it does.
Because both providers wrap the same underlying JSON Schema, moving a definition between them is mechanical: the schema body is identical and only the wrapper changes. That is worth knowing if you support both, since it means you can maintain one schema and generate both definitions rather than keeping two in sync by hand.
Property descriptions inside the schema matter as much as the tool description. A model choosing arguments reads them the same way it reads a structured output schema, and a well-described parameter produces markedly better argument values than a bare type.
One practical note: validate a real tool-call payload against your schema before shipping. A definition that the API accepts is not the same as a definition that produces the arguments you expected, and the gap between those two is where most tool-calling bugs live.