search_terms_batch

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely new behavioral detail: it returns per-query totals plus A-numbers with match positions, and generic queries fail with an error rather than returning empty hits. That failure mode is the kind of thing that would otherwise trip up an agent. It doesn't mention batching limits or cost, which keeps it from a 5.

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?

Three tight sentences with the core action front-loaded and the return/error behavior following in priority order. The inline `limit` reference is efficient rather than redundant. Minor waste in the parenthetical about sub=False, but it earns its place by anchoring semantics.

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?

An output schema exists, so the description's return-value prose is bonus rather than necessity, and it covers the essential contract (counts, A-numbers, positions, error-on-generic). The gap is `ext`, an entirely unexplained parameter in a tool whose schema documents nothing; for a 3-parameter tool with 0% coverage that omission matters.

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 0%, so the description must carry the load: it explains `queries` (comma-separated term strings) and references `limit` ('up to `limit` of their A-numbers'). However `ext` (boolean, default false) is never mentioned, and 'list of comma-separated term strings' is slightly ambiguous against the schema's array-of-strings type. Useful but partial compensation.

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 verb and resource ('Run many exact term searches at once') and pins down its relationship to the sibling search_terms, including the sub=False variant it corresponds to. An agent can distinguish it from search_terms and search_text 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?

The 'many at once' framing plus the reference to search_terms gives clear context for when this batched form is the right pick. It stops short of an explicit exclusion (e.g. 'use search_terms for a single query' or a threshold on batch size), so it's clear but not fully prescriptive.

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