Confirm your tool schema actually triggers — with a real call
A function or tool schema that reads correctly can still misbehave: the model might not call it, might pick the wrong tool, or might produce arguments that miss a required field. The only way to know is to send a real request. This harness takes your tool schema and a test message, calls OpenAI or Anthropic directly with your own key, and shows exactly what the model did with your tool.
How it works
You paste a single tool definition as JSON — name, description, and a JSON Schema parameters object — plus a user message that should trigger it. The harness rewrites your definition into the shape each provider expects: OpenAI’s tools array with a type of function, or Anthropic’s tools array with an input_schema. It sends the request straight from your browser to the provider endpoint using your key, then inspects the response for a tool call. It reports the tool name the model chose, pretty-prints the argument JSON, validates that the arguments parse, and checks that the required top-level properties declared in your schema are present.
What a good tool schema looks like
The three parts of a tool definition each affect how reliably the model calls it:
Name: Keep it short, lowercase, and verb-noun (for example, get_weather,
search_products, send_email). Avoid abbreviations and underscores where
natural words work better. The name is part of what the model matches against
the user’s intent, so it should be self-describing.
Description: This is the most important part for triggering. The model reads the description to decide whether to invoke the tool. A vague description like “retrieves information” may cause the model to skip the tool for natural-sounding queries. A specific one — “retrieves the current weather for a given city and country code, including temperature, humidity, and wind speed” — gives the model enough signal to call it reliably from a user message like “what’s the weather in Paris?”
Parameters: Describe each parameter clearly in its own description field,
including valid values, units, and format constraints. "format": "ISO 8601 date" and
"description": "Temperature unit: celsius or fahrenheit" prevent the model
from guessing. Mark truly optional parameters as not required in the schema;
marking too many fields as required can cause the model to refuse to call the
tool when it cannot fill all of them from context.
Common failure modes this harness surfaces
- Tool ignored: The model responds in prose without a tool call. Usually means the description is too vague or the user message does not clearly match it.
- Wrong arguments: The model calls the tool but supplies unexpected values — dates in the wrong format, an out-of-range number, or a key not in the schema. Check parameter descriptions and add explicit format constraints.
- Missing required fields: The model omits a required parameter it could not infer from the message. Either add it to the test message or mark it optional if it is genuinely not always needed.
- Model declines to call: Some models have safety filters that prevent certain tool calls even when the schema is correct. Test with a clearly benign message to isolate this case from genuine schema problems.
Tips and notes
Write a test message that a real user would actually send, not one that quotes the tool name — you are testing whether the description is clear enough for the model to choose the tool on its own. If the model ignores your tool, tighten the description and make the parameter names and descriptions unambiguous. Your key is used only for the direct provider request and is never stored; use a scoped test key with the minimum necessary permissions. Real API calls cost a small amount per request, so this is a debugging tool rather than something to loop. Run it whenever you change a schema to catch regressions before they reach production.