Tool arguments need explicit types and fields

A call envelope tells us where arguments live, but not which arguments a tool accepts. A search function may require a string query and an integer limit. Receiving a dictionary is only the first check: missing fields, extra fields and wrong primitive types still need a deliberate response.

The lab uses a small trusted field map: each name declares string, integer or boolean. All fields are required, no extras are allowed, and values are not coerced. This is enough to learn the boundary without pretending to implement all of JSON Schema. A real provider adapter should use its documented schema dialect and still validate input in the application.

Python has a trap here: bool is a subclass of int. isinstance(True, int) is true, but a Boolean limit is not accepted by our integer argument contract. Exact type identity expresses the narrower policy. Likewise, the string "3" is not an integer just because a conversion could succeed.

print(isinstance(True, int))
print(type(True) is int)
print(type(3) is int, type('3') is int)

Compare exact key sets. Checking only that required keys exist allows a model to attach undeclared fields that some later code might accidentally use. Rejecting extras keeps the tool interface narrow and easy to test. An empty argument object is valid only when the declared map is empty.

Separate a bad argument from a bad tool configuration. An unsupported type name in the trusted schema is a developer error, so this function raises ValueError before checking the response. A valid schema with wrong model arguments simply returns False. The distinction helps a dispatcher report input errors without silently hiding broken application metadata.

arguments = {'query': 'notes', 'limit': 3, 'extra': True}
required = {'query', 'limit'}
print(required.issubset(arguments))
print(set(arguments) == required)

Build the validator and test extra fields, missing fields, Boolean limits, numeric strings and empty contracts. Do not add minimum lengths, range checks or filesystem rules here: the next layers have explicit places for those policies. Keeping the responsibilities separate makes each failure easier to explain and each test more meaningful.