Provider endpoints

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

With no annotations present, the description carries the full behavioral burden and does meaningfully cover it: it discloses the default result set when no arguments are given, that a cache exists and ``refresh`` bypasses it, that lower-is-better sort keys order ascending, and the default row count. It omits auth requirements, rate limits, and any failure behavior, so it is strong but not exhaustive for an unannotated tool.

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 mode-selection rule is front-loaded in the first paragraph before the Args list, so the most decision-relevant information comes first. The parameter block is long but each line adds distinct semantics rather than restating the schema, so little is wasted; a tighter single paragraph could have trimmed a few lines.

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 must convey the return shape, and it does name the key outputs ($/task, precision, the 1,200-row provider board). Combined with the mode rules and full parameter documentation, an agent has enough to call it correctly, though a note on result shape for the board mode (columns, pagination) would close the remaining gap.

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 0%, yet all eight parameters are explained in the Args block with genuine meaning beyond the schema: ``sort`` enumerates six keys plus the lower-is-better ascending rule, ``fields`` lists the extra columns it unlocks (cache_read, discount, e2e, etc.), ``host`` gives an example substring, and ``min_context``/``open_weights`` state their filtering semantics. This fully compensates for the empty schema descriptions.

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 opening line states the resource and the data it exposes (per-host pricing, precision, speed, feature flags), and the body distinguishes three operating modes: per-model endpoints, the host/filtered provider board, and the global cheapest-endpoint fallback. It never references the sibling tools (aa_model, aa_leaderboard) that an agent might confuse it with, so it falls short of a 5.

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?

Explicit routing logic inside the tool: pass ``model`` for one model's serving endpoints, ``host``/filters for the provider board, and 'with neither, returns the cheapest endpoints globally.' That resolves the main ambiguity about how to invoke it. It gives no guidance on when to prefer this over siblings like aa_model or aa_leaderboard, which keeps it from a 5.

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