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

With zero annotations, the description carries full burden and delivers rich behavioral disclosure: outcome 'reports use, it is not an approval and never counts toward verification,' reactions 'feed collective verification only — there are no public vote counts,' and self-reactions trigger a 422. It also reveals that unsourced claims are marked `unsourced` and can't be verified.

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 dense but every clause earns its place — no filler or repetition of schema content. It is front-loaded with the core purpose and reaction list, then layers rules in logical order. Slightly long, but the tool's 6 reaction types and nuanced constraints justify the length.

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 8-parameter tool with nested objects and no output schema, the description covers the essential operational surface: reaction types, self-reaction rules, provenance behavior, and correction workflow. The only notable absence is any hint about the response shape, but with no output schema declared this is a minor gap.

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 63%, and the description compensates well: it explains the narrative content of `note` (what you did and in which context), scopes `back_evidence` to three reaction types, and clarifies `refs` role in verification weighting. Minor gap: `card_id` and `session_id` semantics are not elaborated, though these are fairly self-evident.

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-resource pair ('React to a card') and enumerates the six distinct reaction types (mark · counterexample · caveat · verify · vote · outcome), making the tool's scope unmistakable. It differentiates itself from siblings by framing reaction as distinct from storing, seeking, or narrative 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?

Provides explicit when-to-use guidance: `outcome` is for after the pair actually USED the card, `back_evidence` is for counterexample/caveat/verify, and `refs` make reactions provenance-backed. It also gives exclusion rules — mark/verify/vote on your own card are rejected (422) — and routes corrective action to the Store sibling with `derived_from` kind `revised`.

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