Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses several behavioral traits beyond the annotations: the automatic model selection logic, the free-tier nature with no token cost, the per-call USDC payment via x402, and that API keys are handled internally. It does not contradict annotations (readOnlyHint=false, destructiveHint=false), and adds meaningful context that helps an agent understand side effects and constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences and every sentence earns its place: purpose, model mapping, cost model, and usage guidance. The task-type mapping is presented compactly in a parenthetical list, keeping the description tight and front-loaded with the primary action and outcome.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 params, no output schema, action with side effects), the description adequately covers what it does, how models are chosen, the payment mechanism, and when to use it. It does not detail the response format (the completion text), but that is standard for an inference endpoint and implied by the schema; the description is complete enough for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the description adds value by mapping task types to specific models (reasoning → DeepSeek R1, code → Llama 3.3, etc.), which enriches the 'task' parameter semantics beyond the schema's generic 'Used for model selection.' It also aligns 'fast' with Llama 3.1 8B, reinforcing the preferSpeed parameter behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Route') and resource ('a task... to the best available free AI model and run inference'), and distinguishes itself from sibling tools like compute.cost and compute.models by positioning itself as the inference execution tool. The model selection examples further clarify the exact scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit usage context: 'Use this when an agent needs to delegate a subtask to a language model without managing model selection or API keys.' This clearly indicates when to invoke it, though it does not name specific alternative tools for model listing or cost estimation, so it stops short of full when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.