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

Annotations declare readOnlyHint and idempotentHint, and the description adds important behavioral context beyond that: exact matches vs. name-only possible matches, the distinction between staleness and no_match, and the caveat that 'No match is not clearance.' This is high-value, non-obvious disclosure.

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 compact set of five sentences, all front-loaded with the core action and followed by precise usage constraints. Every sentence provides actionable information with zero fluff.

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 batch-checking tool with an output schema and full schema coverage, the description supplies critical behavioral nuances (possible vs. exact matches, staleness handling, no-match-not-clearance) that an agent needs to interpret results correctly. Nothing essential 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%, with each parameter described in the schema, so the baseline is 3. The description mentions the array-of-objects shape and required identity attributes, but adds no syntax or format detail beyond what the schema already 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 states a specific verb ('Check') and resource ('1 to 20 identities against a dated active SAM snapshot'), and the semantics are distinct from sibling tools like search_exclusions and explain_match. It clearly defines the batch-checking action and the scoped snapshot.

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 usage context ('Pass identities as an array of objects, not a record ID or page URL') and specifies the required identity attributes, but it does not explicitly name alternative sibling tools (e.g., search_exclusions or explain_match) or state when to use this tool over them.

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