AnyAPI

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

The description adds valuable behavioral context beyond the read-only annotations: latency metrics are nullable observations ('p99 is an observation, not a maximum'), and heavy:true entries can produce large responses requiring follow-up planning. This level of disclosure helps the agent anticipate response characteristics and downstream actions.

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 with front-loaded purpose and details, followed by actionable caveats. There is no redundant phrasing, and every sentence contributes either to what the tool returns or how to use the result safely.

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 an output schema and comprehensive annotations, the description covers the essential operational nuance: heavy responses, latency interpretation, and next-step planning. An agent has enough information to call this tool correctly and act on the returned data.

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 both sku_id and context are already well documented in the schema. The description reinforces that lookup is by SKU and mentions heavy:true response entries, but it does not add substantial meaning to the tool's own parameters beyond what the schema provides.

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: 'Get the full definition of one API by SKU,' and distinguishes this from list/search-style siblings by clearly enumerating the detailed contents (schemas, pricing, latency). An agent can immediately differentiate this from list_apis 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 provides a concrete use case: 'Inspect latency before choosing a client or MCP tool timeout,' and gives actionable guidance for heavy:true entries. It does not explicitly name alternatives or state when not to use the tool, but the context is clear enough for correct selection.

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 behavior context beyond annotations: the balance is returned in USD, and a valid Bearer token is required, which is an authentication-relevant behavioral detail.

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 22-word sentence that front-loads the core action ('Get the remaining wallet balance') and packs currency, token, and key requirement into minimal space. Every word earns its place, with no redundancy or 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?

For a simple read-only balance tool with one fully documented parameter and an output schema available, the description combined with annotations covers all necessary information: what it does, in what currency, how authentication works, and the safety profile. 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 input schema with detailed instructions and an example. Schema description coverage is 100%, so the description adds no additional parameter meaning. Baseline 3 is appropriate because the structured schema does the heavy lifting.

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'), identifies the exact resource ('remaining wallet balance'), specifies the currency ('in USD'), and clarifies the auth context ('AnyAPI key supplied as a Bearer token'). This clearly distinguishes it from sibling tools like get_api or list_apis, which target different resources.

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 includes a prerequisite ('Requires a valid AnyAPI key') and the purpose implies when to use the tool (checking wallet balance). However, it does not explicitly state when not to use it or mention any alternative tools, leaving some inference to the agent.

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, the description adds a critical behavioral guarantee: 'never repeats the paid provider dispatch.' It also clarifies that the tool reads AnyAPI's stored state, which helps the agent reason about side effects and safety.

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 with no filler: purpose, behavioral guarantee, and polling guidance. Each sentence adds distinct value and the most important constraint 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 an output schema present and helpful annotations, the description supplies the missing workflow details: retryAfterSeconds polling and the no-repeat dispatch guarantee. The word 'resume' is slightly ambiguous, and the relationship to read_result is not addressed, so a small gap remains.

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 parameters already have clear descriptions, including the request_id provenance and the detailed context requirements. The description adds only slight reinforcement ('returned by run_api'), so 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?

The description opens with specific verbs ('Inspect or resume') and a clear resource ('durable AnyAPI request returned by run_api'), and then clarifies the actual behavior as reading stored state. This distinguishes it from creation tools like run_api and makes the tool's role understandable instantly.

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-to-use context ('returned by run_api') and a concrete polling instruction ('Poll again after retryAfterSeconds while status is queued or running'). However, it does not explicitly state when not to use it or name alternatives such as read_result, so it stops 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?

Annotations already mark this as read-only, and the description adds rich behavioral context: results are lightweight summaries with no descriptions/schemas to keep cost low, and pricing offers expose both maxUsd and maxPer1kUsd with guidance to quote the per-1k figure. This goes well beyond the structured 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 dense sentences front-load the purpose, then add the key pricing nuance and sibling routing. Every sentence contributes information; 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?

Given the read-only annotation, 100% parameter coverage, and an existing output schema, the description covers the catalog scope, return format, pricing quirk, optional filtering, and when to use alternatives. Nothing needed for correct invocation 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 context and category already documented in the input schema. The description only restates the optional category filter and does not materially add meaning beyond the schema, so it earns the baseline 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?

Description names a specific verb ('Browse available AnyAPI APIs'), a precise resource (the API catalog), and the returned summary shape (id, name, category, USD pricing). It explicitly distinguishes itself from siblings by directing ranked queries to search_apis and full schemas to get_api.

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 explicit routing: 'Use search_apis for every ranked query, or get_api for one API's full schemas.' It also states optional category filtering, leaving no ambiguity about when list_apis is appropriate.

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?

Even with readOnlyHint=true, the description adds substantial behavioral context: 'free, no key required, nothing is charged or executed', schema validation, and return-value interpretation. It also warns against scaling quoted amounts to 1,000 requests, which 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?

The description is front-loaded with the key purpose and safety guarantee, then adds usage details, return semantics, and a reporting caveat. Every sentence earns its place with 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?

Given the tool's moderate complexity, output schema presence, and three well-documented parameters, the description is complete. It covers what the tool does, how to call it, what it returns, and an important usage caution.

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 meaning beyond the schema by tying sku_id and input directly to run_api ('the same sku_id and input you would give run_api') and explaining that pricing resolves exactly as the run will.

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: 'Get the exact price of a run_api call BEFORE running it'. It clearly distinguishes quote_api from run_api by emphasizing that the quote does not execute or charge, and names run_api directly as the related operation.

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 clear context for when to use the tool: before run_api, with the same sku_id and input. It names run_api as the alternative but does not explicitly state when not to use it or list exclusions, so it falls just short of a perfect 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavior beyond them: results are cached ~15 minutes, private to the user's key, and an expired id returns result_expired. This tells an agent exactly what to expect without any surprise side effects.

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 front-load the core value proposition, then name the parameters and their purpose, then cover caching and expiry behavior. Every sentence earns its place with no 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?

With a full input schema, an output schema, and annotations covering safety, the description fills the only remaining gaps: caching duration, privacy, expiry behavior, and the workflow relationship to run_api. An agent has everything needed to call this 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?

Schema coverage is 100%, so the baseline is 3, and the description adds meaning by explaining these parameters re-shape the full cached result, with concrete examples like reading the rest of the rows or slicing a large field with jq. This goes beyond the schema's individual parameter docs.

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: dig deeper into a paid run by reading a cached result without re-running or paying. Explicitly distinguishes itself from run_api by requiring a prior result_id, so an agent can tell them apart at a glance.

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 context: use it after a prior run_api call when you want to re-shape data, read more rows, or slice a large field without paying again. It implies run_api is the alternative, though it does not explicitly say 'do not use run_api unless you need a new run.'

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, the description discloses that reporting is free and never charged, that request_id reaches the stored run and upstream error body so payloads never need to be pasted, and that the agent should not stop the user's task or ask permission. This is rich, actionable behavioral 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 purpose, then gives concrete use cases, cost information, and operational guidance. Every sentence adds value; there is no filler or redundancy despite covering several important aspects.

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?

The tool has an output schema and fully documented parameters, so the description only needs to explain when and how to invoke it. It does that completely: what counts as a bug, which fields to pass, how to handle request_id, and what to do mid-task. 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 schema already documents all six parameters thoroughly. The description reinforces that summary is required and one line and that request_id is valuable, but it largely restates schema content rather than adding new parameter-level meaning, so the baseline score of 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?

The description opens with 'Tell AnyAPI something is broken' and then lists unmistakable bug symptoms (wrong/empty/malformed data, misleading errors, bad prices/schemas, failed retries). This gives a specific verb, resource, and scope that clearly separates reporting a bug from generic feedback or API execution.

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 trigger conditions: use when run_api returns bad data, when error messages are misleading, when a price/schema looks wrong, or when a retry that should have worked did not. It does not explicitly say when not to use it or name send_feedback as the alternative for non-bug feedback, so it stops just short of a perfect 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?

Adds rich behavioral context beyond the annotations: strict schema rejection, Bearer token requirement, 'Charges the USD wallet only on success,' the p99-is-not-a-maximum caveat, and large-result risk. These details help the agent anticipate failures and side effects, and they do not contradict the destructiveHint/readOnlyHint 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 dense but well-organized: core action first, then prerequisites, latency warning, authentication/billing, response-size guidance, and quoting. Every sentence earns its place, and there is no 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 complex 7-parameter tool, the description covers the critical operational concerns: fetching the correct schema, validating via quote_api, billing behavior, latency interpretation, authentication, and output trimming. The output schema handles return-structure documentation, so nothing essential 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%, so the baseline is 3, but the description adds operational meaning: 'input' is normalized, fields/max_items/summary trim responses, and these options 'never change what you are charged.' This supplements the schema's structural definitions with cost and context-management semantics.

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: 'Execute an API by SKU with a normalized input payload.' This clearly differentiates it from siblings like get_api (schema inspection) and quote_api (pricing), and the reference to a normalized payload signals exactly what kind of operation it performs.

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 instructs when to call this tool versus alternatives: 'Call get_api for this SKU first' and 'Use quote_api first with the same arguments to see the exact price and validate your input without charging.' It also provides practical guidance about inspecting latency before setting timeouts.

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?

Given annotations only indicate readOnly and non-destructive behavior, the description carries the burden of explaining much more. It reveals relevance scoring, relevance floors, total-before-limit counting, ranking type, no input schema in results, heavy:true implications, and the expected first-call schema requirement. 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 front-loaded and dense with useful behavioral guidance. It is somewhat long and includes a somewhat anecdotal rejection-rate warning, but nearly every sentence contributes practical information about output, relevance, heavy responses, or the required get_api follow-up.

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 search tool with no output schema details required, the description is extremely complete. It explains why results are insufficient for run_apis, what to do before first run, how to handle heavy:true entries, and how the tool relates to list_apis and get_api. Nothing essential is missing for an agent to call this 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?

Schema coverage is 100% for basic fields, so the baseline is 3, but the description adds real combinatorial semantics: at least one of query/category/platform, scope-only enumeration, and how limit interacts with relevance/total. It adds substantial meaning beyond the schema, though the context parameter needs no additional explanation.

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 tool searches APIs by meaning and keyword across name/slug/description, returns ranked matches with descriptions, and omits schemas. It differentiates itself from siblings like list_apis, get_api, and run_api by describing its exact role and output shape.

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 says when to use the tool, which parameters must be passed, how categories/platforms work as standalone scopes, and how to combine with limit. It also routes the user to get_api for schemas before run_api and to list_apis for browsing, covering when-not-to-use this 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?

The annotations provide no meaningful behavioral guidance, so the description carries the burden. It adds useful transparency by stating 'Free, never charged' and clarifying that this is feedback rather than a defect report. It does not disclose whether submissions create records or reach a human, but it gives agents an accurate sense of the operation's low-risk, non-defect nature.

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: scoping, cost behavior, and parameter-routing guidance. The most decision-relevant information is front-loaded, and there is no filler or redundant restating of the tool name.

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 six-parameter tool with a fully described schema and an output schema, the description covers the essential decision: what counts as feedback and when to use report_bug instead. It does not mention that `context` is also required or that it has strict formatting rules, but those are fully specified in the schema and the description's omission does not prevent 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 schema already documents every parameter clearly. The description adds meaningful guidance beyond that: it highlights that `summary` is required and one line, and it explains that `details` should capture what the user was trying to accomplish. This helps the agent compose a useful submission without duplicating schema content.

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') and enumerates concrete non-defect feedback examples: missing APIs, missing fields, confusing docs, and friction points. It also explicitly contrasts with report_bug, which makes its scope unmistakable and distinguishes it from a key sibling.

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—for non-defect feedback—and explicitly names the alternative: 'Use report_bug instead when something behaved incorrectly.' It also gives example triggers, leaving no ambiguity about which cases belong here versus a sibling.

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