A schema validator for tool arguments
Hand-written to show the checks. In real projects use Pydantic, Zod or a Jackson plus Bean Validation setup (Topic 4.5). The course's Json class stands in for Jackson in Java.
Tool arguments come from a model that users and documents can steer, so they are untrusted input. Parse them in a try block, check them against the schema, allow-list tool names and paths, and never pass them to eval, a shell or a string-built query.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write parse_args(text) that returns (args, error): args is the dict and error is None on success; otherwise args is None and error is "not valid JSON" or "not an object".
Write reject_unknown(args, allowed) that returns a list of messages "unknown argument: <key>" for each key not in allowed, in the order they appear in args.
Explain it without notes
Why must tool arguments be treated as untrusted input even though your own model produced them?
List the checks a tool runner should make between receiving a tool call and running the function.
Why is eval on tool arguments dangerous and what do you do instead for a calculator tool?
Expected output
case 1: ok
case 2: rejected: arguments are not valid JSON
case 3: rejected: missing required argument: city
case 4: rejected: days: expected integer, got string
case 5: rejected: days: 30 is above the maximum 7
case 6: rejected: unit: kelvin is not one of celsius, fahrenheit
case 7: rejected: unknown argument: debug
case 8: rejected: arguments must be a JSON object