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

Annotations only declare the safety profile (not read-only, not destructive, not idempotent, closed-world); the description adds substantial behavioral context beyond that: it never publishes, it may return a request for an identifier, it can return a not_covered outcome, and results carry citations, a disclaimer, and status labels. The heavy response-handling rules (add no facts, keep citations, phrase as product type not personal duties) go well past what the annotations convey.

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 purpose and the draft-only constraint are correctly front-loaded, but the body is a long run of imperative house-style rules ('never call this advice or yourself a consultant', 'never rank or recommend vendors') that read like system-prompt policy rather than tool selection guidance. Useful in aggregate, but several sentences do not earn a place in a tool description.

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?

There is no output schema, yet the description covers the important return expectations: possible identifier requests, citations and disclaimer that must be preserved, status labels, and the not_covered case. Missing only smaller operational details such as what happens on repeated calls (the tool is non-idempotent) or validation failure behavior, so it is close to but not fully complete.

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 100%, with per-parameter guidance including the category enum mapping rules and the battery subType caveat, so the schema already carries the semantics. The description only adds a generic anti-fabrication constraint for identifiers ('ask the user; never invent one'), which reinforces gtin/serialNumber handling but provides no syntax or format detail beyond the schema. Baseline 3 applies.

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+resource+scope: creates a *draft* passport in the user's own TracePass account, sourced from facts the user stated. The draft-only/never-publishes boundary is stated immediately, which cleanly separates it from the profile/registry siblings and prevents an agent from expecting a publish-capable tool.

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?

Explicit triggering condition ('use it whenever the user asks to create a passport'), an explicit handling of the ambiguous case ('create and publish' → create draft, tell the user publishing happens in TracePass, it never publishes), and a fallback path for when no template exists ('if the result is not_covered, say so and point to the article'). Very little is left to inference.

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