hu_coverage

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

Annotations already declare openWorldHint and readOnlyHint, but the description meaningfully expands on them by explaining that an empty search result might reflect a connector gap rather than an absence in the law. It also discloses that every gap includes a fallback and that the result has an as-of note, adding value beyond the structured annotations.

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 compact and well-organized: it front-loads the tool's purpose, follows with precise usage triggers, and ends with the return shape. Every sentence earns its place with no filler.

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 parameterless, read-only coverage tool with a documented output schema, the description provides the necessary operational context: when to call it, what to expect from it, and how to interpret empty results. It is complete for an agent to invoke 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?

The tool has zero parameters, so the baseline is satisfied; there is no input schema to elaborate on. The description focuses on return contents instead, which is appropriate for a parameterless metadata tool.

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 clearly states the tool's purpose: declaring what the connector covers, how it is sourced, and what it does not cover. It is distinct from sibling content-retrieval tools like hu_get_act or hu_list_doc_types, so an agent can select it appropriately.

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 gives explicit trigger conditions: call before telling the user the law 'does not contain' something, and whenever a search comes back empty. It does not explicitly contrast against sibling tools or state when not to use it, but it provides strong, clear context for when it is needed.

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