jev_evaluate

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

Adds substantial behavior beyond the readOnlyHint=true/openWorldHint=true annotations: questions run in parallel and are billed only their own tokens ('speculative questions are nearly free'), Jev reads literally, it never generates text (only selects from options), and it discloses the ~64k token budget. It also explains answer semantics (noul = P(yes), ~0.5 = unsure, gate = auto/review/escalate). No contradiction with annotations; readOnlyHint is consistent with a pure evaluation tool.

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 long but well-structured into scannable sections (Writing questions, Answers, Budget) with front-loaded purpose. Every bullet earns its place — the authoring rules are essential for correct use of this three-variant question-type tool. A little tightening is possible but the complexity justifies the length.

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 highly complex tool (nested question variants, polymorphic state, thresholds, model override) with an output schema covering returns, the description is essentially complete. It addresses the failure-prone parts an agent would get wrong: instruction/criteria split, batching, literal reading, no-arithmetic rule, and the gate semantics. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the baseline is 3. The description earns a point above baseline by explaining how to structure the state and questions parameters: what belongs in instructions vs criteria, one judgment per question, path references like ticket.messages[0].text, and never asking it to count or compare. These usage patterns add meaning the schema alone doesn't convey.

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?

Opens with a specific verb+resource+scope: 'Ask Jev — a fast, calibrated judgment model — many typed questions about one shared state; returns probabilities plus a gate computed in code.' It also names the sibling family it belongs to and explicitly carves its niche: 'Use it for any judgment you want to branch on when no other jev_* tool fits.' An agent can distinguish this from jev_rank/jev_verify without opening any schema.

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?

Gives an explicit selection rule ('when no other jev_* tool fits') and backs it with a full authoring playbook: batch questions sharing a state into one call, send only the needed state, reference by path, always add an escape-hatch option, and compute arithmetic in code rather than asking the model. This is actionable when/why guidance, not a generic hint.

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