AnyAPI
Server Details
Hundreds of scraping and data APIs through one gateway — one key, USD pay-per-request, normalized schemas, automatic failover.
- Status
- Healthy
- Uptime
- 85.2% over 65 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 10 tools
Most tools have clearly distinct purposes: discovery (list_apis, search_apis, get_api), pricing (quote_api), execution (run_api), and result inspection (get_request, read_result). There is some potential overlap between catalog-browsing tools and between request/result retrieval, but the descriptions make the boundaries reasonably clear.
All tool names use a consistent snake_case verb_noun pattern: get_api, get_balance, get_request, list_apis, quote_api, read_result, report_bug, run_api, search_apis, send_feedback. The convention is predictable throughout.
The server exposes 10 tools, which is well-scoped for an API marketplace covering discovery, inspection, pricing, execution, result retrieval, billing, and feedback. Each tool appears to earn its place without obvious redundancy.
The surface covers the core API-consumer lifecycle: find, inspect, quote, run, read results, check balance, and report issues/feedback. Minor gaps exist, such as no explicit request-history listing, cancellation, wallet top-up, or key-management tools, but these are not blockers for the main workflows.
Available Tools
10 toolsget_apiGet API detailsARead-onlyInspect
Get the full definition of one API by API slug, including its normalized input/output JSON schemas, per-request and per-1,000-request USD pricing on every source, and nullable trailing-30-day latency p50/p95/p99 with the successful sample count. Latency percentiles describe observed successful requests; p99 is an observation, not a maximum or a client timeout guarantee. Entries with heavy:true produce large API responses.
| Name | Required | Description | Default |
|---|---|---|---|
| sku_id | Yes | the API SKU slug to describe | |
| context | Yes | Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking. |
Output Schema
| Name | Required | Description |
|---|---|---|
| scraper | Yes | the API definition with input/output schemas |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive), yet the description adds genuinely non-obvious context: latency fields are nullable and describe observed successful requests, p99 is an observation not a timeout guarantee, and entries with heavy:true produce large responses. The p99 caveat and the response-size warning are exactly the kind of disclosure an agent can't derive from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the returned payload in the first sentence, then appends caveats about latency semantics and heavy responses. Dense but every clause carries information; the heavy:true note is slightly tacked on at the end rather than integrated.
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 values need not be fully explained, yet the description still enumerates payload contents plus latency nullability and response-size warnings. It is complete for a single-resource lookup; only explicit sibling routing (vs list_apis/search_apis) is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are documented there, so the schema does the heavy lifting. The description's 'by API slug' loosely maps to sku_id, though the schema calls it an 'API SKU slug' while the description says 'API slug' – a minor terminology drift, but no added syntax or format detail. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('the full definition of one API by API slug') and enumerates the returned payload: normalized input/output JSON schemas, per-request and per-1,000-request USD pricing, and latency percentiles. This clearly separates it from siblings like list_apis, search_apis, run_api, and quote_api, which an agent can distinguish without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'one API by API slug' scoping implies lookup-by-identifier usage, but the description never states when to pick this over list_apis, search_apis, or quote_api, nor any prerequisites. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balanceCheck wallet balanceARead-onlyInspect
Get the remaining wallet balance (in USD) for the AnyAPI key supplied as a Bearer token. Requires a valid AnyAPI key.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking. |
Output Schema
| Name | Required | Description |
|---|---|---|
| balanceUsd | Yes | remaining wallet balance for this API key, in USD |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context the annotations don't: the call requires a valid AnyAPI key passed as a Bearer token. It does not explain the odd idempotentHint=false for a read operation, but that is a minor omission.
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, front-loaded with what is returned and followed by the auth prerequisite. Every clause earns its place and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only balance check with an output schema present, the description only needs to say what is returned, in what unit, and what credential is required — all of which it does. Return-value detail is correctly left to the 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% for the single 'context' parameter, so the schema already carries the semantics. The description adds nothing about the parameter, which matches the baseline 3 for high-coverage schemas.
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 ('Get the remaining wallet balance') and even pins the unit (USD) and the account scope (the AnyAPI key supplied as Bearer token). No sibling tool in the list deals with balance, so the agent can distinguish it immediately.
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?
Usage is implied by the purpose (call it when you need to know remaining funds), but there is no explicit when-to-use statement, no mention of when not to call it, and no named alternative. Minimum viable guidance only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_requestCheck a requestARead-onlyInspect
Inspect or resume a durable AnyAPI request by request_id. This reads AnyAPI's stored state and never repeats the paid provider dispatch. While status is queued or running, retryAfterSeconds gives the minimum interval between status checks.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking. | |
| request_id | Yes | durable request identifier returned by run_api |
Output Schema
| Name | Required | Description |
|---|---|---|
| hint | No | optional result caveat. 'large_result:' identifies a large response; fields/max_items/summary reduce response size without changing cost. 'paging_unavailable:' means the source cannot return a nextCursor, so the result may be incomplete and cannot be paged further; requireFields ["nextCursor"] restricts execution to sources that support pagination and may cost more per request. 'malformed_query:' means X interpreted adjacent bare words as ANDed and OR as having higher precedence, so a multi-word alternative is not a phrase; the result reflects that interpretation, and the hint includes a corrected query. 'date_adjusted:' means an input date was outside the platform's accepted range, so execution used the nearest accepted date named in the hint |
| error | No | safe AnyAPI failure code when durable work failed |
| items | Yes | number of result rows returned; an API that returns one record counts it as one row. For per-result APIs the per-item cost is charged against this; for input-priced APIs (perItemUnit != result) the charge is per submitted input, independent of this count |
| output | Yes | normalized output payload |
| source | No | the source that served this request; its id is accepted by 'source' for preference or 'ignoreSources' for exclusion. Absent when no source identity applies |
| status | No | durable request status: queued, running, succeeded, failed, or expired |
| costUsd | Yes | amount charged to the wallet in USD |
| jqError | No | present only when a jq expression failed; output then holds the full unshaped result and this explains why the reshape did not apply |
| provider | Yes | the provider serving the request (AnyAPI) |
| replayed | Yes | true when this response replays an identical earlier call (same API, same input) from the last few minutes instead of running again: nothing new was executed and costUsd restates the original charge, it was NOT charged a second time |
| resultId | No | opaque handle to the full result, cached ~15 min; identifies the paid result available for free reshaping without another execution or charge. Absent when the result was too large to cache |
| requestId | No | durable request identifier for stored status and result retrieval without repeating the paid provider dispatch |
| nextAction | No | stored-request retrieval coordinates and polling interval present while durable work is pending |
| serviceOutcome | No | end-to-end AnyAPI service outcome when known |
| settlementState | No | payment settlement state when known; independent of durable request status |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and non-destructive semantics, but the description adds real value: it guarantees the paid provider dispatch is never repeated, and it documents the retryAfterSeconds polling contract for queued/running states. That is behavioral context beyond 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 tight sentences with the identifier and the no-repeat guarantee front-loaded. No filler, though the polling clause could be slightly more compact.
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?
Output schema exists, so return-value explanation is not required, and the description even names one output field (retryAfterSeconds) as a polling hint. It leaves minor gaps around failure/timeout states but is broadly complete for a read-only status 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 both parameters (request_id, context) are already documented. The description echoes request_id but adds no format, source, or constraint detail beyond what the schema provides; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Inspect or resume a durable AnyAPI request by request_id') and immediately distinguishes itself from run_api by clarifying that it reads stored state rather than dispatching to the provider. An agent can tell it apart from read_result and 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?
Gives a clear usage context (inspect or resume, and polling behavior while queued/running with retryAfterSeconds as the minimum interval). It does not name alternative siblings or state when not to use it, so it falls short of explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_apisBrowse APIsARead-onlyInspect
Browse available AnyAPI APIs as lightweight summaries (id, name, category, USD pricing), optionally filtered by category. Descriptions and schemas are omitted to keep catalog responses small. Each pricing offer carries both maxUsd (billed per request) and maxPer1kUsd (the same price per 1,000 requests).
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking. | |
| category | No | optional category slug to filter by |
Output Schema
| Name | Required | Description |
|---|---|---|
| scrapers | Yes | matching APIs (lightweight summaries: no description or schemas) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive behavior, so the description earns credit for going beyond them: it discloses the deliberate omission of descriptions/schemas to keep responses small, and explains the pricing semantics of maxUsd vs maxPer1kUsd. It does not address pagination or result-size limits for a catalog list, and the idempotentHint=false on a read tool is left unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what it returns, what it deliberately withholds, and how to read the pricing fields. Front-loaded with the core purpose, and every sentence carries information the agent cannot get from the schema or annotations.
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, return-value documentation is not required, yet the description usefully pre-explains the pricing fields, and read-only annotations cover the safety profile. The only meaningful gap is sibling routing between list_apis, search_apis, and get_api, which the agent must infer.
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 the required context parameter and the optional category slug. The description only restates the category filter as optional and adds nothing about slug formatting or valid values, making the baseline 3 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 names a specific verb and resource (browse/list APIs) and defines the exact shape of the result set — lightweight summaries with id, name, category, and USD pricing — which cleanly separates it from get_api (single-API detail) since it states descriptions and schemas are omitted. It does not, however, name or contrast with the search_apis sibling, which is the closest competing tool for discovery.
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?
"optionally filtered by category" is an implied usage hint and gives the agent a sense of when the filter applies, but there is no explicit when-to-use guidance, no statement of when NOT to use it, and no routing to search_apis or get_api as alternatives. Usage must be inferred from the purpose sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_apiQuote a priceARead-onlyInspect
Get the exact input-aware execution price for an API, free and without a key. Nothing is charged or executed. sku_id and input identify the proposed execution; pricing resolves exactly as it does for execution, and input validation can return invalid_input without a charge. Returns maxCostUsd (the ceiling reserved), minCostUsd (the likely charge), and the base/per-item breakdown explaining why they differ. These are USD amounts for this one call, not per-1,000-request catalog comparison rates.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | the exact normalized input payload being priced; the quote resolves pricing the same way execution does | |
| sku_id | Yes | the API SKU slug to price | |
| context | Yes | Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking. |
Output Schema
| Name | Required | Description |
|---|---|---|
| exact | Yes | true when the price is exact (minCostUsd == maxCostUsd): a flat SKU or a sealed page |
| baseUsd | Yes | fixed cost per call in USD, charged regardless of count |
| pricing | Yes | a one-line human explanation of how this call is priced |
| maxCostUsd | Yes | the most this call can charge - the reserve held before running |
| minCostUsd | Yes | the likely charge - the cheapest route serves first |
| perItemUsd | Yes | marginal cost in USD per billable unit (see perItemUnit); 0 for a flat SKU |
| perItemUnit | No | the unit perItemUsd is charged per: 'result' (default) or an input unit like 'username' for input-priced SKUs |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (readOnly, non-destructive); the description adds that quoting is free and keyless, that nothing is executed or charged, that input validation can return invalid_input at no cost, and that maxCostUsd is a reserved ceiling versus minCostUsd the likely charge. That is material behavioral context beyond the structured 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?
Front-loaded with the core promise (exact input-aware price, free, no key) before any detail, and the closing sentence usefully disambiguates the USD units. It is dense with a few overlapping clauses ('Nothing is charged or executed' vs. 'without a charge'), costing a little tightness.
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 and annotations cover safety, yet the description still explains the two headline return fields and why they differ, and flags the invalid_input failure mode. Nothing an agent needs to call this tool correctly appears to be 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. The description nonetheless adds real meaning: sku_id and input together identify the proposed execution and pricing resolves identically to execution, which tells the agent the input must match the payload it intends to run rather than being a loose query.
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 first sentence states a specific verb (get) and resource (execution price for an API) plus key modifiers (input-aware, free, no key). It implicitly separates itself from run_api by stating 'Nothing is charged or executed', so an agent can tell pricing apart from execution without opening 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 makes clear this is a non-charging preview of what execution would cost, which establishes when to reach for it. It does not explicitly name an alternative such as run_api or state an exclusion ('do not use this to actually execute'), so there is clear context but no routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_resultRead a saved resultARead-onlyInspect
Read or reshape a previously paid API result without executing or paying again. result_id identifies the full cached result; fields/max_items/summary/jq control its presentation, including row selection and slicing large fields. Results are cached ~15 min and are private to the authenticated account; an expired id returns result_expired.
| Name | Required | Description | Default |
|---|---|---|---|
| jq | No | optional: a jq expression to reshape the result; its output replaces 'output'. Example: '.data | {title, description, md: .markdown[:3500]}'. Sandboxed 250ms/2MB budget | |
| fields | No | optional: keep only these keys on each result item - each row of the result list, or the data object itself for an API that returns one record (dotted paths like 'author.name' descend into nested objects) | |
| context | Yes | Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking. | |
| summary | No | optional: return only a structural outline (top-level keys, item counts, per-field byte sizes) instead of the full data | |
| max_items | No | optional: cap the number of result items returned; a _truncated note reports how many were withheld. An API that returns one record is not trimmed | |
| result_id | Yes | the resultId returned by a prior run_api call (cached ~15 min) |
Output Schema
| Name | Required | Description |
|---|---|---|
| hint | No | optional result caveat. 'large_result:' identifies a large response; fields/max_items/summary reduce response size without changing cost. 'paging_unavailable:' means the source cannot return a nextCursor, so the result may be incomplete and cannot be paged further; requireFields ["nextCursor"] restricts execution to sources that support pagination and may cost more per request. 'malformed_query:' means X interpreted adjacent bare words as ANDed and OR as having higher precedence, so a multi-word alternative is not a phrase; the result reflects that interpretation, and the hint includes a corrected query. 'date_adjusted:' means an input date was outside the platform's accepted range, so execution used the nearest accepted date named in the hint |
| error | No | safe AnyAPI failure code when durable work failed |
| items | Yes | number of result rows returned; an API that returns one record counts it as one row. For per-result APIs the per-item cost is charged against this; for input-priced APIs (perItemUnit != result) the charge is per submitted input, independent of this count |
| output | Yes | normalized output payload |
| source | No | the source that served this request; its id is accepted by 'source' for preference or 'ignoreSources' for exclusion. Absent when no source identity applies |
| status | No | durable request status: queued, running, succeeded, failed, or expired |
| costUsd | Yes | amount charged to the wallet in USD |
| jqError | No | present only when a jq expression failed; output then holds the full unshaped result and this explains why the reshape did not apply |
| provider | Yes | the provider serving the request (AnyAPI) |
| replayed | Yes | true when this response replays an identical earlier call (same API, same input) from the last few minutes instead of running again: nothing new was executed and costUsd restates the original charge, it was NOT charged a second time |
| resultId | No | opaque handle to the full result, cached ~15 min; identifies the paid result available for free reshaping without another execution or charge. Absent when the result was too large to cache |
| requestId | No | durable request identifier for stored status and result retrieval without repeating the paid provider dispatch |
| nextAction | No | stored-request retrieval coordinates and polling interval present while durable work is pending |
| serviceOutcome | No | end-to-end AnyAPI service outcome when known |
| settlementState | No | payment settlement state when known; independent of durable request status |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint=true, destructiveHint=false) and the description adds behavior they cannot express: results are cached ~15 minutes, they are private to the authenticated account, an expired id yields a specific result_expired error, and no new charge is incurred. The scope limits (fields/max_items/summary/jq) confirm this is a read/reshape, consistent with 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 dense sentences with the core purpose and the no-cost/no-re-execution promise front-loaded, followed by param roles and then caching/privacy/error facts. No filler, no restatement of the title, and every sentence carries distinct information.
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 cache-access tool with an output schema (so return shape need not be described) and full schema coverage on 6 params, the description supplies the remaining necessary context: origin of result_id, cache lifetime, account privacy scoping, and the expiry failure mode. 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?
Schema coverage is 100%, so the baseline is 3; each parameter is already documented in depth, including the jq sandbox budget (250ms/2MB) and the _truncated note for max_items. The description adds only a light framing that these four params 'control presentation, including row selection and slicing large fields', which is a modest but real conceptual addition beyond the per-parameter 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?
States a specific verb and resource ('read or reshape a previously paid API result') plus the defining constraint 'without executing or paying again'. This cleanly separates it from the sibling run_api, which is the tool that actually spends money, so an agent can distinguish the two without opening 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 condition for use is clear: you already hold a previously paid result and want to view or reshape it rather than re-run it. The schema's result_id entry reinforces the 'returned by a prior run_api call' origin. It does not explicitly name run_api as the alternative or state when-not-to-use (e.g. use run_api for a fresh execution), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_bugReport a bugAInspect
Submit a defect report to AnyAPI about wrong, empty, or malformed API data for valid input, misleading or unactionable errors, incorrect prices or schemas, or retries that failed unexpectedly. Free, never charged. summary is required and contains one line; optional request_id identifies the stored request and its upstream error body without requiring the payload in the report.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | No | optional: the sku_id this is about, e.g. 'instagram.reels_search' | |
| contact | No | optional: an email address for a reply; trial keys have no reachable account contact | |
| context | Yes | Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking. | |
| details | No | optional: what you expected, what you got, and anything you already tried | |
| summary | Yes | one line saying what went wrong or what you want to tell us | |
| request_id | No | optional: the requestId or resultId from the run that went wrong. This is the single most useful field: it reaches the stored run, its attempts, and any upstream error body, so you do not need to paste the payload |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | the stored report id for support correspondence |
| received | Yes | true when the report is stored |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-destructive, non-idempotent submission, and the description adds context annotations cannot carry: the report is 'Free, never charged', and request_id reaches the stored run plus upstream error body so the payload need not be pasted. It does not mention that repeat submissions create separate tickets or who can see the report, so it is good but not exhaustive.
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-loaded with the qualifying-defect list before the field guidance, and no filler. The long enumeration is justified by its routing value, though it makes the first sentence heavy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and 100% parameter description coverage, the description need not explain returns; it supplies the qualifying conditions and the highest-value field guidance (request_id). Only the free-of-charge and data-minimization notes plus the bug-vs-feedback boundary are left thin.
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 restates that summary is required and one line, and that request_id links to the stored request without needing the payload — accurate and slightly clarifying, but largely duplicating the schema's own request_id 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?
States a concrete verb+resource (submit a defect report to AnyAPI) and then enumerates the exact scope of defects that qualify: wrong/empty/malformed data for valid input, misleading errors, incorrect prices or schemas, unexpected retry failures. That enumeration implicitly separates it from the sibling send_feedback, so an agent can route without opening 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 defect taxonomy is effectively a 'when to use' list, which is strong guidance. It never names an alternative (e.g. send_feedback for non-defect commentary) or states when not to file, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_apiRun an APIADestructiveInspect
Execute an API by API slug with a normalized input payload. Every input schema is strict: unknown fields are rejected, not ignored, and field names can differ between related APIs. Inputs must conform to the endpoint's schema, not its description. Published latency p50/p95/p99 and sample counts describe observed successful requests; p99 is an observation, not a maximum or a client timeout guarantee. Requires a valid AnyAPI key as a Bearer token. Charges the USD wallet. Some failed wallet-funded requests incur processing charges passed through at cost, with no markup; the error message shows the amount charged. Results can be large. fields keeps selected keys, max_items caps returned rows, and summary returns an outline; these controls reduce response size without changing the charge.
| Name | Required | Description | Default |
|---|---|---|---|
| jq | No | optional: a jq expression to reshape the result; its output replaces 'output' (multiple outputs collect into an array). Example: '.data | {title, description, md: .markdown[:3500]}'. Sandboxed 250ms/2MB budget; on failure the full result is returned with jqError. Does not change cost | |
| input | Yes | normalized input payload matching the API input schema | |
| fields | No | optional: keep only these keys on each result item - each row of the result list, or the data object itself for an API that returns one record (dotted paths like 'author.name' descend into nested objects). Shrinks the response without changing cost | |
| sku_id | Yes | the API SKU slug to execute | |
| context | Yes | Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking. | |
| summary | No | optional: return only a structural outline (top-level keys, item counts, and per-field byte sizes) instead of the full data. Does not change cost | |
| max_items | No | optional: cap the number of result items returned; a _truncated note reports how many were withheld. An API that returns one record is not trimmed. Does not change cost |
Output Schema
| Name | Required | Description |
|---|---|---|
| hint | No | optional result caveat. 'large_result:' identifies a large response; fields/max_items/summary reduce response size without changing cost. 'paging_unavailable:' means the source cannot return a nextCursor, so the result may be incomplete and cannot be paged further; requireFields ["nextCursor"] restricts execution to sources that support pagination and may cost more per request. 'malformed_query:' means X interpreted adjacent bare words as ANDed and OR as having higher precedence, so a multi-word alternative is not a phrase; the result reflects that interpretation, and the hint includes a corrected query. 'date_adjusted:' means an input date was outside the platform's accepted range, so execution used the nearest accepted date named in the hint |
| error | No | safe AnyAPI failure code when durable work failed |
| items | Yes | number of result rows returned; an API that returns one record counts it as one row. For per-result APIs the per-item cost is charged against this; for input-priced APIs (perItemUnit != result) the charge is per submitted input, independent of this count |
| output | Yes | normalized output payload |
| source | No | the source that served this request; its id is accepted by 'source' for preference or 'ignoreSources' for exclusion. Absent when no source identity applies |
| status | No | durable request status: queued, running, succeeded, failed, or expired |
| costUsd | Yes | amount charged to the wallet in USD |
| jqError | No | present only when a jq expression failed; output then holds the full unshaped result and this explains why the reshape did not apply |
| provider | Yes | the provider serving the request (AnyAPI) |
| replayed | Yes | true when this response replays an identical earlier call (same API, same input) from the last few minutes instead of running again: nothing new was executed and costUsd restates the original charge, it was NOT charged a second time |
| resultId | No | opaque handle to the full result, cached ~15 min; identifies the paid result available for free reshaping without another execution or charge. Absent when the result was too large to cache |
| requestId | No | durable request identifier for stored status and result retrieval without repeating the paid provider dispatch |
| nextAction | No | stored-request retrieval coordinates and polling interval present while durable work is pending |
| serviceOutcome | No | end-to-end AnyAPI service outcome when known |
| settlementState | No | payment settlement state when known; independent of durable request status |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far beyond the annotations, it discloses that the call charges the USD wallet, that some failed wallet-funded requests still incur passed-through processing charges with the amount shown in the error, that results can be large, and that p99 is an observation rather than a timeout guarantee. These are exactly the behaviors an agent cannot infer from destructiveHint/openWorldHint 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?
Front-loaded with the core action, then cost/auth, then response-size controls. Dense but each sentence carries information; the p50/p95/p99 sentence is the longest and least immediately actionable, but still earns its place given the pricing model.
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 paid, non-idempotent, potentially destructive open-world call, it covers authentication, cost, failure-charge semantics, and response-size mitigation, and an output schema already exists for return values. Nothing an agent needs before invoking 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 baseline is 3, but the description adds cross-cutting meaning the schema lacks: fields, max_items, and summary shrink the response without changing the charge, which is the key decision criterion for using them. It omits jq's sandbox budget the schema already documents, so it is additive rather than exhaustive.
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 ('Execute') and resource ('an API by API slug') plus the payload shape, so the agent knows exactly what happens. It is distinguishable from siblings like get_api or list_apis in spirit, but never names quote_api, which is the closest alternative for the same resource, so differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives real preconditions: a valid AnyAPI key as Bearer token, inputs must match the endpoint's schema (not its description), and unknown fields are rejected. However it never says when to pick this over quote_api, nor warns that a paid, destructive call should be preceded by a cost check, so routing 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.
search_apisSearch APIsARead-onlyInspect
Search APIs by meaning and keyword across name, slug, and description, returning matches with their descriptions but without schemas, ranked most relevant first. At least one of query, category, or platform is required, in any combination; category or platform without query enumerates that scope. limit caps matches (default 25, maximum 50). Each result carries a relevance score in (0,1] relative to the top match; a relevance floor drops weak matches, so total counts relevant matches before the limit. ranking identifies meaning-based ('semantic') or substring ('keyword') matching. Entries with heavy:true produce large API responses. Search results omit input schemas; API inputs require the endpoint's strict schema, whose field names can differ between related APIs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | optional cap on matches returned (default 25, maximum 50) | |
| query | No | free-text search over API name, slug, and description; optional when category or platform is given | |
| context | Yes | Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking. | |
| category | No | optional category slug to narrow the search | |
| platform | No | optional API slug prefix to narrow the search |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| ranking | Yes | |
| results | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile; the description adds substantial behavioral context beyond them: results omit input schemas, relevance is relative to the top match with a hidden floor, total counts relevant matches before the limit, ranking indicates the matching mode, and heavy:true entries produce large responses. This is exactly the extra disclosure the lower annotation bar rewards.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: purpose first, then input rules, then return semantics and caveats. Every sentence carries information, though the schema-omission and strict-schema caveats could be tightened slightly.
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 an output schema and rich annotations, the description covers everything an agent needs: required inputs, ranking modes, result-shape caveats (no schemas; strict input schemas on endpoints), and the heavy:true cost signal. Nothing material 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 value beyond per-field schema text: the required one-of relationship among query/category/platform, the semantics of limit (default 25, max 50), and how relevance/total interact. That interaction logic is not fully captured in the individual schema 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?
States a specific verb and resource ('Search APIs by meaning and keyword across name, slug, and description') plus the scope of returned fields. It clearly distinguishes itself from siblings like list_apis or get_api, which retrieve rather than search, and from quote_api/run_api which act on a single 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?
Gives explicit input-combination rules ('at least one of query, category, or platform is required, in any combination') and clarifies that category/platform alone enumerates that scope. It does not explicitly contrast when to prefer this over list_apis, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_feedbackSend feedbackAInspect
Submit non-defect feedback to AnyAPI about an API you could not find in the catalog, a missing result field, confusing documentation or tool descriptions, or an improvement that would make a task easier. Free, never charged. summary is required and contains one line; optional details describes the task or suggestion.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | No | optional: the sku_id this is about, e.g. 'instagram.reels_search' | |
| contact | No | optional: an email address for a reply; trial keys have no reachable account contact | |
| context | Yes | Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking. | |
| details | No | optional: what you expected, what you got, and anything you already tried | |
| summary | Yes | one line saying what went wrong or what you want to tell us | |
| request_id | No | optional: the requestId or resultId from the run that went wrong. This is the single most useful field: it reaches the stored run, its attempts, and any upstream error body, so you do not need to paste the payload |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | the stored report id for support correspondence |
| received | Yes | true when the report is stored |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false with destructiveHint=false, so the agent knows this is a non-destructive write. The description usefully adds 'Free, never charged', which is real cost context not present in the structured fields, but says nothing about submission rate limits, whether feedback is reviewed, or what the agent receives back.
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, front-loaded with purpose and the scope constraint before the parameter note. The short 'Free, never charged' fragment earns its place as cost information, though the sentence could be tightened slightly further.
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 values need not be explained. The description covers purpose, scope, cost, and the two required/optional content fields, leaving only minor gaps such as post-submission handling and any usage limits for a straightforward submission 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 baseline is 3 and the schema already explains every field, including the value of request_id. The description restates that summary is required and one line and that details is optional, adding only marginal meaning beyond the schema's own wording.
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 (submit feedback to AnyAPI) and immediately scopes it as 'non-defect', which separates it from the sibling report_bug. The enumerated cases (API not in catalog, missing result field, confusing docs, improvement) make the intended input content 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?
Gives clear context for when to reach for this tool via four concrete scenarios and the explicit 'non-defect' qualifier that implicitly routes defects to report_bug. It never names the alternative tool outright or states when not to use it, so it stops short of a full when/when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
10 tool updates
- Changed
get_api1 field changed- changed
Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking."
- Changed
get_balance1 field changed- changed
Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking."
- Changed
get_request1 field changed- changed
Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking."
- Changed
list_apis1 field changed- changed
Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking."
- Changed
quote_api1 field changed- changed
Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking."
- Changed
read_result1 field changed- changed
Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking."
- Changed
report_bug1 field changed- changed
Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking."
- Changed
run_api1 field changed- changed
Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking."
- Changed
search_apis1 field changed- changed
Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking."
- Changed
send_feedback1 field changed- changed
Input schema / properties / context / descriptionPrevious value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Brief purpose of this tool call within the requested task, used for analytics and user-intent tracking."
6 tool updates
- Changed
get_request7 fields changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time. 'date_adjusted:' means a date you sent was outside the range the platform accepts, so the run used the nearest accepted date the hint names"New value: +"optional result caveat. 'large_result:' identifies a large response; fields/max_items/summary reduce response size without changing cost. 'paging_unavailable:' means the source cannot return a nextCursor, so the result may be incomplete and cannot be paged further; requireFields [\"nextCursor\"] restricts execution to sources that support pagination and may cost more per request. 'malformed_query:' means X interpreted adjacent bare words as ANDed and OR as having higher precedence, so a multi-word alternative is not a phrase; the result reflects that interpretation, and the hint includes a corrected query. 'date_adjusted:' means an input date was outside the platform's accepted range, so execution used the nearest accepted date named in the hint" - changed
Output schema / properties / nextAction / descriptionPrevious value: -"machine-actionable resume instruction present while durable work is pending"New value: +"stored-request retrieval coordinates and polling interval present while durable work is pending" - changed
Output schema / properties / nextAction / properties / requestId / descriptionPrevious value: -"request_id argument for the next tool call"New value: +"durable request identifier for stored-request retrieval" - changed
Output schema / properties / nextAction / properties / tool / descriptionPrevious value: -"MCP tool to call next"New value: +"MCP tool name for stored-request retrieval" - changed
Output schema / properties / requestId / descriptionPrevious value: -"durable request identifier; pass it to get_request to resume without repeating the paid POST"New value: +"durable request identifier for stored status and result retrieval without repeating the paid provider dispatch" - changed
Output schema / properties / resultId / descriptionPrevious value: -"opaque handle to the full result, cached ~15 min; pass it to read_result to dig deeper for free (no re-run, no charge). Absent when the result was too large to cache"New value: +"opaque handle to the full result, cached ~15 min; identifies the paid result available for free reshaping without another execution or charge. Absent when the result was too large to cache" - changed
Output schema / properties / source / descriptionPrevious value: -"the source that served this run: pass its id back in 'source' to prefer it again, or in 'ignoreSources' to avoid it. Absent when no source identity applies"New value: +"the source that served this request; its id is accepted by 'source' for preference or 'ignoreSources' for exclusion. Absent when no source identity applies"
- Changed
quote_api1 field changed- changed
Input schema / properties / input / descriptionPrevious value: -"the exact input payload you plan to pass to run_api; the quote resolves pricing the same way the run will"New value: +"the exact normalized input payload being priced; the quote resolves pricing the same way execution does"
- Changed
read_result7 fields changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time. 'date_adjusted:' means a date you sent was outside the range the platform accepts, so the run used the nearest accepted date the hint names"New value: +"optional result caveat. 'large_result:' identifies a large response; fields/max_items/summary reduce response size without changing cost. 'paging_unavailable:' means the source cannot return a nextCursor, so the result may be incomplete and cannot be paged further; requireFields [\"nextCursor\"] restricts execution to sources that support pagination and may cost more per request. 'malformed_query:' means X interpreted adjacent bare words as ANDed and OR as having higher precedence, so a multi-word alternative is not a phrase; the result reflects that interpretation, and the hint includes a corrected query. 'date_adjusted:' means an input date was outside the platform's accepted range, so execution used the nearest accepted date named in the hint" - changed
Output schema / properties / nextAction / descriptionPrevious value: -"machine-actionable resume instruction present while durable work is pending"New value: +"stored-request retrieval coordinates and polling interval present while durable work is pending" - changed
Output schema / properties / nextAction / properties / requestId / descriptionPrevious value: -"request_id argument for the next tool call"New value: +"durable request identifier for stored-request retrieval" - changed
Output schema / properties / nextAction / properties / tool / descriptionPrevious value: -"MCP tool to call next"New value: +"MCP tool name for stored-request retrieval" - changed
Output schema / properties / requestId / descriptionPrevious value: -"durable request identifier; pass it to get_request to resume without repeating the paid POST"New value: +"durable request identifier for stored status and result retrieval without repeating the paid provider dispatch" - changed
Output schema / properties / resultId / descriptionPrevious value: -"opaque handle to the full result, cached ~15 min; pass it to read_result to dig deeper for free (no re-run, no charge). Absent when the result was too large to cache"New value: +"opaque handle to the full result, cached ~15 min; identifies the paid result available for free reshaping without another execution or charge. Absent when the result was too large to cache" - changed
Output schema / properties / source / descriptionPrevious value: -"the source that served this run: pass its id back in 'source' to prefer it again, or in 'ignoreSources' to avoid it. Absent when no source identity applies"New value: +"the source that served this request; its id is accepted by 'source' for preference or 'ignoreSources' for exclusion. Absent when no source identity applies"
- Changed
report_bug2 fields changed- changed
Input schema / properties / contact / descriptionPrevious value: -"optional: an email address to reply to. Supply one if you are on a trial key, since a trial has no account we can reach"New value: +"optional: an email address for a reply; trial keys have no reachable account contact" - changed
Output schema / properties / id / descriptionPrevious value: -"the stored report id; quote it if you contact support about this"New value: +"the stored report id for support correspondence"
- Changed
run_api7 fields changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time. 'date_adjusted:' means a date you sent was outside the range the platform accepts, so the run used the nearest accepted date the hint names"New value: +"optional result caveat. 'large_result:' identifies a large response; fields/max_items/summary reduce response size without changing cost. 'paging_unavailable:' means the source cannot return a nextCursor, so the result may be incomplete and cannot be paged further; requireFields [\"nextCursor\"] restricts execution to sources that support pagination and may cost more per request. 'malformed_query:' means X interpreted adjacent bare words as ANDed and OR as having higher precedence, so a multi-word alternative is not a phrase; the result reflects that interpretation, and the hint includes a corrected query. 'date_adjusted:' means an input date was outside the platform's accepted range, so execution used the nearest accepted date named in the hint" - changed
Output schema / properties / nextAction / descriptionPrevious value: -"machine-actionable resume instruction present while durable work is pending"New value: +"stored-request retrieval coordinates and polling interval present while durable work is pending" - changed
Output schema / properties / nextAction / properties / requestId / descriptionPrevious value: -"request_id argument for the next tool call"New value: +"durable request identifier for stored-request retrieval" - changed
Output schema / properties / nextAction / properties / tool / descriptionPrevious value: -"MCP tool to call next"New value: +"MCP tool name for stored-request retrieval" - changed
Output schema / properties / requestId / descriptionPrevious value: -"durable request identifier; pass it to get_request to resume without repeating the paid POST"New value: +"durable request identifier for stored status and result retrieval without repeating the paid provider dispatch" - changed
Output schema / properties / resultId / descriptionPrevious value: -"opaque handle to the full result, cached ~15 min; pass it to read_result to dig deeper for free (no re-run, no charge). Absent when the result was too large to cache"New value: +"opaque handle to the full result, cached ~15 min; identifies the paid result available for free reshaping without another execution or charge. Absent when the result was too large to cache" - changed
Output schema / properties / source / descriptionPrevious value: -"the source that served this run: pass its id back in 'source' to prefer it again, or in 'ignoreSources' to avoid it. Absent when no source identity applies"New value: +"the source that served this request; its id is accepted by 'source' for preference or 'ignoreSources' for exclusion. Absent when no source identity applies"
- Changed
send_feedback2 fields changed- changed
Input schema / properties / contact / descriptionPrevious value: -"optional: an email address to reply to. Supply one if you are on a trial key, since a trial has no account we can reach"New value: +"optional: an email address for a reply; trial keys have no reachable account contact" - changed
Output schema / properties / id / descriptionPrevious value: -"the stored report id; quote it if you contact support about this"New value: +"the stored report id for support correspondence"
3 tool updates
- Changed
get_request1 field changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time"New value: +"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time. 'date_adjusted:' means a date you sent was outside the range the platform accepts, so the run used the nearest accepted date the hint names"
- Changed
read_result1 field changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time"New value: +"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time. 'date_adjusted:' means a date you sent was outside the range the platform accepts, so the run used the nearest accepted date the hint names"
- Changed
run_api1 field changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time"New value: +"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time. 'date_adjusted:' means a date you sent was outside the range the platform accepts, so the run used the nearest accepted date the hint names"
3 tool updates
- Changed
get_request1 field changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list"New value: +"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time"
- Changed
read_result1 field changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list"New value: +"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time"
- Changed
run_api1 field changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list"New value: +"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list. 'malformed_query:' means X read your search query differently than it looks (adjacent bare words are ANDed and OR binds tighter, so a multi-word alternative is not a phrase); this result is what X returned for it, and the hint carries the corrected query to send next time"
1 tool update
- Changed
get_api1 field changed- added
Output schema / properties / scraper / properties / lanes / items / properties / health / properties / blockedPctAdded value: +{ + "type": [ + "null", + "number" + ] +}
3 tool updates
- Changed
get_request1 field changed- changed
Output schema / properties / items / descriptionPrevious value: -"number of result rows returned. For per-result SKUs the per-item cost is charged against this; for input-priced SKUs (perItemUnit != result) the charge is per submitted input, independent of this count"New value: +"number of result rows returned; an API that returns one record counts it as one row. For per-result APIs the per-item cost is charged against this; for input-priced APIs (perItemUnit != result) the charge is per submitted input, independent of this count"
- Changed
read_result3 fields changed- changed
Input schema / properties / fields / descriptionPrevious value: -"optional: keep only these keys on each result item (dotted paths like 'author.name' descend into nested objects)"New value: +"optional: keep only these keys on each result item - each row of the result list, or the data object itself for an API that returns one record (dotted paths like 'author.name' descend into nested objects)" - changed
Input schema / properties / max_items / descriptionPrevious value: -"optional: cap the number of result items returned; a _truncated note reports how many were withheld"New value: +"optional: cap the number of result items returned; a _truncated note reports how many were withheld. An API that returns one record is not trimmed" - changed
Output schema / properties / items / descriptionPrevious value: -"number of result rows returned. For per-result SKUs the per-item cost is charged against this; for input-priced SKUs (perItemUnit != result) the charge is per submitted input, independent of this count"New value: +"number of result rows returned; an API that returns one record counts it as one row. For per-result APIs the per-item cost is charged against this; for input-priced APIs (perItemUnit != result) the charge is per submitted input, independent of this count"
- Changed
run_api3 fields changed- changed
Input schema / properties / fields / descriptionPrevious value: -"optional: keep only these keys on each result item (dotted paths like 'author.name' descend into nested objects). Shrinks the response without changing cost"New value: +"optional: keep only these keys on each result item - each row of the result list, or the data object itself for an API that returns one record (dotted paths like 'author.name' descend into nested objects). Shrinks the response without changing cost" - changed
Input schema / properties / max_items / descriptionPrevious value: -"optional: cap the number of result items returned; a _truncated note reports how many were withheld. Does not change cost"New value: +"optional: cap the number of result items returned; a _truncated note reports how many were withheld. An API that returns one record is not trimmed. Does not change cost" - changed
Output schema / properties / items / descriptionPrevious value: -"number of result rows returned. For per-result SKUs the per-item cost is charged against this; for input-priced SKUs (perItemUnit != result) the charge is per submitted input, independent of this count"New value: +"number of result rows returned; an API that returns one record counts it as one row. For per-result APIs the per-item cost is charged against this; for input-priced APIs (perItemUnit != result) the charge is per submitted input, independent of this count"
3 tool updates
- Changed
get_request1 field changed- added
Output schema / properties / sourceAdded value: +{ + "additionalProperties": false, + "description": "the source that served this run: pass its id back in 'source' to prefer it again, or in 'ignoreSources' to avoid it. Absent when no source identity applies", + "properties": { + "artworkKey": { + "type": "string" + }, + "id": { + "type": "string" + }, + "kind": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "kind", + "artworkKey" + ], + "type": [ + "null", + "object" + ] +}
- Changed
read_result1 field changed- added
Output schema / properties / sourceAdded value: +{ + "additionalProperties": false, + "description": "the source that served this run: pass its id back in 'source' to prefer it again, or in 'ignoreSources' to avoid it. Absent when no source identity applies", + "properties": { + "artworkKey": { + "type": "string" + }, + "id": { + "type": "string" + }, + "kind": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "kind", + "artworkKey" + ], + "type": [ + "null", + "object" + ] +}
- Changed
run_api1 field changed- added
Output schema / properties / sourceAdded value: +{ + "additionalProperties": false, + "description": "the source that served this run: pass its id back in 'source' to prefer it again, or in 'ignoreSources' to avoid it. Absent when no source identity applies", + "properties": { + "artworkKey": { + "type": "string" + }, + "id": { + "type": "string" + }, + "kind": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "kind", + "artworkKey" + ], + "type": [ + "null", + "object" + ] +}
1 tool update
- Changed
get_api1 field changed- added
Output schema / properties / scraper / properties / lanes / items / properties / fieldsAdded value: +{ + "items": { + "type": "string" + }, + "type": [ + "null", + "array" + ] +}
3 tool updates
- Changed
get_api2 fields changed- added
Output schema / properties / scraper / properties / lanes / items / properties / pricing / properties / addonsAdded value: +{ + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "id": { + "type": "string" + }, + "label": { + "type": "string" + }, + "usd": { + "type": "number" + } + }, + "required": [ + "id", + "label", + "field", + "usd" + ], + "type": "object" + }, + "type": [ + "null", + "array" + ] +} - added
Output schema / properties / scraper / properties / pricing / properties / from / properties / addonsAdded value: +{ + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "id": { + "type": "string" + }, + "label": { + "type": "string" + }, + "usd": { + "type": "number" + } + }, + "required": [ + "id", + "label", + "field", + "usd" + ], + "type": "object" + }, + "type": [ + "null", + "array" + ] +}
- Changed
list_apis1 field changed- added
Output schema / properties / scrapers / items / properties / pricing / properties / from / properties / addonsAdded value: +{ + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "id": { + "type": "string" + }, + "label": { + "type": "string" + }, + "usd": { + "type": "number" + } + }, + "required": [ + "id", + "label", + "field", + "usd" + ], + "type": "object" + }, + "type": [ + "null", + "array" + ] +}
- Changed
search_apis1 field changed- added
Output schema / properties / results / items / properties / pricing / properties / from / properties / addonsAdded value: +{ + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "id": { + "type": "string" + }, + "label": { + "type": "string" + }, + "usd": { + "type": "number" + } + }, + "required": [ + "id", + "label", + "field", + "usd" + ], + "type": "object" + }, + "type": [ + "null", + "array" + ] +}
3 tool updates
- Changed
get_request1 field changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireCursor true (may cost more per request) if you need the full list"New value: +"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list"
- Changed
read_result1 field changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireCursor true (may cost more per request) if you need the full list"New value: +"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list"
- Changed
run_api1 field changed- changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireCursor true (may cost more per request) if you need the full list"New value: +"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireFields [\"nextCursor\"] (may cost more per request) if you need the full list"
1 tool update
- Changed
search_apis2 fields changed- changed
Input schema / properties / query / descriptionPrevious value: -"free-text search over API name, slug, and description"New value: +"free-text search over API name, slug, and description; optional when category or platform is given" - changed
Input schema / requiredPrevious value: -[ - "query", - "context" -]New value: +[ + "context" +]
10 tool updates
- Changed
get_api22 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / contextAdded value: +{ + "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "sku_id" -]New value: +[ + "sku_id", + "context" +] - removed
Output schema / properties / scraper / properties / baseUsdRemoved value: -{ - "description": "fixed cost per request in USD, charged regardless of count", - "type": "number" -} - added
Output schema / properties / scraper / properties / excludesCallerDelayAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / scraper / properties / executionAdded value: +{ + "additionalProperties": false, + "properties": { + "mode": { + "type": "string" + } + }, + "required": [ + "mode" + ], + "type": "object" +} - added
Output schema / properties / scraper / properties / failoverAdded value: +{ + "type": "boolean" +} - removed
Output schema / properties / scraper / properties / heavy / descriptionRemoved value: -"true when this API's responses are typically large; pass fields, max_items, or summary to run_api (and a small limit in the input) to keep the result out of your context" - changed
Output schema / properties / scraper / properties / inputSchemaPrevious value: -{ - "description": "normalized input JSON Schema" -}New value: +true - added
Output schema / properties / scraper / properties / lanesAdded value: +{ + "items": { + "additionalProperties": false, + "properties": { + "health": { + "additionalProperties": false, + "properties": { + "latencyP50Ms": { + "type": "integer" + }, + "latencySample": { + "type": "integer" + }, + "requests": { + "type": "integer" + }, + "servedRequests": { + "type": "integer" + }, + "uptimePct": { + "type": "number" + }, + "uptimeSample": { + "type": "integer" + }, + "window": { + "type": "string" + } + }, + "required": [ + "window", + "uptimePct", + "latencyP50Ms", + "uptimeSample", + "latencySample", + "requests", + "servedRequests" + ], + "type": [ + "null", + "object" + ] + }, + "pricing": { + "additionalProperties": false, + "properties": { + "baseUsd": { + "type": [ + "null", + "number" + ] + }, + "maxPer1kUsd": { + "type": "number" + }, + "maxUsd": { + "type": "number" + }, + "model": { + "type": "string" + }, + "perUnitUsd": { + "type": [ + "null", + "number" + ] + }, + "unit": { + "type": "string" + } + }, + "required": [ + "model", + "unit", + "maxUsd", + "maxPer1kUsd" + ], + "type": "object" + }, + "source": { + "additionalProperties": false, + "properties": { + "artworkKey": { + "type": "string" + }, + "id": { + "type": "string" + }, + "kind": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "kind", + "artworkKey" + ], + "type": "object" + } + }, + "required": [ + "pricing", + "source" + ], + "type": "object" + }, + "type": [ + "null", + "array" + ] +} - added
Output schema / properties / scraper / properties / latencyAdded value: +{ + "additionalProperties": false, + "properties": { + "basis": { + "type": "string" + }, + "p50Ms": { + "type": "integer" + }, + "p95Ms": { + "type": "integer" + }, + "p99Ms": { + "type": "integer" + }, + "sample": { + "type": "integer" + }, + "window": { + "type": "string" + } + }, + "required": [ + "window", + "p50Ms", + "p95Ms", + "p99Ms", + "sample", + "basis" + ], + "type": [ + "null", + "object" + ] +} - added
Output schema / properties / scraper / properties / methodAdded value: +{ + "type": "string" +} - changed
Output schema / properties / scraper / properties / outputSchemaPrevious value: -{ - "description": "normalized output JSON Schema" -}New value: +true - added
Output schema / properties / scraper / properties / pathAdded value: +{ + "type": "string" +} - removed
Output schema / properties / scraper / properties / perItemUnitRemoved value: -{ - "description": "the unit perItemUsd is charged per: 'result' (default) or an input unit like 'username' for input-priced SKUs", - "type": "string" -} - removed
Output schema / properties / scraper / properties / perItemUsdRemoved value: -{ - "description": "marginal cost in USD per billable unit (see perItemUnit); total = baseUsd + perItemUsd × unitCount, capped at priceUsd", - "type": "number" -} - removed
Output schema / properties / scraper / properties / priceUsdRemoved value: -{ - "description": "maximum price per request in USD (the reserved ceiling at the default limit)", - "type": "number" -} - added
Output schema / properties / scraper / properties / pricingAdded value: +{ + "additionalProperties": false, + "properties": { + "failoverMaxPer1kUsd": { + "type": "number" + }, + "failoverMaxUsd": { + "type": "number" + }, + "from": { + "additionalProperties": false, + "properties": { + "baseUsd": { + "type": [ + "null", + "number" + ] + }, + "maxPer1kUsd": { + "type": "number" + }, + "maxUsd": { + "type": "number" + }, + "model": { + "type": "string" + }, + "perUnitUsd": { + "type": [ + "null", + "number" + ] + }, + "unit": { + "type": "string" + } + }, + "required": [ + "model", + "unit", + "maxUsd", + "maxPer1kUsd" + ], + "type": "object" + } + }, + "required": [ + "from", + "failoverMaxUsd", + "failoverMaxPer1kUsd" + ], + "type": "object" +} - added
Output schema / properties / scraper / properties / providerAdded value: +{ + "type": "string" +} - added
Output schema / properties / scraper / properties / tryEligibleAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / scraper / properties / tryMaxItemsAdded value: +{ + "type": [ + "null", + "integer" + ] +} - changed
Output schema / properties / scraper / requiredPrevious value: -[ - "id", - "slug", - "category", - "name", - "description", - "priceUsd", - "baseUsd", - "perItemUsd" -]New value: +[ + "id", + "slug", + "category", + "name", + "method", + "path", + "provider", + "execution", + "pricing", + "failover", + "description", + "lanes", + "latency", + "tryEligible" +]
- Changed
get_balance3 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / propertiesAdded value: +{ + "context": { + "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"", + "type": "string" + } +} - added
Input schema / requiredAdded value: +[ + "context" +]
- Added
get_request - Changed
list_apis17 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / contextAdded value: +{ + "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"", + "type": "string" +} - removed
Input schema / properties / queryRemoved value: -{ - "description": "optional free-text filter over API name and description", - "type": "string" -} - added
Input schema / requiredAdded value: +[ + "context" +] - removed
Output schema / properties / scrapers / items / properties / baseUsdRemoved value: -{ - "description": "fixed cost per request in USD, charged regardless of count", - "type": "number" -} - added
Output schema / properties / scrapers / items / properties / excludesCallerDelayAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / scrapers / items / properties / executionAdded value: +{ + "additionalProperties": false, + "properties": { + "mode": { + "type": "string" + } + }, + "required": [ + "mode" + ], + "type": "object" +} - added
Output schema / properties / scrapers / items / properties / failoverAdded value: +{ + "type": "boolean" +} - removed
Output schema / properties / scrapers / items / properties / heavy / descriptionRemoved value: -"true when this API's responses are typically large; pass fields, max_items, or summary to run_api (and a small limit in the input) to keep the result out of your context" - added
Output schema / properties / scrapers / items / properties / methodAdded value: +{ + "type": "string" +} - added
Output schema / properties / scrapers / items / properties / pathAdded value: +{ + "type": "string" +} - removed
Output schema / properties / scrapers / items / properties / perItemUnitRemoved value: -{ - "description": "the unit perItemUsd is charged per: 'result' (default) or an input unit like 'username' for input-priced SKUs", - "type": "string" -} - removed
Output schema / properties / scrapers / items / properties / perItemUsdRemoved value: -{ - "description": "marginal cost in USD per billable unit (see perItemUnit); total = baseUsd + perItemUsd × unitCount, capped at priceUsd", - "type": "number" -} - removed
Output schema / properties / scrapers / items / properties / priceUsdRemoved value: -{ - "description": "maximum price per request in USD (the reserved ceiling at the default limit)", - "type": "number" -} - added
Output schema / properties / scrapers / items / properties / pricingAdded value: +{ + "additionalProperties": false, + "properties": { + "failoverMaxPer1kUsd": { + "type": "number" + }, + "failoverMaxUsd": { + "type": "number" + }, + "from": { + "additionalProperties": false, + "properties": { + "baseUsd": { + "type": [ + "null", + "number" + ] + }, + "maxPer1kUsd": { + "type": "number" + }, + "maxUsd": { + "type": "number" + }, + "model": { + "type": "string" + }, + "perUnitUsd": { + "type": [ + "null", + "number" + ] + }, + "unit": { + "type": "string" + } + }, + "required": [ + "model", + "unit", + "maxUsd", + "maxPer1kUsd" + ], + "type": "object" + } + }, + "required": [ + "from", + "failoverMaxUsd", + "failoverMaxPer1kUsd" + ], + "type": "object" +} - added
Output schema / properties / scrapers / items / properties / providerAdded value: +{ + "type": "string" +} - changed
Output schema / properties / scrapers / items / requiredPrevious value: -[ - "id", - "slug", - "category", - "name", - "priceUsd", - "baseUsd", - "perItemUsd" -]New value: +[ + "id", + "slug", + "category", + "name", + "method", + "path", + "provider", + "execution", + "pricing", + "failover" +]
- Changed
quote_api3 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / contextAdded value: +{ + "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "sku_id", - "input" -]New value: +[ + "sku_id", + "input", + "context" +]
- Changed
read_result12 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / contextAdded value: +{ + "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "result_id" -]New value: +[ + "result_id", + "context" +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": false, + "description": "safe AnyAPI failure code when durable work failed", + "properties": { + "code": { + "description": "safe AnyAPI error code", + "type": "string" + } + }, + "required": [ + "code" + ], + "type": [ + "null", + "object" + ] +} - changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge, present only on large untrimmed results, suggesting fields/max_items/summary to keep future responses out of your context"New value: +"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireCursor true (may cost more per request) if you need the full list" - added
Output schema / properties / nextActionAdded value: +{ + "additionalProperties": false, + "description": "machine-actionable resume instruction present while durable work is pending", + "properties": { + "requestId": { + "description": "request_id argument for the next tool call", + "type": "string" + }, + "retryAfterSeconds": { + "description": "minimum delay before polling again", + "type": "integer" + }, + "tool": { + "description": "MCP tool to call next", + "type": "string" + } + }, + "required": [ + "tool", + "requestId", + "retryAfterSeconds" + ], + "type": [ + "null", + "object" + ] +} - added
Output schema / properties / replayedAdded value: +{ + "description": "true when this response replays an identical earlier call (same API, same input) from the last few minutes instead of running again: nothing new was executed and costUsd restates the original charge, it was NOT charged a second time", + "type": "boolean" +} - added
Output schema / properties / requestIdAdded value: +{ + "description": "durable request identifier; pass it to get_request to resume without repeating the paid POST", + "type": "string" +} - added
Output schema / properties / serviceOutcomeAdded value: +{ + "description": "end-to-end AnyAPI service outcome when known", + "type": "string" +} - added
Output schema / properties / settlementStateAdded value: +{ + "description": "payment settlement state when known; independent of durable request status", + "type": "string" +} - added
Output schema / properties / statusAdded value: +{ + "description": "durable request status: queued, running, succeeded, failed, or expired", + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "output", - "provider", - "costUsd", - "items" -]New value: +[ + "output", + "provider", + "costUsd", + "items", + "replayed" +]
- Added
report_bug - Changed
run_api12 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / contextAdded value: +{ + "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "sku_id", - "input" -]New value: +[ + "sku_id", + "input", + "context" +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": false, + "description": "safe AnyAPI failure code when durable work failed", + "properties": { + "code": { + "description": "safe AnyAPI error code", + "type": "string" + } + }, + "required": [ + "code" + ], + "type": [ + "null", + "object" + ] +} - changed
Output schema / properties / hint / descriptionPrevious value: -"optional nudge, present only on large untrimmed results, suggesting fields/max_items/summary to keep future responses out of your context"New value: +"optional nudge. 'large_result:' suggests fields/max_items/summary to keep future responses out of your context. 'paging_unavailable:' means this result came from a source that cannot return a nextCursor, so it may be INCOMPLETE and you cannot page further - re-run with requireCursor true (may cost more per request) if you need the full list" - added
Output schema / properties / nextActionAdded value: +{ + "additionalProperties": false, + "description": "machine-actionable resume instruction present while durable work is pending", + "properties": { + "requestId": { + "description": "request_id argument for the next tool call", + "type": "string" + }, + "retryAfterSeconds": { + "description": "minimum delay before polling again", + "type": "integer" + }, + "tool": { + "description": "MCP tool to call next", + "type": "string" + } + }, + "required": [ + "tool", + "requestId", + "retryAfterSeconds" + ], + "type": [ + "null", + "object" + ] +} - added
Output schema / properties / replayedAdded value: +{ + "description": "true when this response replays an identical earlier call (same API, same input) from the last few minutes instead of running again: nothing new was executed and costUsd restates the original charge, it was NOT charged a second time", + "type": "boolean" +} - added
Output schema / properties / requestIdAdded value: +{ + "description": "durable request identifier; pass it to get_request to resume without repeating the paid POST", + "type": "string" +} - added
Output schema / properties / serviceOutcomeAdded value: +{ + "description": "end-to-end AnyAPI service outcome when known", + "type": "string" +} - added
Output schema / properties / settlementStateAdded value: +{ + "description": "payment settlement state when known; independent of durable request status", + "type": "string" +} - added
Output schema / properties / statusAdded value: +{ + "description": "durable request status: queued, running, succeeded, failed, or expired", + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "output", - "provider", - "costUsd", - "items" -]New value: +[ + "output", + "provider", + "costUsd", + "items", + "replayed" +]
- Changed
search_apis24 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / contextAdded value: +{ + "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"", + "type": "string" +} - changed
Input schema / properties / limit / descriptionPrevious value: -"optional cap on matches returned (default 25); 'total' reports how many relevant matches there were before the cap"New value: +"optional cap on matches returned (default 25, maximum 50)" - added
Input schema / properties / platformAdded value: +{ + "description": "optional API slug prefix to narrow the search", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "query" -]New value: +[ + "query", + "context" +] - removed
Output schema / properties / ranking / descriptionRemoved value: -"'semantic' when meaning-based ranking served this search, 'keyword' when it fell back to substring matching (relevance is coarser)" - removed
Output schema / properties / results / descriptionRemoved value: -"matching APIs with descriptions (schemas omitted), most relevant first" - removed
Output schema / properties / results / items / properties / baseUsdRemoved value: -{ - "description": "fixed cost per request in USD, charged regardless of count", - "type": "number" -} - added
Output schema / properties / results / items / properties / excludesCallerDelayAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / results / items / properties / executionAdded value: +{ + "additionalProperties": false, + "properties": { + "mode": { + "type": "string" + } + }, + "required": [ + "mode" + ], + "type": "object" +} - added
Output schema / properties / results / items / properties / failoverAdded value: +{ + "type": "boolean" +} - removed
Output schema / properties / results / items / properties / heavy / descriptionRemoved value: -"true when this API's responses are typically large; pass fields, max_items, or summary to run_api (and a small limit in the input) to keep the result out of your context" - removed
Output schema / properties / results / items / properties / inputSchemaRemoved value: -{ - "description": "normalized input JSON Schema" -} - added
Output schema / properties / results / items / properties / methodAdded value: +{ + "type": "string" +} - removed
Output schema / properties / results / items / properties / outputSchemaRemoved value: -{ - "description": "normalized output JSON Schema" -} - added
Output schema / properties / results / items / properties / pathAdded value: +{ + "type": "string" +} - removed
Output schema / properties / results / items / properties / perItemUnitRemoved value: -{ - "description": "the unit perItemUsd is charged per: 'result' (default) or an input unit like 'username' for input-priced SKUs", - "type": "string" -} - removed
Output schema / properties / results / items / properties / perItemUsdRemoved value: -{ - "description": "marginal cost in USD per billable unit (see perItemUnit); total = baseUsd + perItemUsd × unitCount, capped at priceUsd", - "type": "number" -} - removed
Output schema / properties / results / items / properties / priceUsdRemoved value: -{ - "description": "maximum price per request in USD (the reserved ceiling at the default limit)", - "type": "number" -} - added
Output schema / properties / results / items / properties / pricingAdded value: +{ + "additionalProperties": false, + "properties": { + "failoverMaxPer1kUsd": { + "type": "number" + }, + "failoverMaxUsd": { + "type": "number" + }, + "from": { + "additionalProperties": false, + "properties": { + "baseUsd": { + "type": [ + "null", + "number" + ] + }, + "maxPer1kUsd": { + "type": "number" + }, + "maxUsd": { + "type": "number" + }, + "model": { + "type": "string" + }, + "perUnitUsd": { + "type": [ + "null", + "number" + ] + }, + "unit": { + "type": "string" + } + }, + "required": [ + "model", + "unit", + "maxUsd", + "maxPer1kUsd" + ], + "type": "object" + } + }, + "required": [ + "from", + "failoverMaxUsd", + "failoverMaxPer1kUsd" + ], + "type": "object" +} - added
Output schema / properties / results / items / properties / providerAdded value: +{ + "type": "string" +} - changed
Output schema / properties / results / items / properties / relevance / descriptionPrevious value: -"relative relevance in (0,1], 1.0 = the best match in this response; comparable only within this response"New value: +"relative relevance in (0,1], 1.0 = the best match" - changed
Output schema / properties / results / items / requiredPrevious value: -[ - "id", - "slug", - "category", - "name", - "description", - "priceUsd", - "baseUsd", - "perItemUsd", - "relevance" -]New value: +[ + "id", + "slug", + "category", + "name", + "description", + "method", + "path", + "provider", + "execution", + "pricing", + "failover", + "relevance" +] - removed
Output schema / properties / total / descriptionRemoved value: -"number of relevant matches (after the relevance floor), before the limit cap - if this is large, narrow your query"
- Added
send_feedback
4 tool updates
- Changed
get_api1 field changed- added
Output schema / properties / scraper / properties / heavyAdded value: +{ + "description": "true when this API's responses are typically large; pass fields, max_items, or summary to run_api (and a small limit in the input) to keep the result out of your context", + "type": "boolean" +}
- Changed
list_apis1 field changed- added
Output schema / properties / scrapers / items / properties / heavyAdded value: +{ + "description": "true when this API's responses are typically large; pass fields, max_items, or summary to run_api (and a small limit in the input) to keep the result out of your context", + "type": "boolean" +}
- Added
quote_api - Changed
search_apis8 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"optional cap on matches returned (default 25); 'total' reports how many matched before the cap"New value: +"optional cap on matches returned (default 25); 'total' reports how many relevant matches there were before the cap" - added
Output schema / properties / rankingAdded value: +{ + "description": "'semantic' when meaning-based ranking served this search, 'keyword' when it fell back to substring matching (relevance is coarser)", + "type": "string" +} - changed
Output schema / properties / results / descriptionPrevious value: -"matching APIs with descriptions (schemas omitted)"New value: +"matching APIs with descriptions (schemas omitted), most relevant first" - added
Output schema / properties / results / items / properties / heavyAdded value: +{ + "description": "true when this API's responses are typically large; pass fields, max_items, or summary to run_api (and a small limit in the input) to keep the result out of your context", + "type": "boolean" +} - added
Output schema / properties / results / items / properties / relevanceAdded value: +{ + "description": "relative relevance in (0,1], 1.0 = the best match in this response; comparable only within this response", + "type": "number" +} - changed
Output schema / properties / results / items / requiredPrevious value: -[ - "id", - "slug", - "category", - "name", - "description", - "priceUsd", - "baseUsd", - "perItemUsd" -]New value: +[ + "id", + "slug", + "category", + "name", + "description", + "priceUsd", + "baseUsd", + "perItemUsd", + "relevance" +] - changed
Output schema / properties / total / descriptionPrevious value: -"number of APIs that matched before the limit was applied"New value: +"number of relevant matches (after the relevance floor), before the limit cap - if this is large, narrow your query" - changed
Output schema / requiredPrevious value: -[ - "results", - "total" -]New value: +[ + "results", + "total", + "ranking" +]
2 tool updates
- Added
read_result - Changed
run_api4 fields changed- added
Input schema / properties / jqAdded value: +{ + "description": "optional: a jq expression to reshape the result; its output replaces 'output' (multiple outputs collect into an array). Example: '.data | {title, description, md: .markdown[:3500]}'. Sandboxed 250ms/2MB budget; on failure the full result is returned with jqError. Does not change cost", + "type": "string" +} - changed
Input schema / properties / summary / descriptionPrevious value: -"optional: return only a structural outline (top-level keys and item counts) instead of the full data. Does not change cost"New value: +"optional: return only a structural outline (top-level keys, item counts, and per-field byte sizes) instead of the full data. Does not change cost" - added
Output schema / properties / jqErrorAdded value: +{ + "description": "present only when a jq expression failed; output then holds the full unshaped result and this explains why the reshape did not apply", + "type": "string" +} - added
Output schema / properties / resultIdAdded value: +{ + "description": "opaque handle to the full result, cached ~15 min; pass it to read_result to dig deeper for free (no re-run, no charge). Absent when the result was too large to cache", + "type": "string" +}
2 tool updates
- Changed
list_apis5 fields changed- changed
Output schema / properties / scrapers / descriptionPrevious value: -"matching APIs"New value: +"matching APIs (lightweight summaries: no description or schemas)" - removed
Output schema / properties / scrapers / items / properties / descriptionRemoved value: -{ - "type": "string" -} - removed
Output schema / properties / scrapers / items / properties / inputSchemaRemoved value: -{ - "description": "normalized input JSON Schema" -} - removed
Output schema / properties / scrapers / items / properties / outputSchemaRemoved value: -{ - "description": "normalized output JSON Schema" -} - changed
Output schema / properties / scrapers / items / requiredPrevious value: -[ - "id", - "slug", - "category", - "name", - "description", - "priceUsd", - "baseUsd", - "perItemUsd" -]New value: +[ + "id", + "slug", + "category", + "name", + "priceUsd", + "baseUsd", + "perItemUsd" +]
- Added
search_apis
4 tool updates
- First observed
get_api - First observed
get_balance - First observed
list_apis - First observed
run_api
Related MCP Servers
- AlicenseNot gradedqualityBmaintenancePerplexity for social: ask what competitors are running across social and get answers grounded in real ad and creative data, not guesses.2Apache 2.0
- AlicenseCqualityBmaintenanceCompetitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs119 npmMIT
- AlicenseAqualityCmaintenanceEnables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.164 npm1MIT

industrylens-mcpofficial
AlicenseNot gradedqualityBmaintenanceBrowse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.