Check whether the citations in a draft actually verify

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds critical behavioral nuance: 'ADVISORY: nothing is blocked, and a citation this responder does not hold is never a denial, because it is indistinguishable from one minted elsewhere.' It also reveals that 'a check that read nothing still answers allow,' and details the deny codes and fixes. This goes well beyond the structured 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?

The description is long but tightly organized: it leads with the core function, then details return codes, advisory behavior, usage guidance, and an example. Every section adds value, though some redundancy exists with the schema (e.g., shape descriptions). It earns a 4 rather than 5 because it is somewhat verbose for a tool that the schema already documents well.

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—5 parameters, an output schema, and a rich annotation set—the description is remarkably complete. It covers the full workflow, including when to use it, how to handle non-native payloads, what the codes mean, and how to move from consultation to enforcement. It even provides a concrete example argument. No critical context 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?

With 100% schema coverage, the baseline is 3, but the description multiplies meaning: it explains the `shape` parameter's real-world consequence ('a CloudEvent whose citation sits at data.text is invisible to the native reader'), describes `claim_gating` as 'reports on the absence of a citation rather than on a failed check,' and clarifies that unrecognised shapes 'fall back to native rather than erroring.' These are insights not present in 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 opens with a specific action: 'Run emem-guard's policy pipeline over text you are about to send, against this responder's corpus.' It clearly identifies the resource (emem: citations in draft text) and the output (allow/deny with machine-readable reason), and distinguishes this from sibling tools like emem_recall or emem_ask by focusing on verification rather than retrieval or generation.

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?

An explicit 'When to use' section states precisely when to invoke this tool: 'Call it on your own draft before you assert something, or on a tool result before you reason on it.' It also gives an alternative: 'To ENFORCE this rather than consult it, run your own node: emem_guard_selfhost returns the procedure,' and explains how to handle foreign payload shapes. This is model guidance with clear exclusions.

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