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

Goes well beyond the annotations (openWorld/non-idempotent/destructive) by disclosing the actual cost model: paid capabilities debit the wallet, free capabilities have a monthly per-IP allowance, and the return object includes latency, price charged, and data provenance. It also points at the max_price_cents guard, which explains why an execution can fail rather than overspend.

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?

Front-loads what the tool does, then prerequisites, then return shape, then pricing. Every sentence carries information, though the parenthetical endpoint reference (GET /v1/platform/facts) is a bit dense for a tool description.

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?

With no output schema, the description supplies the return shape (capability output, latency, price charged, provenance). For a meta-tool with a dynamic nested input object, it covers discovery, execution, cost, and failure conditions adequately.

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 coverage is already 100%, so the baseline is 3; the description adds real value by explaining that 'inputs' is a dynamic payload governed by the target capability's own schema, which strale_search reports. It doesn't explain the default/behavior of max_price_cents beyond what the schema says, so it stops short of a 5.

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?

States a specific verb and resource ('Executes a Strale capability by slug and returns the result') and enumerates the capability classes it covers (verification, validation, lookup, data extraction). This clearly separates it from strale_search, which only lists capabilities.

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?

Gives explicit prerequisites and sequencing: 'Call strale_search first to find the right slug and required input fields' and 'check strale_balance first for high-value calls.' It also tells the agent the free-tier path exists, so an agent can choose a no-cost capability before spending.

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