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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add one useful trait — 'No identifiers are retained' — which signals a privacy guarantee. However, it says nothing about the actual classification behavior: what categories it can return, whether it makes network calls (several params look like URLs and feeds), how results are formatted, or whether the tool is read-only. The single privacy note is too thin to be transparent.

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?

Two short sentences with no filler: the purpose is front-loaded first, and the privacy disclosure second. Every word earns its place, and the structure is tight. It is appropriately sized for what it communicates, even though what it communicates is thin.

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 9-parameter tool with no output schema and no annotations, this description is far too sparse. It fails to explain what classifications exist, what the return value looks like, how the many parameters map to classification outcomes, or how an agent should interpret the result. The privacy note and vague purpose leave major gaps that an agent would need to resolve by trial and error.

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%, so all 9 parameters are individually documented in the schema (e.g., 'discarded after the shape check,' 'no disk access'). The description itself adds nothing about parameters, but per the rubric the baseline is 3 when the schema already covers them. The schema's per-parameter notes actually carry more semantic weight than the tool description.

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 the verb 'Show' with the object 'how this request is classified,' but it never defines what classification means or which classifications exist. With 9 heterogeneous parameters (url, city, json, path, query, etc.) and 27 shape-checking siblings, an agent cannot tell what this tool outputs or how it differs from domain-shape or jira-key-shape. The purpose is vague rather than a tautology, which is why it earns a 2 rather than a 1.

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?

There is zero guidance on when to invoke this tool versus the 27 siblings. Many siblings (domain-shape, figma-url-shape, github-repo-shape, jira-key-shape) appear to perform similar classification or shape-checking roles, yet the description provides no when/when-not conditions, no named alternatives, and no context on which input type the tool is meant for. An agent is left to guess.

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