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

With no annotations provided, the description carries the full behavioral burden. It discloses a key semantic nuance: rates are measurements of the past week, not forecasts, and clarifies that 'keep' is fees retained after arbitrage and that a tenth of swap fees from own pools pays the LoomDesk book. It does not describe pagination or output format, but those are less critical given the rich return-field explanation.

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 dense sentences, each earning its place: the first defines scope and fields, the second explains the own-pool distinction, and the third disambiguates measurements from forecasts. No filler or repetition of the schema.

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 list endpoint with four optional parameters and no output schema, the description covers the returned fields, ownership semantics, and a critical temporal caveat. It is missing explicit guidance on sort behavior and response shape, but the schema already documents defaults and constraints for the parameters.

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 only 50%, so the description must compensate. It adds meaning to sort values like weekly_at_10 via the ±5/10/15/25% range mention, and to own_only by explaining what 'own' means for Earn positions. However, it does not directly clarify the sort parameter's options or limit, leaving some of the gap unfilled.

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 ('List') and resource ('Tokenized stock pools on Robinhood Chain'), then enumerates the exact output fields: weekly rate, keep, depth, and 24h flow. It also distinguishes LoomDesk's own pools from all pools, so an agent can tell it apart from siblings like get_pool or quote_position.

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 provides useful context—own pools are the ones Earn opens positions in—which implies when this tool matters for LoomDesk. However, it never explicitly says when to use list_pools versus get_pool, book_status, or quote_position, and it offers no exclusions.

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