AnyAPI

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

Annotations establish readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context beyond those annotations: latency fields are nullable, p99 is an observation not a bound, and heavy:true entries return large payloads. This helps the agent predict response characteristics and plan follow-up 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, each serving a distinct purpose: what is returned, why latency matters (with a caveat), and how to handle heavy responses. The most important scoping information appears first, and there is no filler or repetition of schema content.

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 exists, the description correctly avoids repeating return-value structure. What it does add—latency interpretation, heavy-entry warning, and routing to run_api—closes the main practical gaps an agent would face when deciding whether and how to call this 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 100%, so the input schema already fully documents sku_id and context, including a detailed instruction block for the context parameter. The description does not add parameter-specific meaning beyond restating the 'by SKU' concept, which is already in the tool title. Baseline 3 applies because the schema carries the burden.

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 operation (get the full definition of one API by SKU) and enumerates the exact content returned (schemas, per-lane pricing, latency statistics). This distinguishes it from sibling tools like list_apis or search_apis, which would not return this level of detail for a single resource.

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 explicit when-to-use guidance: inspect latency before choosing a timeout. It also gives actionable advice for heavy responses by suggesting alternatives (fields/max_items/summary in run_api), showing awareness of related tools without ambiguity.

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 read-only and non-destructive. The description adds useful behavioral context: the balance is tied to a specific Bearer-token key, and a valid key is required, indicating an auth-dependent lookup. This goes beyond the structured hints and does not contradict them.

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 a single sentence that states the action, resource, unit, and auth requirement with no filler. Information is front-loaded and every word 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?

This is a simple read-only balance lookup. Combined with the readOnly and destructive annotations, an output schema, and a fully documented parameter schema, the description covers the goal, auth mechanism, and prerequisite. Nothing essential 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?

The only parameter, 'context', is fully documented in the schema with word-count, perspective, and content constraints, so schema coverage is 100%. The description does not attempt to re-explain the parameter, and the baseline of 3 is appropriate since the description adds no parameter-level semantics beyond what the schema already 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 uses a specific verb ('Get'), identifies the resource ('remaining wallet balance in USD'), and states the auth mechanism ('AnyAPI key supplied as a Bearer token'). This clearly distinguishes it from siblings like list_apis, get_api, or quote_api, so an agent can select it unambiguously for balance queries.

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 implies when to use the tool (whenever the remaining wallet balance is needed) and states the prerequisite of a valid AnyAPI key. However, it does not explicitly mention alternatives or when not to use it, leaving sibling differentiation to the agent's 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 readOnlyHint annotation, the description adds valuable behavioral context: it reads AnyAPI's stored state, never repeats the paid dispatch, and explains the polling semantics. This gives an agent a clear mental model of side effects and safe repeatability.

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 with no filler. It front-loads the core purpose, then adds the critical behavioral guarantee and polling guidance.

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 description is sufficient for an agent to call this tool correctly: it explains what the tool does, when to call it again, and that it will not cause another paid dispatch. The output schema covers return-value expectations, so no further detail is needed.

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 both parameters thoroughly. The description reinforces that request_id comes from run_api but does not add meaning 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 clearly states the tool inspects or resumes a durable AnyAPI request returned by run_api, and it explicitly says it never repeats the paid provider dispatch. This distinguishes it from run_api, though it does not explicitly differentiate it from siblings like read_result.

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 concrete usage guidance: poll again after retryAfterSeconds while status is queued or running. It implies the tool should be used after run_api has created the request, but it does not explicitly name alternatives or state when not to use the 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 already establish readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond that: results are lightweight summaries without descriptions or schemas, the call is cheap even across the whole catalog, and it clarifies the pricing semantics between maxUsd and maxPer1kUsd with guidance to quote the per-1k figure.

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: the primary purpose appears first, followed by the key behavioral caveat and pricing clarification, and ends with sibling routing. Every sentence carries useful information without redundant 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?

The description covers the tool's scope, cost profile, output shape, pricing nuance, filtering, and explicit alternatives, while the output schema and annotations cover return values and read-only safety. Nothing essential is left unexplained for an agent to select and invoke 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?

Schema description coverage is 100%, so the schema already fully documents the context and category parameters. The description adds the 'Optionally filter by category' usage note but otherwise does not substantially enhance parameter-level understanding 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 states a specific verb 'Browse' with a specific resource ('available AnyAPI APIs') and the exact summary fields (id, name, category, USD pricing). It also explicitly distinguishes itself from siblings by naming search_apis and get_api as alternatives, so an agent can clearly identify when this tool is appropriate.

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 optional category filtering, making the selection criteria 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?

The description goes beyond the annotations by disclosing that the quote is free, requires no key, does not execute or charge anything, and resolves pricing exactly as the run will. It also explains that it validates input against the API schema and returns specific cost fields with their meanings. Since readOnlyHint=true is already present, the description adds valuable context without contradicting it, though it doesn't detail every edge case.

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 most important fact (free, no key, no charge/execute), and every sentence adds value: usage caveat, validation benefit, return fields, and a critical scaling warning. It is well-structured and avoids redundancy despite covering several key 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?

For an agent deciding whether and how to invoke this tool, the description covers the necessary context: when to use it, what inputs to provide, what it returns, and what not to do with the results. With a full input schema and output schema, nothing critical 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 description coverage is 100%, so the schema already documents each parameter. The description adds meaning by explaining that sku_id and input must match exactly what would be passed to run_api, and it gives context for the returned cost fields. It reinforces the relationship between parameters and tool behavior, though it doesn't describe the context parameter in detail 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?

The description is specific and action-oriented: it states the tool quotes pricing for a run_api call before execution, with no charge or execution. It distinguishes itself from siblings like run_api and read_result by focusing on pre-run pricing, and explicitly mentions validation, making its purpose 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?

The description explicitly tells the agent to use this tool BEFORE running run_api, to pass the same sku_id and input as intended for run_api, and to catch invalid_input for free. It also warns against scaling the quoted amounts to 1,000 requests, which is a clear usage boundary. This effectively separates it from run_api and other siblings.

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 meaningful behavioral detail beyond that: results are cached for roughly 15 minutes, cached results are private to the key, expired ids produce a specific error, and reshaping can be done with jq/fields/max_items/summary. This gives the agent a clear safety and lifecycle picture without contradicting 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, each earning its place: the first states the core value proposition and differentiator, the second explains the mechanics with concrete options, and the third covers critical cache/privacy/expiry behavior. Key constraints are 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 six-parameter tool with a full input schema and an output schema present, the description covers everything an agent needs to decide when to call it and what to expect: no rerun/charge, source of result_id, optional reshaping parameters, cache lifetime, privacy, and the expired-id error path. No critical contextual 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?

Input schema coverage is 100%, so the schema already documents every parameter. The description adds value by grouping the reshaping parameters ('fields/max_items/summary/jq'), giving a concrete example of their intended purpose, and showing how they relate to the cache/result_id workflow rather than merely repeating schema 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?

The description states a specific verb ('read' / 'dig deeper into') with a concrete resource ('a paid run' / 'cached result') and clearly distinguishes it from run_api by emphasizing it does not re-run or charge. It also names the exact input source ('result_id from a prior run_api call').

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 usage context is explicit: use this tool after a prior run_api call, when you want the cached result without paying again. It even handles the expiry case by stating that an expired id returns result_expired and directs the agent to re-run to refresh, which serves as practical alternative 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?

Beyond the annotations' basic flags, the description discloses that reporting is free/non-charged, that request_id connects to stored runs and upstream error bodies, and that the agent should proceed with the task rather than pause for user consent. These are valuable behavioral traits an agent could not infer from the schema alone.

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 core purpose, then conditions, then cost, then parameter hints, then behavioral directive. Every sentence contributes distinct guidance and there is no filler or repetition of schema field names.

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 reporting tool with six parameters and a full output schema, the description covers purpose, triggers, behavior, cost, and the most important parameter semantics. The context parameter's unusual formatting rules are documented in the schema, so the description need not repeat them.

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 parameter guidance: summary should be one line, request_id is the single most useful field and eliminates the need to paste payloads, and details are not to be filled with raw payload content. This raises it slightly above baseline.

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 concrete verb and resource ('Tell AnyAPI something is broken') and then enumerates specific triggering conditions—wrong/empty/malformed data, misleading errors, bad pricing/schema, failed retries. This clearly identifies the tool as bug reporting and differentiates it from general-purpose sibling tools like send_feedback by tying it to failing run_api calls.

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 conditions with concrete examples and instructs the agent to file the report and continue without asking permission. It does not explicitly name an alternative tool for non-bug feedback, so the when-not-to-use guidance is only implied.

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 significant behavioral context beyond the annotations: strict schema rejection, latency p50/p95/p99 caveats, Bearer token requirement, wallet charging only on success, and response-size trimming options. These details meaningfully inform the agent's expectations and risk assessment. No contradiction with the annotations is present.

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 but every sentence carries operational weight: prerequisites, strictness, timeout guidance, auth, cost, and response shaping. It is front-loaded with the core purpose and the most critical prerequisite first. There is 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?

Covers prerequisites, schema strictness, latency behavior, auth, cost model, validation workflow, and response-size mitigation. Since an output schema exists, return-value details need not be repeated. For a complex, externally-charged execution tool, this is a thoroughly complete description.

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 cross-parameter semantics by grouping fields, max_items, and summary as cost-neutral response trimmers, and it clarifies that quote_api can validate the same arguments. This adds value beyond the individual schema descriptions, though the schema already does most of the work.

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." It clearly differentiates from siblings like get_api and quote_api by the action and prerequisite relationship. The scope is unmistakable even before reading 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 directs the agent to call get_api first unless the schema was already read, warns that inputs built from descriptions usually fail, and tells the agent to use quote_api first for price validation. This gives clear when-to-use and when-not-to-use guidance relative to 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?

Beyond the readOnlyHint=true annotation, the description adds rich behavioral context: relevance scoring with a floor that drops weak matches, 'total counts relevant matches before the limit,' the semantic vs. keyword 'ranking' flag, heavy:true response implications, and the absence of input schemas in results. It also quantifies the failure-rate benefit of reading schemas first. None of this is available from annotations alone.

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: it front-loads the core purpose, then systematically covers parameter rules, output semantics, operational caveats, and sibling routing. The warning about guessing inputs is a valuable addition despite adding length. Information is ordered from most to least critical.

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 description provides everything an agent needs to call search_apis correctly and to avoid the common pitfall of invoking run_api without a schema. It explains the output fields, the limit behavior, the heavy:true case, and the required follow-up call to get_api. Given that an output schema exists, the description still adds necessary context around return semantics and operational constraints.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains the 'at least one' relationship among query/category/platform, that a scope alone is a complete search, how limit caps results, and the extra result fields (relevance, total, ranking) that parameter choices affect. For example, 'category or platform with no query enumerates it' is not derivable from 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?

The description explicitly states the verb and resource: 'Search APIs by meaning and keyword across name, slug, and description.' It also clarifies the output shape ('returning matches WITH their descriptions (schemas omitted), ranked most relevant first') and distinguishes itself from siblings like list_apis ('Use list_apis to browse everything'). This leaves no ambiguity about what the tool does.

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 guidance on when to use this tool and when not to: 'before your FIRST run_api on any API, call get_api for it' and 'Use list_apis to browse everything.' It also explains the valid parameter combinations ('Pass query, category, or platform - at least one') and how scopes alone constitute complete searches, making the decision boundary 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 indicate no readOnly, no idempotent, no destructive hints, so the description carries the burden of explaining side effects. It adds useful behavioral context ('Free, never charged', 'pass summary', 'use details'), but does not explicitly state that this creates a support ticket or feedback record, nor what the response contains. With an output schema present, the response shape is covered, so a 3 is fair.

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: it defines the tool's purpose in the first sentence, gives concrete examples of appropriate feedback, and ends with the sibling routing rule. It is slightly dense but every sentence earns its place. Minor structural improvement would be separating the parameter guidance from the purpose statement, but it is not bloated.

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 non-destructive, feedback-collection nature and a full output schema, the description covers the core context well: what kind of feedback is welcome, that it is free, how to structure the content, and when to use report_bug instead. It could mention whether the feedback is anonymous by default or what happens after submission, but those are minor gaps for a low-risk tool with a clear output schema.

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 meaningful value by explaining the intended split between summary and details, emphasizing that summary is one line, and by describing what fields like sku and request_id are useful for. Some parameter-specific nuance, such as the request_id guidance, lives in the schema already, but the description's guidance on using details versus summary strengthens the agent's ability to fill the fields correctly.

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 ('Tell') and resource (AnyAPI feedback), and explicitly distinguishes its scope: non-defect feedback about missing APIs, fields, docs, or task friction. It clearly differentiates from the sibling report_bug, so an agent can tell them apart without inspecting either 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?

The description gives explicit when-to-use context ('an API you wanted and could not find', 'a field missing', 'confusing docs') and an explicit alternative ('Use report_bug instead when something behaved incorrectly'). This is exactly the kind of routing guidance that lets an agent choose correctly between siblings.

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