jev_tool_route

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

Annotations already supply readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds the non-obvious behavioral facts that this tool neither invents arguments nor executes calls, which prevents two common misuses and goes beyond the annotation layer.

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?

Two terse clauses, front-loaded with the operative verb and followed by the two essential negative constraints. Every word earns its place; there is no filler or restatement of the schema.

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?

For a routing tool with six parameters and no output schema, the description establishes the tool's role but does not cover the required task and observation fields, the review_at/auto_accept controls, or what the selection result looks like. It is adequate for orientation but not complete for unambiguous invocation.

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?

With only 17% schema description coverage, the description needed to clarify the six parameters. It only clarifies the selection container ('prepared calls') and says arguments are never generated, leaving task, observation, model, review_at, and auto_accept without added meaning. The schema descriptions are left to carry too much weight.

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 names the specific operation ('Select') and the exact object ('prepared calls'), and then draws a hard line with 'never generates arguments or executes calls.' This makes it immediately distinguishable from planning or execution tools, even without naming a sibling explicitly.

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 phrase 'Select from prepared calls' implies the intended context: use when a host has already prepared candidate calls and a choice must be made. The negative clauses provide a clear boundary, but no explicit when/when-not conditions or sibling alternatives are named.

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