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

Beyond the annotations' safety profile, the description discloses billing behavior (per-tier pricing, per-element billing for multi-target arrays, rows_per_unit), failure semantics ("failed calls and empty results leave no final charge ... anything reserved is restored"), and pagination mechanics (next_page_token/page_token, repeated tokens on rows, page_size_varies). This is substantial behavioral context an agent cannot derive from 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?

The core purpose and pricing lead the paragraph, so it is front-loaded, and for a paid meta-dispatch tool most clauses (billing, pagination, async) earn their place. It is nonetheless a single dense run-on passage where pagination and billing clauses compete for attention, which slightly hurts scannability.

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 carries the return-value burden, and it does explain the async job_id path and next_page_token pagination, plus the discovery prerequisite. It does not describe the general shape of the structured JSON response or error behavior, so it is nearly complete but leaves some gaps for a tool with nested params.

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 100%, so the baseline is 3, but the description adds real meaning: it explains mode=async's return (job_id), and contextualizes params such as limit, billing-relevant multi-target arrays, and page_token sourcing from next_page_token. However, the schema properties themselves are only lightly annotated, so some param meaning still relies on the catalog lookup it recommends.

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 states a concrete verb+resource ("Call any EveryInfra data capability and get structured JSON") and implicitly distinguishes itself from the discovery and async-read siblings by routing to everyinfra_list_capabilities and everyinfra_get_job. The opening sentence partly echoes the title ("Call a data capability"), so it is clear but not maximally differentiated on its own terms.

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 prerequisite ("Check platform/action, required params and max_limit or page_size with everyinfra_list_capabilities first") and an explicit alternative path ("for slow tasks or large limits pass mode=async ... read the result with everyinfra_get_job"). The sync-vs-async condition is stated outright, leaving nothing to inference.

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