Screen many items, reading files server-side

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

The description discloses multiple behaviors beyond the annotations: files are read server-side so contents never enter context, each item is an independent request with failures reported in place, and nothing is truncated (oversized files fail rather than being cut). These add significant value beyond the readOnlyHint and idempotentHint annotations, giving the agent a clear picture of failure modes and data handling.

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 a single, dense paragraph that front-loads the core purpose and key differentiators. Every sentence earns its place: it covers the batch nature, file reading, use case, query vs questions, failure isolation, and truncation policy without fluff. It is concise yet complete, ideal for an agent scanning for the essentials.

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 complexity (7 parameters, nested question structure) and the presence of an output schema and comprehensive annotations, the description covers all critical operational aspects: the batch workflow, server-side file reading, independent failure handling, and the no-truncation guarantee. An agent can confidently invoke it for triage without needing additional clarification.

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 parameters are fully documented in the schema. The description adds semantic meaning by explaining the conceptual difference between 'query' (single relevance check) and 'questions' (typed judgments), the file-path mechanism for avoiding context pollution, and the per-item independence. This goes beyond mere parameter listings, enriching the agent's understanding of how to compose calls.

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's purpose: 'Ask the same question set about many items in one call and get one result per item, in input order.' It specifies the verb (Ask), resource (many items), and the key differentiator (batch processing with server-side file reading). This distinguishes it from single-item siblings like jev_ask or jev_classify, which handle one item at a time.

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 provides explicit guidance on when to use: 'Use it to decide which of many files, documents, or candidates deserve a closer look before opening any.' This clearly indicates the batch triage scenario. However, it does not name specific alternatives or state when not to use it (e.g., when you have few items), so it lacks explicit exclusions. Still, the use case is clear enough for an agent to decide.

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