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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: the deliberate statement of what the tool does NOT cover is exactly the kind of negative-scope disclosure that prevents an agent from assuming domain coverage, and "Free, needs no input" sets cost/latency expectations.

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?

One sentence plus a short trailing clause, front-loaded with the core action and then the scope detail. Every element earns its place: the enumerated coverage areas help matching, and the exclusion clause and cost note add information rather than restating the title.

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 zero-parameter discovery tool with no output schema, the description tells the agent what will come back (tool list, coverage domains, exclusions) and that it costs nothing to call. The only mild gap is that the shape of the response — prose versus structured capability list — is not hinted at, which matters slightly for a tool whose whole value is its output.

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 zero parameters the baseline is 4, and the description reinforces this by stating "needs no input," removing any doubt about whether arguments are required. There is nothing further to document, so no credit or penalty beyond the baseline 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?

The description uses a specific verb ("Lists") against a specific resource (Flow Pack's tools), then enumerates the coverage domains — nations, pipe materials, gases, record types, emergency situations — plus explicit scope exclusions. This makes it immediately distinguishable from the domain siblings (check_gas_record, size_pipe, emergency_triage), which all perform work rather than catalog capability.

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?

"Free, needs no input" implicitly lowers the cost of calling it, which nudges toward using it for orientation, and the "what it deliberately does not do" clause signals its role as a scope check. However, it never states when to prefer it — e.g. "call this first if you are unsure which sizing tool applies" — nor names any alternative. Usage is implied rather than directed.

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