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

Annotations already declare readOnly/idempotent/destructive=false, so credit is for going beyond them, which this does: it discloses the availability gate ('Disabled while the protection ladder is raised (tool_disabled, reason ladder_L1)'), auth requirements ('linked'), and the credit/ambiguity/untrusted_text handling obligations. Those are operational facts an agent cannot derive from the structured fields.

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?

Tight, front-loaded, and label-structured (Use / Inputs / Returns / Disabled / Credit / Auth) with no filler sentences. It loses a point because several fragments ('Credit attribution.line', 'if ambiguity.state is not none, ask first') are dense shorthand that is not self-explanatory to an uninitiated agent.

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 4-optional-parameter read tool with no output schema, the description supplies the return shapes (`data.surfaces[]` with name/grain/served/form|reason; `data.rows[]`), pagination source, the disabled state, and auth — enough to call it correctly. Remaining gaps are the undefined 'protection ladder' and 'ambiguity.state' mechanics, which leave the disabled and disambiguation paths somewhat opaque.

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?

With 100% schema coverage the baseline is 3, and the description earns one more by explaining the mode coupling ('no arguments → the registry listing; `name` + `cluster` (64-hex) → rows') and by noting returned `*_cluster_id_hex` values are get_artist keys, which crosses into sibling-tool semantics. The 'limit'/'cursor' mentions add no detail beyond the already-documented schema.

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 the resource and both modes concretely: 'hosaka's cluster-keyed surface registry ... and one surface's rows for one cluster', and the gloss '(signal tables behind the facets)' plus 'Returns: data.surfaces[] ... or data.rows[]' makes the verb (read) and returned entities identifiable. It loses a point because 'surface', 'facets' and 'grain/served/form' are domain jargon an agent cannot ground, and it never contrasts itself with any sibling (though none of the listed siblings overlap).

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 'Use:' line gives concrete contexts ('row-level detail behind a facet; which surfaces exist'), and the Inputs line maps call shapes to outcomes (no arguments → registry listing; name + cluster → rows), which is the key selection decision. It does not name alternatives or when-not-to-call, but no sibling in the list performs this function, so no exclusion is needed.

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