Verify a registry name or digest

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

Annotations already declare readOnlyHint=true, so the read-only safety profile is covered by structured data. The description adds one behavioral detail — the registry is 'hashed' — implying matches are validated against stored hashes. However, it does not disclose the output shape, whether matching is exact/fuzzy, or what happens on a failed match. With annotations present, the bar is lower, and the description provides marginal but real added context; 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?

A single 15-word sentence with the verb front-loaded and zero filler. The 'hashed FragGate registry' qualifier earns its place by scoping the verification target. Nothing in the description is redundant with the title or annotations.

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 tool with three undocumented optional parameters, no output schema, and several closely related siblings, the description is too thin. An agent lacks: the return shape, the meaning of 'slug', how parameters combine, and when this tool is preferable to fraggate_describe. The readOnly annotation covers safety but not the operational semantics an agent needs to invoke this correctly.

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 0%, so the description must compensate fully. It does clarify that 'name' and 'digest' are identifier types being checked against the registry, but it never mentions the 'slug' parameter at all, and it gives no hint about how the three optional parameters relate (alternatives? AND? priority?). additionalProperties: true further widens the ambiguity. The description covers two of three params without relational semantics, which is insufficient at 0% schema coverage.

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 a specific verb ('confirm') with a defined resource ('a name or digest against the hashed FragGate registry'), so an agent can tell this performs an existence/authenticity check rather than enumeration or inspection. It is not tautological and adds the meaningful 'hashed' qualifier. It loses one point because it never states what a verification returns (boolean vs. details) and doesn't explicitly distinguish itself from fraggate_describe.

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?

No guidance whatsoever about when to use this tool versus fraggate_list, fraggate_describe, or fraggate_call. The description neither states a triggering condition nor names alternatives. Given a sibling set full of registry tools, the agent is left to guess whether verification is for CI checks, pre-call validation, or ad-hoc lookups.

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