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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe, idempotent read operation. The description adds value by disclosing the history-start constraint ('history starts at the first ingestion run'), which is behavioral context beyond the annotations. It does not describe pagination behavior (limit up to 100) or potential latency, but with strong annotation coverage, a 3 is appropriate.

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 concise at two sentences plus an example. The first sentence states purpose and scope, the second lists filters, and the example provides a concrete usage case. No word is wasted, and the structure is front-loaded with the core action.

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 has 5 parameters (1 required), 2 enums, no output schema, and annotations that cover safety, the description is reasonably complete. It explains the result type (certifications with changes), the temporal scope, and available filters. The lack of output schema is mitigated by the description indirectly hinting at the result structure. A minor gap is not explaining that 'limit' caps results and its default, but overall sufficient for a list tool.

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 description coverage is only 20% (only the 'since' parameter has a brief description), so the description must compensate. The description lists filterable parameters (change type, register, NSF code) but does not explain their format, constraints (e.g., 'nsf' maxLength 4, enum values for type and repertoire), or default behavior (limit default 50). The example uses a natural language query that maps to parameters, adding some value, but the description does not fully cover the schema gaps.

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 uses specific verbs (created, updated, deactivated, reactivated, removed) tied to a clear resource (certifications) and a temporal scope (since a date). It distinguishes itself from sibling tools like search_certifications (list vs search) and get_certification (single vs list). The mention of history start and filters for change type, register, or NSF code adds precision.

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 states when to use the tool (querying certifications that changed since a date) and provides concrete filter options (change type, register, NSF code). However, it does not explicitly say when NOT to use it versus siblings like check_habilitation or compare_certifications, nor does it mention prerequisites or alternatives. The example query helps but lacks exclusions.

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