anyapi

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

Annotations already mark it read-only and non-destructive, but the description adds valuable behavioral context beyond that: p99 is an observation rather than a maximum, latency data is nullable and trailing-30-day, heavy:true responses can be large, and the returned payload includes sample counts. This gives an agent accurate expectations about what the call returns and how to handle it.

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 dense but every sentence earns its place: the first states exactly what is returned, the second gives concrete usage guidance, and the third warns about heavy responses and points to run_api parameters. It is front-loaded and contains no filler or repetition of schema fields.

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 an output schema, the description need not re-explain return values; here it goes beyond that by covering pricing units, latency caveats, sample counts, large-response behavior, and next-step guidance for run_api. An agent has what it needs to decide when to call this tool and what to do with the result.

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 schema already fully explains sku_id and context. The description reinforces that sku_id is a SKU slug and hints at heavy-response handling, but it does not add significant parameter-level meaning beyond the schema. Baseline 3 is appropriate here.

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 uses a specific verb ('Get'), a precise resource ('full definition of one API by SKU'), and enumerates exactly what is included: normalized JSON schemas, lane-level pricing, and latency percentiles with sample counts. This clearly differentiates it from sibling tools like list_apis or search_apis, which would not return all these details.

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 gives a clear use case: inspect latency before choosing a client or MCP timeout, and plan around heavy:true entries by using fields/max_items/summary when calling run_api. It does not explicitly state when not to use this tool or how it compares to list_apis/search_apis, so it falls short of a 5 but is much stronger than a vague generic statement.

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 set readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds useful behavioral detail: the result is denominated in USD and a valid key must be presented as a Bearer token. It does not cover error responses or rate limits, but for a simple read-only balance check the added context is adequate.

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 short sentences, with the core function front-loaded and the authentication requirement as a concise second clause. No filler or redundancy.

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 tool with an output schema, the description supplies the essential facts: what is checked, the currency, and the required authentication. Nothing an agent needs to invoke 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?

The only parameter, context, is fully described in the schema (100% coverage), so the description does not need to document it. The Bearer-token mention clarifies that the API key is not a separate parameter but an auth header. This matches the baseline of 3 for high schema coverage.

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 resource ('remaining wallet balance'), a unit ('in USD'), and an authentication context ('AnyAPI key supplied as a Bearer token'). It clearly distinguishes get_balance from siblings like get_api or run_api, none of which concern wallet balances.

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 establishes that the tool is for checking the balance tied to the current API key, which implies using it before or instead of making billable API calls. It does not name alternatives, but the context is unambiguous given the sibling list contains no other balance-related tool.

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 mark the tool as readOnly. The description adds valuable behavioral context: it reads AnyAPI stored state, never repeats the paid dispatch, and supports polling after retryAfterSeconds. This goes beyond the annotation baseline.

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 deliver purpose, behavioral guarantee, and polling guidance with no filler. The most important and differentiating information is front-loaded.

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 full parameter documentation and an output schema present, the description covers the essential usage cycle: inspect state, avoid duplicate dispatch, poll while queued/running. The term 'resume' is slightly unexplained, but the overall call guidance is complete enough for an agent.

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 schema documents both parameters well. The description adds minor context by indicating request_id comes from run_api, but the schema already carries the primary semantic weight.

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?

Description names specific verbs 'Inspect or resume' and a clear resource: durable AnyAPI requests returned by run_api. It also explicitly states that this reads stored state and never repeats the paid provider dispatch, which differentiates it from run_api and other sibling tools.

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 clearly frames when to use the tool: after run_api, and while polling 'queued' or 'running' requests via retryAfterSeconds. It does not explicitly name alternatives or exclusion conditions, but the polling guidance is concrete and actionable.

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 annotation, the description discloses meaningful behavior: the output is intentionally lightweight and cheap, excludes descriptions/schemas, and each pricing offer includes maxUsd and maxPer1kUsd with guidance to quote the per-1k figure. This adds real context for an agent deciding whether this tool fits the task.

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 compact, front-loaded with the core purpose, and each sentence carries distinct value: output content, cost/behavior, pricing-field semantics, and sibling routing. There is 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 read-only listing tool with a rich output schema and explicit sibling guidance, the description covers the essential decision factors: scope, filtering, cost behavior, field semantics, and when to use alternatives. Nothing needed for correct invocation or selection 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 input schema already provides 100% coverage for both parameters, so the baseline is 3. The description adds only that category is an optional filter, which is helpful but not a major semantic extension beyond the schema's own description.

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 uses a specific verb and resource: 'Browse available AnyAPI APIs as lightweight summaries', and clearly scopes the result set to id, name, category, and USD pricing. It also distinguishes itself from siblings by explicitly saying it lacks descriptions/schemas, which separates it from get_api and search_apis.

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 gives explicit routing guidance: 'Use search_apis for every ranked query, or get_api for one API's full schemas.' It also notes the optional category filter, so an agent knows when list_apis is the lightweight browsing choice and when an alternative is better.

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 and destructiveHint annotations, it discloses free access, no key required, no charge/execution, input-schema validation, and the meaning of min/max cost. These behavioral details help the agent set expectations and distinguish a quote from an actual run.

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 purpose and timing; every clause adds operational or safety-relevant information, with no filler. The length is appropriate for the tool's complexity.

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 selection, invocation, output semantics, and post-processing constraints. With an output schema present and sibling context given, no critical decision information 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 schema already documents all three parameters with high coverage; the description contributes the crucial relationship that input and sku_id must exactly match what would be passed to run_api, and explains validation behavior. It does not need to duplicate the context-parameter instructions already present in 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 the precise action ('Get the exact price of a run_api call') with explicit timing ('BEFORE running it'), a distinct resource ('run_api'), and clear scope ('nothing is charged or executed'). This clearly separates it from siblings such as run_api, get_api, and list_apis.

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 when-to-use direction: call it before run_api with the same sku_id and input, and use it as a free validation/quote step. It also adds a usage boundary ('report them as-is and never scale them to 1,000 requests'), though it does not enumerate alternatives beyond run_api.

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=true annotation, the description discloses caching (~15 min), privacy (private to your key), and expiration behavior (result_expired). It also explains that fields/max_items/summary/jq reshape the cached result, adding transparency about how the tool modifies output. No contradiction with 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?

The description is two sentences, front-loads the key benefit ('Dig deeper into a paid run WITHOUT re-running or paying again'), and packs essential usage and behavioral info without fluff. 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?

Given the tool's complexity (6 params) and the presence of an output schema, the description covers the main use cases, caching, expiration, privacy, and reshaping capabilities. It doesn't miss critical information an agent needs to call it correctly, and the output schema covers return 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?

The schema already documents all parameters (100% coverage), but the description adds value by explaining how the parameters collectively reshape the result and gives a concrete jq example ('.data | {title, description, md: .markdown[:3500]}'). This goes beyond the schema's individual 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 description clearly states the verb 'read' and the resource 'cached result' from a prior run_api call, explicitly distinguishing it from running a new API call. It says 'WITHOUT re-running or paying again' and gives concrete examples like 'read the rest of the rows' or 'slice a large field with jq', making the purpose unambiguous.

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 explicitly frames when to use this tool: to avoid re-running or paying for a paid run. It references the alternative run_api ('from a prior run_api call') and provides usage examples (read more rows, slice large field). It also warns about the expiration case ('an expired id returns result_expired (re-run to refresh)'), telling the agent when to re-run instead.

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?

The description adds meaningful behavioral context beyond the all-false annotations: it states the action is free and never charged, explains that request_id reaches the stored run and upstream error body, and instructs the agent to file and continue without asking permission. No contradiction with 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?

The description is four sentences with no filler: purpose, trigger conditions, cost implication, parameter guidance, and behavioral directive are each addressed in order. Every sentence earns its place and the most important usage rule is front-loaded.

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 bug-reporting tool with a rich schema and output schema present, the description covers purpose, when to trigger, key parameter guidance, cost, and expected agent behavior. No critical information is missing for selecting and invoking the tool 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?

Even though schema coverage is 100%, the description adds real value beyond it: it emphasizes that summary is required and one line, positions request_id as the single most useful field, and explains why pasting the payload is unnecessary. This helps the agent prioritize parameters effectively.

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 ('Tell AnyAPI something is broken') and then enumerates concrete failure scenarios that make the tool's scope unmistakable. It clearly distinguishes bug reporting from the sibling tools, e.g., run_api and send_feedback.

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 explicitly says 'Use this when' and gives a detailed list of triggering conditions: wrong/empty/malformed data, misleading errors, suspicious prices/schemas, and failed retries. It also tells the agent not to pause the user's task and to proceed with the best alternative, which is strong operational 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?

The description discloses important behaviors beyond the annotations: strict unknown-field rejection, Bearer-token authentication, charging only on success, latency p50/p95/p99 caveats, and response-size controls that do not affect cost. It adds substantial operational context without contradicting the readOnly/destructive hints.

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 dense but well-structured, leading with the core purpose and then layering prerequisites, auth, cost, and response-shaping guidance. Every sentence carries operational value; there is no filler or redundant repetition of schema details.

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?

Given the tool's complexity and rich schema, the description covers preconditions, authentication, cost model, timeout considerations, and how to avoid context overflow. With an output schema present, no essential calling information 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 input schema already documents all seven parameters, so the baseline is 3. The description adds cross-cutting semantic value by explaining that schemas are strict, that input must be normalized, and that fields, max_items, and summary uniformly reduce response size without changing cost—information not obvious from individual parameter 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 description clearly states a specific verb and resource: "Execute an API by SKU with a normalized input payload." It also differentiates itself from the siblings by explicitly naming get_api and quote_api as separate prerequisite tools, so an agent can tell run_api apart without opening their 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?

The description gives explicit when-to-use guidance: call get_api first unless the schema was already read, use quote_api first to validate input and see pricing, and consult get_api before setting timeouts. It directly names alternatives and the conditions that select them.

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 readOnlyHint/destructiveHint annotations, the description discloses rich behavior: relevance scores in (0,1], a relevance floor, ranking modes, heavy:true response implications, and the absence of input schemas in results. It also quantifies failure rates for callers who skip schema lookup, giving agents a strong behavioral expectation.

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 longer than the minimum but every section earns its place: search semantics, parameter usage, return behavior, and the critical get_api prerequisite. The only mild redundancy is repeating the schema's default/max for limit and the cautionary sentence, which slightly extends length but retains instructional value.

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?

An output schema exists, so return-value documentation is not strictly required, yet the description still covers relevance, ranking, total, and heavy-response behavior. It also closes the operational loop by telling the agent to call get_api before run_api, making the tool safely callable in its intended workflow.

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 baseline is 3. The description adds value by clarifying that query is required, category/platform are narrowing filters, limit caps matches with defaults, and how relevance/ranking semantics interact with search. This goes beyond the schema's field-level text without being overly verbose.

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 states a specific action and object: 'Search APIs by meaning and keyword across name, slug, and description.' It clearly distinguishes itself from siblings by noting returns include descriptions but omit schemas, ranked by relevance, and later points to list_apis for browsing and get_api for 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?

It explicitly instructs when to switch to alternatives: 'Use list_apis to browse everything' and 'before your FIRST run_api on any API, call get_api for it.' It explains that search results alone cannot support a run_api call, which prevents misuse and gives clear decision 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 provide only neutral hints, so the description carries much of the behavioral burden. It adds the useful 'Free, never charged' cost signal and clarifies the feedback is not a defect report, but it does not describe side effects, delivery behavior, or what happens after submission. This is acceptable but not deeply transparent.

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 compact and front-loaded with the core purpose, followed by the cost note, parameter guidance, and the sibling-tool handoff. It is a bit longer than strictly necessary, but every sentence earns its place and no information is repeated from 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?

Given the rich schema, output schema, and sibling context, the definition is close to complete: it covers what the tool is for, what it is not for, and which alternative to use. The main residual gap is that the description does not mention the required 'context' parameter behavior, although the schema explains it in detail.

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 baseline is 3. The description adds a small amount of parameter nuance ('summary' should be one line; 'details' should describe what the user was trying to accomplish), but it does not discuss the required 'context' parameter or the optional fields. The schema handles those adequately.

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 uses a specific action ('Tell AnyAPI something that is not a defect') and enumerates concrete cases: a missing API, a missing field, confusing docs, or something that would have made a task easier. It also explicitly differentiates from report_bug, so an agent can immediately recognize this is for non-defect feedback.

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 states exactly when to use this tool and names the alternative: 'Use report_bug instead when something behaved incorrectly.' It also gives multiple valid use examples, making the selection boundary clear even without inspecting other tools.

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