TOO-DEC-01Tier ITool Use as Typed Contract

Typed Tool Catalog

Every tool the agent can call has a strict, versioned schema for inputs and outputs. No free-form calls.

Runtime: DecideAgentOps: Build & IntegrateSee on the matrix →
TYPED TOOL CATALOG Tool Definitionname · schemas Agentfunction call Validatorparams vsschema Executortyped invoke Typed Returnresult schemaValidate before invoke. No free-form argument parsing.
In Plain English

This page is the complete instruction page for one pattern called "Typed Tool Catalog." It explains the problem this pattern solves, the idea behind the solution, when you should (and should not) use it, and what happens afterward — both the good effects and the costs.

This matters because building AI agents is not just about making them clever. It is also about making them safe and predictable. Following a well-tested pattern like this one helps avoid common mistakes, and shows you exactly which safety rules and regulations it connects to, listed under "Standards Mesh" on this page.

Context

Without schemas, the agent guesses parameter names, types, and semantics. Guesses fail under edge cases, silently most of the time.

Problem

Free-form tool invocation is unreliable and untraceable.

Forces

  • LLM flexibility vs deterministic integration
  • Schema maintenance vs correctness

Solution

Define each tool as a typed function: name, parameter schema (e.g. JSON Schema), return schema, error contract, cost metadata. Expose to the agent via function-calling or equivalent. Validate parameters before invocation.

Applicability

  • All production agents
  • Any agent with more than a handful of tools

Anti-Patterns

  • "Pass the request through as JSON the model produces"
  • Schema documented only in the system prompt

Consequences

  • +Reliable invocation
  • +Enables static analysis and tests
  • Schema authorship cost
  • Discovery burden when catalog grows