EveryInfra

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

Annotations already establish read-only, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real context beyond that: the call is free, bonus credit expiry is reported separately from paid, the per-minute limit spans all keys combined and may include a rate package with an end date. It also cross-references balance_after_usd on paid-call billing, which is genuinely useful operational context.

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 statement is front-loaded ('The account behind this API key'), which is good, but the body is a single run-on sentence with deeply nested parentheticals enumerating field after field. It is dense rather than wasteful, yet a bulleted layout of the returned fields would parse far more easily for an agent scanning for a specific datum.

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 and no parameters, so the description carries the full burden of explaining what comes back — and it does so exhaustively, covering every returned field group including expiry semantics and tier distance. An agent knows exactly what it will get and needs no further inference.

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 and the schema is an empty object, so per the rubric the baseline is 4. There is nothing parameter-wise the description could add, and it correctly avoids inventing any input options.

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 resource (the account behind the API key) and enumerates exactly what it returns: wallet balance, top-up discount, per-minute limit, key name/creation time, and 24-hour calls and spend. It is clearly distinct from a generic usage endpoint. However, it never names or contrasts with the near-neighbours everyinfra_usage and everyinfra_billing, so sibling differentiation is left implicit.

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 concrete guidance with 'Check the balance before a batch of paid calls', which tells the agent when this tool is worth calling. It also flags that the tool is free, removing cost hesitation. It stops short of saying when to prefer everyinfra_usage or everyinfra_billing instead, so no exclusions are stated.

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

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

Annotations already declare readOnly/closed-world/non-destructive, yet the description adds real behavioral context: the required permission scope, the key-type nuance for enabling it, and the fact that the call is free. That goes beyond the annotation set, though it says nothing about rate limits or freshness of the spend figures.

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 the returned data before the permission caveat, which is the right ordering. The permission sentence is long but carries needed auth detail; overall it is tight for the amount of information conveyed.

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 takes on the burden of describing the return shape and does so thoroughly (totals, per-platform split, call-status counts, discount, wallet entries). Combined with the auth prerequisite, an agent has enough to call it correctly; only sibling disambiguation is missing.

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% and both params are self-documented with defaults and bounds. The description only echoes them implicitly ('last N days', 'recent wallet entries') without adding format or interpretation beyond the schema, so baseline 3 applies.

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 resource (spend/billing) and enumerates exactly what is returned: total USD, per-platform breakdown, charged/free/failed counts, discount, and wallet ledger entries. It is clear what the tool does, though it never explicitly distinguishes itself from the closely related sibling everyinfra_usage.

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 supplies the precondition for use (the account must hold 'billing:read', with detail on default vs product-line-limited keys) and notes the call is Free. However, it gives no guidance on when to pick this over everyinfra_usage or everyinfra_requests, so the choice between spend-reporting siblings is left to inference.

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

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.

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

With annotations only covering safety hints, the description carries the operational burden well: exact billing behavior (free for topped-up accounts, nothing deducted), tiered rate limits by cumulative top-up, the ai_topup_required error, and the 45,000-character ceiling with a recovery instruction. This is precisely the beyond-annotation context an agent needs.

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-loaded with the core capability, then limits, billing, and use cases in single-sentence units. Dense but nearly every clause carries operational information — no filler, though the pricing parenthetical is slightly heavy.

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 tool with no output schema, the description covers errors, limits, rate limits, cost, and use cases. The only real gap is an explicit statement of the return shape, though 'OpenAI-compatible' implies the response envelope.

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 baseline is 3; the description adds the message-length constraint (45,000 characters total) and points to GET /api/v1/models for valid model names, which is meaning beyond the schema's inline enum text.

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?

Names the specific capability — OpenAI-compatible text completions with multi-turn history — and enumerates concrete jobs (summaries, translation, sentiment labels, topic classification, structured extraction). No sibling in the list does text generation, so the resource boundary is unmistakable.

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 positive usage context ('Good for cleaning collected data: summaries, translation, sentiment labels...') and failure-driven guidance ('split long documents into several calls' on input_too_large). It does not name an alternative tool or state when NOT to use it, which keeps it short of a 5.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), the description discloses rich behavior: any account key works, nothing is charged, retries are idempotent (same subject/description within 24h returns the same ticket), support hours and first-reply average, where replies appear, and a warning against including secrets or bare long IDs. This is exactly the supplemental context that structured fields alone cannot convey.

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 description is long and densely packed with semicolons, but it is front-loaded with purpose and use cases and every sentence carries usable information (return value, formatting, idempotency, support hours, follow-up tool). A bulleted structure would improve scanability, but nothing is wasted.

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 still explains what comes back ('ticket number and a link'), how to check progress and read replies, the auth model, idempotency guarantees, and operational details like support hours. For a 7-parameter mutation tool with complete schema descriptions and annotations, this leaves no significant gap for correct invocation.

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. The description adds meaningful semantic guidance for the important parameters: one line in subject; what to include in description (platform/action, UTC time, error code and message, expected result); and how to pass request_id and job_id with labeled IDs. It does not discuss category, contact_email, or idempotency_key in prose, keeping it below 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?

The description states a specific verb and resource ('Open a ticket with EveryInfra's human support team') and even describes the return value ('ticket number and a link the account owner can open'). It names the follow-up sibling everyinfra_get_ticket for reading progress, but does not distinguish itself from the near-identical sibling everyinfra_ticket_create, which could leave an agent unsure which create tool to pick.

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 clear when-to-use cases ('when calls keep failing or return wrong or missing data, for top-up, charge or refund questions, or to ask for a new platform, capability or field') and explicitly routes the agent to everyinfra_get_ticket for later reads. There are no explicit when-not conditions, so it stops short of the top score.

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

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

Goes well beyond the readOnlyHint/destructiveHint annotations by disclosing that the call is free and exempt from the per-minute limit, that only same-API-key jobs are visible, and what each terminal/non-terminal status means. It also warns explicitly not to resubmit on submit_unknown and tells the agent to follow next_action.

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 and its cost profile, then packs status-specific guidance into a compact semicolon-separated paragraph. Every clause is actionable and earns its place.

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 full return-shape burden and does so: results rows, next_page_token for paged actions, error.reason, error.charged, and next_action. An agent has enough to call the tool and interpret all meaningful responses.

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 single job_id parameter has 100% schema description coverage, and the description adds only the provenance context that it comes from everyinfra_call_api(mode=async). With the schema already documenting the parameter, the baseline 3 is appropriate.

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 (Read) and resource (a job), and ties it directly to the originating tool by naming everyinfra_call_api(mode=async). This clearly distinguishes it from siblings like everyinfra_call_api, everyinfra_requests, or everyinfra_usage.

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?

Explicitly says when to call based on job status: retry later for submitting/running/finalizing, stop for succeeded, inspect error.reason/charged for failed, and do not resubmit for submit_unknown. This turns the tool into a complete polling protocol rather than leaving the agent to infer behavior.

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

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false), but the description adds substantial behavior beyond them: the auth model (the key that opened a ticket can always read it; other tickets need 'support:read'), the failure mode ('any other number returns ticket_not_found'), the cost ('Free'), and the 100-message return cap. This is exactly the extra context annotations cannot carry.

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-loaded with purpose, then usage, then auth, then error behavior, then cost – a logical progression with little waste. It is dense but every clause (permission model, ticket_not_found, free) earns its place.

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 must describe return values, and it does (status, next steps, latest 100 messages). Combined with auth requirements, error behavior, and cost, an agent has everything needed to call it correctly.

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 100%, so the ticket_id semantics are already documented, giving a baseline of 3. The description adds only a routing note ('the ticket_id that tool returned') and the invalid-ID behavior, which is a small increment over the schema.

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?

'Read one support ticket' is a specific verb+resource, and the description enumerates exactly what comes back (status, what happens next, latest 100 messages including support replies). This cleanly distinguishes it from siblings like everyinfra_create_ticket, everyinfra_ticket_reply, and everyinfra_tickets.

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?

Explicitly says to use it 'after everyinfra_create_ticket to check progress, with the ticket_id that tool returned,' which routes the agent from the creation flow. It does not explicitly contrast with the list-oriented everyinfra_tickets sibling, so it stops short of full when/when-not coverage.

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

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

Annotations only declare readOnly=false, destructive=false, openWorld=false. The description adds substantial undisclosed behavior: the new key can never exceed the caller's capabilities, inherits the same source-IP limit, cannot have a later expiry or higher per-minute limit, is restricted to read scopes, and is capped at 20 keys per account per UTC day. That is exactly the kind of constraint an agent needs before invoking.

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, front-loaded with the action and its single-use return semantics, followed by the inheritance constraints and the permission prerequisite. No filler.

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 correctly discloses that the key is returned once. It covers the permission prerequisite and rate limit, but leaves roughly half the input parameters unexplained for a 7-param mutation tool.

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 low (43%) across 7 parameters, so the description must compensate. It indirectly constrains ip_allow ('same source-IP limit') and expires_at ('no later expiry'), but says nothing about name, note, scope_mode, scope_rules, or account_scopes, leaving several parameters undocumented in both places.

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 ('Create a new API key on this account') and adds the crucial scope note that the key is returned once. Clearly distinguishable from siblings like everyinfra_key_update and everyinfra_key_delete.

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 strong context for when this is usable: it requires the keys:write account scope, which is off by default and grantable only by the owner. It does not explicitly name a sibling alternative, but the preconditions and the 'return it once' caveat effectively route the caller.

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

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

Annotations already flag destructiveHint=true, but the description adds value beyond them: the deletion is permanent, it requires the keys:write account scope, that scope is off by default, and only the account owner can grant it in the console. These are exactly the operational facts an agent needs before attempting a destructive call, and nothing contradicts the annotations.

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, no filler, front-loaded with the destructive action and target before moving to exclusions and the permission prerequisite. Every sentence contributes a distinct fact.

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 two-parameter destructive tool with no output schema, the description covers permanence, exclusions, the confirm gate, and the auth requirement. It stops short of stating success/failure behavior or how to source a valid key_id.

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%, so the description must carry the meaning. It does explain the confirm flag ('Pass confirm: true') and scopes what key_id may reference (an API-created key or the calling key), but it never states the key_id format or where to obtain it, leaving half the parameter semantics implicit.

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 the exact verb and resource ('Permanently delete a key') plus the accepted targets ('created through an API key, or the calling key itself') and the excluded class ('Keys created in the console cannot be deleted this way'). This clearly separates it from sibling key_disable / key_update without requiring schema inspection.

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 a real precondition (pass confirm: true) and an explicit when-not case (console-created keys). It does not, however, route the agent to an alternative such as everyinfra_key_disable for reversible revocation, so the alternative-selection half of the guidance is left to inference.

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

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

Goes well beyond the annotations by disclosing the auth requirement (keys:write scope, off by default, owner-granted only), the re-enable path (console, owner action), and the exact failure behavior for subsequent calls. This is the kind of preconditions an agent cannot infer from destructiveHint=false.

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, each earning its place: what it does, what happens after, and what is required. Front-loaded with the action and consequence before the scope caveat.

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?

Covers purpose, side effect, re-enable path, and the gatekeeping scope. Given one fully documented parameter and no output schema, nothing critical is missing, though a one-line contrast with everyinfra_key_delete would make the definition airtight.

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 100% and the single key_id parameter already documents its source ('From everyinfra_keys'). The description adds no param-level detail, but with full schema coverage the baseline is 3.

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 (disable) and resource (any key on this account), and distinguishes it from siblings like everyinfra_key_delete by noting the effect is temporary until the owner re-enables it. An agent can route correctly between disable/delete/update without opening a schema.

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 a clear use case ('for example one that leaked') and explains the consequence of calling it. It does not explicitly contrast with everyinfra_key_delete or everyinfra_key_update, so an agent choosing between disable and delete still has to infer.

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

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

Beyond the readOnlyHint annotations, it discloses that full keys are never returned (security posture), the exact authorization requirement ('account:read'), the permission nuances for product-line-limited vs unrestricted keys, and that the call is free. That is substantive behavioral context an agent cannot get from the annotations or schema.

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 returned-field list is front-loaded and every clause carries information (fields, security caveat, auth requirement, cost). It is dense and the permission discussion runs long as one sentence, but none of it is filler for a tool whose entire value is in knowing what comes back and what authorization it needs.

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, yet the description compensates by enumerating the returned fields, so an agent knows the shape of the response. Combined with permission requirements and the free-cost note, nothing needed to call this zero-param listing tool correctly is missing.

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, so the baseline is 4 and there is nothing for the description to disambiguate. It correctly implies a full-account, unfiltered listing rather than suggesting any hidden filtering options.

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 opens with a specific verb and resource ('Every API key of the account') and enumerates exactly which fields are returned (name, prefix, status, permissions, rate limit, IP restriction, expiry, last use). This clearly separates it from the mutating siblings everyinfra_key_create, everyinfra_key_delete, everyinfra_key_disable and everyinfra_key_update.

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 explicit when-not guidance: 'Never returns a full key; create, limit or disable keys in the console,' which redirects the agent away from this tool for mutations. The only weakness is that it points to the console rather than naming the sibling key-management tools that exist in this toolset, which could misdirect an agent that has everyinfra_key_create/delete/disable available.

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

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

Annotations only declare a non-destructive, non-open-world write. The description goes further by disclosing a hard authorization gate (keys:write scope, off by default, grantable only by the account owner in the console) and the asymmetric mutation rules (expiry and rpm limit can only be reduced, never raised). It does not describe failure behavior or response shape.

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?

Two sentences, both front-loaded: the capability set first, then scope/preconditions. No filler and nothing restated from the title.

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 5-parameter mutation tool with no output schema, the description covers scope, authorization, and mutation limits well. It is nearly complete, though it says nothing about what the caller gets back or whether partial updates are observable.

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 60% and the schema already documents key_id provenance ('From everyinfra_keys'), the rpm_limit 'can only be lowered' rule, and expires_at's ISO 8601/earlier-only constraint. The description restates those same constraints at a high level but adds no format, default, or validation detail beyond the schema, so the baseline 3 applies.

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?

Opens with a specific verb-plus-field enumeration ('Rename a key, change its note, move its expiry earlier, or lower its per-minute limit'), which instantly distinguishes it from key_create, key_delete, and key_disable.

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 states exactly which keys are in scope (API-created keys and the calling key) and supplies a when-not rule: console-created keys 'can only be disabled', which routes the agent to everyinfra_key_disable. The prerequisite (keys:write account scope, off by default) is also given as a gating condition.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered. The description adds genuinely new context: it's free, it reveals per-call row limits (max_limit vs page_size) and price, and it describes what a platform-scoped call returns. It stops short of describing pagination or output format details, keeping it from a 5.

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?

Dense but front-loaded with the core purpose and the critical pre-call workflow instruction. Every sentence carries information, though the parenthetical platform/action/param enumeration is slightly list-heavy and could be tightened.

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 no-output-schema discovery tool, the description covers what the agent needs: what gets returned (platform/action, required/optional params, row limits, price, allowed values, field meanings), the cost (free), and the correct ordering relative to everyinfra_call_api.

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: passing 'platform' unlocks allowed values, returned fields, and their semantics, and it names example platforms. This tells the agent why to supply the optional parameter, beyond the schema.

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 (List) plus resource (EveryInfra's data platforms and capabilities) with concrete scope (90 platforms / 413 capabilities). It immediately differentiates itself from siblings by naming everyinfra_call_api and everyinfra_chat in context.

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 sequencing instruction: 'Use it before everyinfra_call_api'. It also states a clear exclusion: 'Data collection only — for AI chat use everyinfra_chat.' An agent knows exactly when to pick this over the alternatives.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the result is described structurally (name/params/solution shape) and the cost note "Free" is a useful behavioral signal. It does not cover pagination or rate limits, so it lands at 4 rather than 5.

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 leads are front-loaded (what it lists, when to call it) and the sentence earns its place, but the long parenthetical enumerating solution shapes (token / cookie / text / number / fields / points...) is dense and slightly list-heavy for a 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?

No output schema exists, so the description carries the burden of describing return values, and it does: the three things returned and the taxonomy of solution shapes are spelled out. Nothing an agent needs to call this correctly is missing.

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% with a single optional filter that the schema itself documents with examples (turnstile / recaptcha_v2 / cloudflare_challenge). The description adds no syntax or format detail for the param, so the baseline 3 is correct.

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 ("List the 52 CAPTCHA and bot-challenge types EveryInfra solves"), and explicitly distinguishes itself from the sibling everyinfra_solve_captcha by naming it as the downstream consumer. An agent can tell exactly what this returns.

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 sequencing guidance: "Call it before everyinfra_solve_captcha" and explains the payoff (type name, params, and solution shape). This names the alternative tool and the condition that selects it, 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.

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

Beyond the readOnly/non-destructive annotations, the description discloses ordering (newest first), the exact fields returned, that single-call lookup includes the charge's final state and any async job, and precise auth requirements (requests:read, default behavior for unrestricted vs. product-line-limited keys). It also notes the tool is free, which is meaningful operational context.

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 description is front-loaded with the return fields and lookup mode, and every clause is relevant. It is somewhat dense and the permission explanation is verbose, but it contains no filler or repetition.

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 fully describes the return fields and ordering, covers both list and single-lookup modes, and explains the permission model and cost. Nothing essential for correct invocation is missing, and the schema handles limit/offset details.

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 already 100%, so baseline is 3. The description adds genuine meaning for request_id (where it comes from: request_id / X-Request-Id of any call, and what it returns: charge state and async job), though it adds little beyond the schema for limit, offset, and failed_only.

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 specific resource and scope: the account's call records, with enumerated fields (request_id, capability, status code, latency, rows returned, charged flag, amount). It also distinguishes two modes (listing vs. single-call lookup via request_id) and names the charge/refund and async-job context, making it clearly separable from siblings like usage or billing.

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 clear usage contexts: pass request_id to look up one call, use failed_only=true to list failures only, and otherwise list records. It does not, however, name alternative tools or explicitly state when not to use this tool versus everyinfra_usage or everyinfra_billing.

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

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

Annotations declare readOnlyHint=false and destructiveHint=true, and the description adds real context beyond them: searches are billed ('failed or empty searches leave no final charge, anything reserved is restored'), harvest is long-running ('tens of seconds to minutes'), semantic mode=deep is slower and costs more, and read auto-retries other fetch paths. It does not explain why the tool is flagged destructive/readOnly=false beyond the reservation/refund note, so a small gap remains.

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-loaded with the core sentence before the dispatch list, and each indented line carries one sub-tool with only the discriminating detail. Despite its length the text is dense with necessary routing information for 17 sub-tools, and the trailing warning is placed where it is read last but remembered.

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 needn't explain returns, and it does cover routing, cost/latency caveats and safety implications. The one real gap is that `params` is an untyped nested object, so the agent has no authoritative schema for each sub-tool's arguments and must infer them from inline hints.

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 `tool` enum and `params` object are nominally documented, but `params` is a free-form object ('The tool's params') with no per-sub-tool schema. The description compensates by naming concrete params inline (full, kind=patents, mode=deep, q/num in the example, and web's site/region/time-window/paging), adding meaning the schema lacks — though coverage of all 17 sub-tool param sets is incomplete.

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 sentence names the specific verb+resource (search and retrieve sources) and immediately discloses the dispatch mechanism ('17 tools, chosen with `tool`'), then enumerates every one with a distinct one-line purpose. An agent can distinguish crawl vs map vs harvest vs read without opening any other schema, and the tool is clearly separated from the account/billing/key siblings.

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?

Nearly every sub-tool line carries an explicit use/don't-use rule: 'use it only when crawl cannot get the data' (harvest), 'the opposite direction of media' (lens), 'something keyword search cannot do' (similar), 'use crosscheck to assert a specific fact'. The final warning line names the alternative tool for a concrete condition, which is exactly the when-to-use guidance an agent needs.

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

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

Adds substantial information beyond the annotations: it requires the settings:write scope, which is off by default and owner-grantable only in the console, and it flags the asymmetric security-notification behavior. It does not explain partial-update semantics (all nine params are optional) or what happens to omitted fields, which is a notable gap for a mutation 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?

Three tight sentences with the core action front-loaded and the authorization caveat and console-only constraint following in priority order. 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 nine-param, all-optional mutation with no output schema and no annotations covering permissions, the description supplies the crucial auth requirement and the key behavioral edge case. It still leaves partial-update semantics and the individual notification switches under-explained.

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?

With only 11% schema description coverage across nine parameters, the description bears most of the burden. It names language, time zone, notifications, and the low-balance threshold (clarying it is USD), but collapses six distinct notification booleans into one vague phrase and never explains that omitted fields may be left unchanged.

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?

Names a specific verb (Change) and resource (account settings) and enumerates concrete targets: console language, time zone, notification switches, and the low-balance alert threshold in USD. It is clearly distinguishable from siblings like everyinfra_account, everyinfra_billing, and everyinfra_webhook_set.

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?

Provides clear context for use, including a real when/when-not rule: security notifications can be enabled here but must be disabled in the console. It does not compare against sibling tools, but the operational constraint effectively scopes the tool's usage.

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

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

Annotations cover safety flags but say nothing about billing or failure behavior; the description fills that gap with per-call pricing, the crucial 'charged per successful solve' rule, refund of reserved funds on failed/empty attempts, and the proxy/IP-binding caveat for certain types. This is exactly the beyond-annotations context an agent needs before spending money.

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-loaded with the core action, then cost, then when-to-use, then the prerequisite — a sensible priority order. The dollar-range and refund parenthetical is dense, and the mixed-language/asterisk emphasis slightly clutters it, but nearly every clause earns its place.

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?

No output schema exists, so the description carries the return burden and does so by promising 'a ready-to-use solution'. Combined with pricing, failure semantics, and the cross-type param routing, an agent has everything needed to invoke this correctly.

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% and the type enum is self-explanatory, so the baseline is 3; the description adds real value by explaining that the params object is type-dependent and by flagging the subset of types that require the caller's own proxy because delivered cookies are IP-bound. It still doesn't name per-type param fields, hence not 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 ('Solve a CAPTCHA or bot challenge and get a ready-to-use solution') and immediately differentiates itself by noting that params vary per type and that everyinfra_list_captcha_types must be consulted first. An agent can distinguish this from query/billing/key siblings without opening any schema.

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 an explicit when-to-use trigger ('when a target site is blocked by Turnstile / reCAPTCHA / hCaptcha / a Cloudflare challenge page / GeeTest') plus the concrete prerequisite: check params with everyinfra_list_captcha_types first. Names both the condition and the sequencing step.

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

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

Goes well beyond the annotations: discloses a hard rate limit (10/account/UTC day), the human nature of replies, retry semantics via idempotency_key, and a required support:write scope that is off by default and owner-granted. This is exactly the operational context an agent needs before calling a write 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?

Four short sentences, each carrying a distinct operational fact (purpose, rate limit, idempotency, auth). The most important constraints are front-loaded and nothing is padded.

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 write tool with no output schema, the description covers purpose, quota, retry safety, and permission prerequisites. An agent has everything needed to decide whether it can even call this tool and how to retry it safely.

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 33%; only idempotency_key is documented in the schema, and the description usefully reinforces its retry use. But title and message semantics (length caps, content expectations) are left entirely to the schema with no added meaning.

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 ('Open a ticket with human support') and disambiguates the audience ('replies come from staff, not from an AI'). It does not, however, distinguish itself from the sibling everyinfra_create_ticket, which the agent must tell apart.

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 'human support' framing and the daily cap imply when this channel is appropriate, but the description never names the alternative (e.g. everyinfra_create_ticket or everyinfra_chat) or states when not to use it. Use context is implied rather than explicit.

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

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

Annotations only declare the generic write/non-destructive/openWorld profile; the description adds genuinely useful behavior beyond that: the scope is off by default and can only be granted by the account owner, and retries must preserve the idempotency key. It stops short of describing rate limits or exactly how the message is recorded, so not a full 5.

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?

A single dense sentence with the core action front-loaded, followed by the idempotency and permission caveats. Nothing is redundant, though the semicolon-chained clauses are packed.

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?

No output schema exists, so the description should carry the return behavior, and it partially does by noting that human support answers the message. With auth requirements and idempotency covered, the definition is nearly complete for a simple mutation, missing only the response shape.

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 only 33%, so the description must compensate, and it does explain idempotency_key semantics. However, the 4000-character limit on message and the role of ticket_id are left entirely to the schema, so coverage is partial.

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 ('Add a message to one of the account's support tickets') and clarifies that a human answers, which distinguishes it from the automated ticket_create sibling. It does not name ticket_create explicitly, so a small amount of sibling differentiation is left implicit.

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 clear operational context: reuse the same idempotency_key when retrying the same message, and the required support:write scope. It doesn't enumerate alternatives (e.g., use ticket_create for a new ticket), but the scenario for calling this tool is unambiguous.

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

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false, closed world), and the description adds non-obvious operational context: the call requires the 'support:read' account permission, that permission is off by default and must be enabled by the account owner in the console, and the call is free. This is exactly the auth/cost context annotations cannot convey.

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 short sentences, front-loaded with what the tool returns before the parameter behavior, then the permission and cost caveats. No filler, no repetition of the tool name or title.

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 does so ('the latest tickets', 'that ticket and its messages'). Combined with the permission and cost notes and a fully documented two-parameter schema, an agent has everything needed to invoke this correctly.

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: ticket_id is not just a filter, it switches the tool from list mode to single-ticket-with-messages mode. It does not describe the limit parameter's behavior beyond the schema's 'default 10', so it is a modest improvement over the schema rather than a full one.

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 resource (the account's support tickets) and its two operating modes: list latest tickets without ticket_id, or fetch one ticket plus its messages with it. This clearly separates it from siblings like everyinfra_ticket_create and everyinfra_ticket_reply, which act on tickets rather than reading them.

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?

Explicitly conditions usage on the ticket_id parameter ('without ticket_id, the latest tickets; with it, that ticket and its messages'), which tells the agent exactly when to use each mode. It stops short of naming alternatives or exclusions (e.g., pointing to ticket_reply for responding), so it is clear context rather than full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond that: no order is created, nothing is charged, any key can use it, and it is free. These are exactly the traits an agent needs before invoking it, though auth requirements are only stated loosely as 'any key.'

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 short sentences, front-loaded with what is returned, then the no-charge guarantee, then accessibility notes. No filler or repetition.

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 zero-parameter read tool, the description covers purpose, return value (link and balance), cost behavior, and key accessibility. With no output schema, the description appropriately names the two returned items. Could be slightly stronger by noting pagination or rate limits, but none are implied for this simple lookup.

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, so there is no schema-level parameter documentation to compensate for. The description correctly conveys that no input is needed, which is the right baseline for a 0-param tool.

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 (returns) and two concrete resources: the console top-up page link and the current balance. This is distinct from siblings like everyinfra_billing (likely invoice/payment data) and everyinfra_account, so an agent can route correctly without opening the schema.

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?

Explicitly says the account owner pays in the console and this tool creates no order and charges nothing, which tells the agent when NOT to expect a transaction. It doesn't name a specific alternative sibling for balance queries, but the use context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds genuinely non-structured context: UTC day boundaries, aggregation across all keys, exclusion of MCP handshakes, the required 'requests:read' scope with its default/per-key behavior, and that the call is free. It doesn't describe return shape, but with no output schema and a read-only profile that is a minor gap.

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, front-loaded with the core behavior, then the alternative, then the permission prerequisite. Every clause earns its place (scope qualifiers, permission name, console path), though the permission sentence is somewhat long for a secondary detail.

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 single-parameter, read-only, non-destructive tool with no output schema, the description covers scope, time semantics, aggregation, exclusions, permission requirements, cost, and the sibling alternative for spend. Nothing an agent needs to call it correctly is missing.

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% and the 'days' property already documents 'Number of days, default 7'. The description's 'UTC days' adds a small semantic clarification about how days are counted, which the schema does not state, but nothing about the 1–90 range or default beyond what the schema carries. Baseline 3 with a marginal add.

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 precise verb+resource ('Calls per day for the last N days') and qualifies the scope with 'UTC days, all keys combined, MCP handshakes excluded'. It also names the sibling to use for a different concern ('For spend use everyinfra_billing'), so an agent can distinguish it from everyinfra_requests and everyinfra_billing without opening schemas.

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?

Explicitly routes spend-related queries to everyinfra_billing and gives concrete prerequisites for use (the 'requests:read' permission, with defaults and console steps). It lacks an explicit statement of when this tool is the wrong choice beyond the spend case, so it falls short of a full when/when-not treatment.

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

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

Adds substantial behavior beyond the annotations: the signing secret is returned only on first creation (a one-time side effect the agent must warn about), the endpoint must be public HTTPS, and a privileged scope must be granted out-of-band. The annotations only say it is not read-only and not destructive, so the description carries and delivers the real behavioral payload.

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?

Two tight sentences, front-loaded with the action and its events, followed by the critical secret-on-creation caveat and the scope requirement. Every clause carries information; there is no filler.

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, no annotations of substance, and 0% schema coverage, the description supplies the prerequisites, the one-time secret return, and the per-event parameter condition. It does not clarify whether a subsequent call replaces or merges the existing event list, which is the one remaining ambiguity for an upsert tool.

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%, so the description must compensate and largely does: it explains url must be a public HTTPS endpoint, that balance.low requires balance_threshold_usd, and enumerates the supported events. Format constraints like the 2000-char url limit and non-negative threshold remain undocumented, so not quite complete.

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 ('Create or change the webhook endpoint') plus its events, which is far more informative than the title alone. It does not explicitly name a sibling such as everyinfra_webhook_test to distinguish itself, so it stops 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?

Gives real prerequisites: the settings:write account scope is off by default and must be granted by the account owner in the console. It also states the conditional requirement that balance.low needs balance_threshold_usd. It does not say when to use this instead of everyinfra_webhook_test, so no explicit alternative routing.

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

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

Goes well beyond the annotations (readOnly=false, destructive=false, openWorld=false) by disclosing that it is not retried, is rate-limited to 5 per minute, and requires the settings:write scope which is off by default and grantable only by the account owner in the console. That is exactly the kind of auth and limit context an agent needs before calling.

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 tight clauses: action first, then retry/rate-limit constraints, then the auth requirement. Nothing is repeated from the title or annotations and every sentence earns its place.

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?

Even without an output schema, the description states what is returned (HTTP status and latency), plus retry, rate-limit, and permission behavior. For a zero-parameter test action, an agent has everything needed to call it correctly.

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, so the schema carries nothing to explain and the baseline is 4. The description correctly implies no inputs are needed ('now', to the configured endpoint).

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 (send) plus the exact event type (one signed webhook.test) and its target (the configured endpoint), and names the key output (HTTP status and latency). This is clearly distinguishable from sibling everyinfra_webhook_set, which configures the endpoint this tool tests.

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 word 'now' plus 'configured endpoint' establishes the context: use this to verify an already-configured webhook. However, it never explicitly names everyinfra_webhook_set as the prerequisite/alternative, so the routing to a sibling is implied rather than stated.

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