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

Beyond the annotations, the description discloses that 'answers.result.noul is the probability of yes from 0 to 1, not a guaranteed truth or enforcement decision,' that the call sends input to Jev AI and consumes account credits, that rate limits apply, and that there are no automatic retries. This gives an agent realistic expectations about side effects and reliability.

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?

Every sentence earns its place: the core function, the probabilistic-result caveat, the sibling routing, the auth/cost/rate-limit warning, and the return/no-retry note. The most critical information is front-loaded.

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 an external, cost-incurring API call with no output schema, the description covers required auth (JEV_AI_API_KEY), side effects (credits, rate limits), retry behavior, and key return fields (model, answers, usage). An agent has enough to invoke it correctly and interpret the response.

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%, so the schema already documents 'state' and 'instructions' thoroughly. The description adds a yes/no framing and an output caveat, but it does not contribute new input-parameter semantics beyond what the schema provides.

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 opens with a specific verb and resource: 'Evaluate a yes/no condition.' It also differentiates itself from a sibling by telling the agent to 'Use jev_decide for multiple questions,' so the agent can pick the correct tool without inspecting every 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?

There is explicit routing: 'Use jev_decide for multiple questions' establishes the single-question scope and gives a concrete alternative. However, it does not explicitly contrast with the other sibling tools like jev_classify, jev_score, or jev_gate, so the when-not-to-use guidance is present but not exhaustive.

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

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

Beyond the annotations (which only signal non-read-only, open world, non-idempotent, non-destructive), the description discloses external data sent to Jev AI, account credit consumption, rate limits, and no automatic retries. This is exactly the behavioral context an agent needs and does not contradict any annotation.

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 short, front-loaded with the core behavior, and every sentence adds necessary information: purpose, output, alternative, authentication, side effects, and retry behavior. No filler or redundant material.

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 an externally calling tool with no output schema, the description covers purpose, return shape, authentication, cost, rate limits, and retry behavior. An agent has enough information to select and invoke the tool 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%, so the parameters are already documented. The description adds some context by saying input is sent to Jev AI, but it does not add detailed parameter semantics beyond the schema; baseline 3 is appropriate.

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 states a specific verb and resource: 'Choose one labelled option for routing, categorization or intent detection', which is much more informative than the title. It also clarifies the output (choice, confidence, probabilities) and distinguishes from jev_score for ordered levels.

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?

It gives explicit routing guidance: use jev_score when ordered levels are needed, implying this tool is for categorical choices. It also provides operational prerequisites and constraints: requires JEV_AI_API_KEY, consumes credits, rate limits, and no automatic retries.

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

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

The description goes well beyond the annotations by disclosing that input is sent to Jev AI, that account credits are consumed, that rate limits apply, and that there are no automatic retries. This is critical behavioral context for an agent deciding cost, side effects, and error-handling expectations.

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 compact and front-loads the core purpose, followed by behavioral and operational notes. Minor redundancy exists between "Returns answers keyed by your question names" and the later "Returns model, answers and usage," but overall every sentence contributes practical information.

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?

With no output schema, the description carries the full burden of explaining return values, and it does so by noting answers are keyed by question names and that model, answers, and usage are returned. It also covers authentication, rate limits, cost, and retry behavior, making the tool safely invocable without missing critical context.

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 schema already documents the parameters. The description adds useful semantic gloss by explaining that noul means yes/no, choice means a label map, and score means ordered levels, and by noting that answers will be keyed by question names. This adds meaning beyond raw schema constraints.

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 states a specific operation: evaluate 1–64 named questions in one API request. It further disambiguates the three question types and explicitly says it returns answers keyed by question names, which clearly separates it from the sibling tools focused on single decisions.

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 gives clear guidance: "Prefer this for several decisions on the same input," which signals when to choose this over sibling tools. It also states the API key prerequisite. It does not explicitly name alternative tools for single-question cases, so it stops short of full when-not guidance.

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

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

The description goes well beyond the annotations by disclosing that the tool sends input to Jev AI, consumes account credits, is subject to rate limits, and performs no automatic retries. It also clarifies that it does not execute or enforce actions, which is consistent with the destructiveHint=false annotation. This is exactly the kind of side-effect disclosure the annotations do not capture.

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, each adding substantive value: purpose, outputs, non-execution and policy responsibility, authentication and side effects, and return fields. It is slightly longer than strictly necessary but front-loads the core purpose and remains efficient.

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 tool that calls an external API, consumes credits, has rate limits, and returns structured data without an output schema, the description covers all essential aspects: what it does, what it returns (recommendation, risk, model, answers, usage), side effects, and the lack of retries. The agent has enough information to call it correctly and set expectations.

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?

The input schema already provides 100% coverage of both parameters ('action' and 'context'), each with clear descriptions. The tool description does not add additional meaning to the parameters themselves beyond what the schema states, so the baseline of 3 is appropriate.

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 states a specific action ('Assess an action before execution') and clearly distinguishes itself by naming its outputs ('allow/confirm/block classification' and 'risk score') and its non-execution nature. It is immediately apparent how this differs from the sibling tools, which likely perform related but distinct operations.

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 clear context: use it to assess an action before execution, and it explicitly says it does not enforce actions, so the agent must retain its own permission policy. However, it does not explicitly mention when NOT to use it or name alternative sibling tools, leaving some inference to the agent.

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

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

Discloses key behaviors beyond annotations: does not change the judge, sends input to Jev AI, consumes account credits, rate limits apply, returns model/answers/usage, and has no automatic retries. It even explains the HTTP 409 revision conflict behavior. No contradiction with the annotations.

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?

Front-loaded with the core purpose, and every sentence carries distinct information: purpose, non-mutation, revision semantics, sibling routing, auth, side effects, rate limits, return value, and retry policy. Dense but not padded.

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 tool with no output schema and 3 parameters, this description is complete: it covers auth requirements, side effects, return values, conflict behavior, retry policy, and a sibling alternative. Nothing essential for invoking 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 description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema, particularly for the revision parameter, explaining it detects changed rules with HTTP 409, and clarifying that state is sent to Jev AI model providers. This elevates the score.

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?

States a specific action: 'Evaluate new input with a judge saved in your Jev AI account.' It also explicitly names the sibling alternative (jev_decide) for inline rules, making the tool's role clear. The title and body are consistent.

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 clear when-to-use context: when using a saved judge, and directs inline-rule use cases to jev_decide. It also covers prerequisite setup (JEV_AI_API_KEY), revision behavior, and operational constraints like rate limits and credit consumption.

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

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

Discloses external service usage (Jev AI), API key requirement, credit consumption, rate limits, and no retries. It also notes the output location (answers.result). This goes well beyond the sparse annotations (readOnlyHint false, etc.) and gives the agent important operational context.

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?

Four sentences, no redundant words. Core purpose is first, then alternative, then requirements and side effects. Every sentence adds new information; no filler.

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 tool with 3 required params and no output schema, the description provides enough: what it returns (score, legend, probabilities, model, usage), prerequisites (API key), and side effects (credits, rate limits, no retries). An agent can safely invoke it without further documentation.

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 covers all parameters at 100%, so baseline is 3. The description adds meaningful details: levels are ordered and zero-based, score is fractional, and state is sent to Jev AI. These clarify how the parameters relate to the tool's behavior beyond the schema.

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 the tool rates input on an ordered 2–20 level scale, which is specific and distinguishes it from the yes/no tool (jev_check). It also gives the return format, so an agent knows exactly what to expect.

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?

It explicitly directs to use jev_check for yes/no, providing one clear alternative. It does not compare against jev_classify, jev_gate, jev_decide, jev_saved_judge, but the purpose (rating on a scale) implicitly differentiates it. Overall it gives clear context but not exhaustive exclusions.

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