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

With no annotations, the description carries the burden itself and largely does: it implies a safe read (GET /v1/pools/networks), declares the enumerable result categories, and proactively discloses policy-driven states ('Moonbeam ... closed by policy; every other chain as not supported yet'), which is behavior an agent cannot infer elsewhere. It omits auth requirements, caching/rate limits, and pagination, but adds genuine context beyond 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?

Three sentences, front-loaded with the endpoint and purpose, then the result contents, then the policy edge cases, then the next-step handoff. No sentence is redundant and nothing is buried.

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?

There is no output schema, so the description has to describe the return: it names factory, hook, pool assets and live status, plus the closed/not-supported policy states. Combined with the explicit downstream tool, an agent has everything needed to call it and act on the result.

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 takes zero parameters, which is the baseline-4 case; there is nothing for the schema to document and nothing the description could add. The description correctly spends no words on parameters.

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 names a specific verb+resource ('where a coverage pool can be opened') and pins the concrete response shape (every supported chain and line, with factory, hook, pool assets and live status), going so far as to cite the underlying endpoint GET /v1/pools/networks. It is clearly separable from sibling pool tools (pool_quote, pool_status, pool_open_plan) because it is framed as the inventory entry point.

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?

It gives an explicit ordering directive ('Start here, then taifoon_pool_open_plan'), which is exactly the routing an agent needs for a discovery tool. It stops short of naming the alternatives to avoid (e.g. when to skip this and call taifoon_pool_status or taifoon_pool_quote), so it is clear context rather than a full when/when-not matrix.

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