One key to 1,000+ paid data APIs: enrichment, SEO/SERP, scraping, places, news. Pay per call.
Scored across 7 tools
Each tool occupies a distinct slot in the search→inspect→run→monitor workflow: search finds endpoints, inspect reads a contract, run executes, runs_get/runs_list/runs_stop manage runs, and balance checks funds. There is no plausible confusion between any pair — even run vs runs_get is clearly split between 'create a run' and 'read one run'.
The run-management family follows a clean noun_verb pattern (runs_get, runs_list, runs_stop), but the remaining tools are bare verbs/nouns (balance, inspect, run, search) with no prefix, so 'run' sits awkwardly next to 'runs_*' where 'runs_create' would be expected. The convention is readable and mostly predictable, just not uniform.
Seven tools is well-scoped for an endpoint-marketplace proxy: discovery, contract inspection, execution, run lifecycle (get/list/stop), and balance accounting. Every tool earns its place with no redundancy or bloat.
The core paid-execution lifecycle is fully covered: search, inspect, run, get/list/stop runs, and balance — with idempotency, async status, and charging semantics all addressed. Minor gaps exist around task/work management (task_id is threaded through tools but there is no explicit tool to list or inspect tasks) and no endpoint browsing beyond keyword search.
The workspace's balance in USD: balance, held (reserved by in-flight runs), available. Also the cheapest probe that the key works. Docs: https://glasser.ai/docs/api-reference/balance/get
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds value by describing the held amount as reserved by in-flight runs (explains why the number may differ from expectations) and by noting this is a cheap probe, implying low cost/no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence plus a docs link. The core purpose leads, the field breakdown and probe hint follow, and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param read tool with no output schema, the description usefully explains the return shape (balance/held/available) and points to docs. Annotations cover the safety profile, so little is missing; only pagination-style or error semantics would add more, and they are largely irrelevant here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; there is nothing for the description to compensate for. The return-field enumeration is not a parameter concern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (the workspace's USD balance) and enumerates the returned fields (balance, held, available), which is more than a tautology. It does not distinguish itself from siblings, but they are clearly unrelated operations (run, search, runs_*), so the purpose is 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?
"Also the cheapest probe that the key works" gives an explicit alternate use case (auth/key verification), which is real guidance beyond the primary read. It does not name a specific alternative tool or state when-not-to-use, keeping it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one endpoint's execution contract: provider-native input schema, exact price with every charge clause, current endpoint_version, run mode and timeout. Always inspect before the first run of an endpoint, and pass the endpoint_version you saw to run. Selecting an endpoint_version does not lock Price; new Runs use the current Price at admission. Pass the task_id from your search so this inspection is recorded against the same piece of work. Docs: https://glasser.ai/docs/api-reference/endpoints/inspect
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | No | ||
| endpoint | Yes | ||
| provider | Yes | ||
| endpoint_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuinely non-obvious behavior: selecting a version does not lock Price, and new Runs are admitted at the current Price. It omits auth requirements and any rate-limit or result-caching behavior, but the pricing/version decoupling is valuable context beyond structured data.
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 what the tool returns, then workflow guidance, then the docs link. Every sentence carries information, though it is fairly dense and the pricing caveat 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?
With no output schema, the description still tells the agent what the response contains (schema, price clauses, endpoint_version, run mode, timeout) and how to use it downstream. Combined with the read-only annotations, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains the workflow role of task_id (link the inspection to the same piece of work) and endpoint_version (what to pass on to run), but provider and endpoint receive no clarification beyond their regex patterns, leaving half the parameters unexplained.
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 ('one endpoint's execution contract') and enumerates exactly what comes back: input schema, price with charge clauses, endpoint_version, run mode and timeout. It is clearly distinguishable from siblings like run, search, and runs_get without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition ('Always inspect before the first run of an endpoint'), tells the agent what to do with the result ('pass the endpoint_version you saw to run'), and explains how to correlate with the search step via task_id. When-to-use and the handoff to run are both spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute one endpoint and charge the workspace per its published price. Build input against the inspected input_schema. Generate a UUID for idempotency_key and reuse the SAME key to retry — it never charges twice; the result carries replayed:true on a replay. A provider 404/500 is a COMPLETED run carrying that outcome in provider_response, not an error. A QUEUED/RUNNING result means an async endpoint is still working — poll runs_get. The user's own keys and integrations outrank Glasser; never run speculatively, in loops or in bulk without naming the price and getting the user's go-ahead. The result's run_url opens the run's records in the workspace console, exactly as the provider returned them (members only); when your answer relies on the run, cite run_url as its source — the run id alone opens nothing. Docs: https://glasser.ai/docs/api-reference/runs/create
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | Provider-native input. Build it from the input_schema returned by Inspect. | |
| task_id | No | ||
| endpoint | Yes | ||
| provider | Yes | ||
| idempotency_key | Yes | ||
| endpoint_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations, which only flag mutating/idempotent/open-world. The description discloses billing behavior (charge per published price), idempotency mechanics (generate a UUID, reuse the SAME key, never double-charges, replayed:true), error semantics (provider 404/500 is a COMPLETED run in provider_response, not an error), and async state (QUEUED/RUNNING means poll runs_get).
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?
Long but densely packed: it leads with the action and price consequence, then layers idempotency, error handling, async polling, safety gating, and citation guidance. Nearly every sentence carries operational information, though the volume is on the heavier side for a single tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 6 parameters, the description compensates by describing the salient return fields (provider_response, replayed:true, QUEUED/RUNNING, run_url) and the run_url citation convention. Nothing essential for correct invocation or interpretation 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 only 17%, so the description carries most of the burden: it explains how to construct input (from an inspected input_schema) and the idempotency_key generation/reuse rule, which the bare minLength:1 schema does not convey. It does not elaborate on the provider/endpoint string formats beyond their regex patterns, leaving a small gap.
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+resource: "Execute one endpoint and charge the workspace per its published price." This clearly separates run from siblings inspect (schema discovery), runs_get (polling), runs_list and runs_stop, so an agent can route without opening another 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?
Explicit routing and gating: build input from the inspected input_schema, poll runs_get when a result is QUEUED/RUNNING, and never run speculatively, in loops or in bulk without naming the price and getting user go-ahead. It names the alternative tool and the conditions that select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one run by run_id: status, output, provider_response, failure, charge_usd, charge_basis, run_url. Status and charge are independent — a FAILED run can carry a non-zero charge. The result's run_url opens the run's records in the workspace console, exactly as the provider returned them (members only); when your answer relies on the run, cite run_url as its source — the run id alone opens nothing. Docs: https://glasser.ai/docs/api-reference/runs/get
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered; the description goes further by disclosing domain behavior the annotations cannot: status and charge are independent (a FAILED run can carry a non-zero charge), run_url resolves to provider-returned records in the workspace console, access is 'members only', and citation of run_url is required because the run id alone opens nothing. That is substantive added context on auth and result semantics.
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 and returned fields, followed by the two non-obvious behavioral facts (failed-but-charged, cite run_url), then a docs link. Dense and every clause carries information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of enumerating return fields and does so explicitly. Combined with the read-only annotations, an agent has everything needed to call this correctly and interpret the result, including the citation requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema gives only the type/format (uuid pattern) without prose. The description partially compensates by naming the parameter's role ('by run_id') and clarifying that the id alone opens nothing, but it never explains where a run_id comes from or its expected form. Marginal value over the structured fields.
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 one run by run_id') and enumerates exactly what comes back (status, output, provider_response, failure, charge_usd, charge_basis, run_url), which is enough to distinguish it from runs_list (plural/summary) and runs_stop (mutating). An agent can identify the tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: fetch a single run when you already hold a run_id ('Get one run by run_id'). There is no explicit routing guidance telling the agent to use runs_list or search first to obtain a run_id, and no when-not condition. Adequate but inferential rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this workspace's runs, newest first; filter by status, provider, endpoint, or task (exact match — use a task_id from a search to see every run of one piece of work). Cursor-paginated. Rows are summaries: input and output read {"omitted": true}; runs_get returns the full run. Docs: https://glasser.ai/docs/api-reference/runs/list
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | ||
| limit | No | Page size, from 1 to 100. Default: 20. | |
| cursor | No | ||
| status | No | ||
| endpoint | No | ||
| provider | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: newest-first ordering, cursor pagination, and the fact that list rows omit input/output as {"omitted": true}. It stops short of rate limits or error behavior, but the added context is substantial.
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: the core operation and ordering come first, then filters, then pagination and the row-shape caveat with the escape hatch to runs_get. No filler, and every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly spends its budget explaining the return shape (summary rows with omitted input/output) and the pagination contract, plus a docs link. A 6-param, zero-required list tool is adequately covered, though the unannotated endpoint/provider filters remain under-explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, so the description must carry more weight. It does add value for `task` (exact match, and where to get a task_id) and for cursor pagination, but `endpoint` and `provider` are only named as filter dimensions with no semantics, and `limit`/`cursor` are already documented in the schema. Partial compensation, not full.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List this workspace's runs'), plus scope ('this workspace's'), ordering ('newest first'), and pagination model. It explicitly differentiates from the sibling runs_get ('runs_get returns the full run'), so an agent can choose between them 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?
Gives concrete filter dimensions (status, provider, endpoint, task) and directs the agent to runs_get when full input/output is needed, and to a prior search to obtain a task_id. No explicit when-not guidance beyond the runs_get handoff, but the routing context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a stop for an in-flight run. Before dispatch the run becomes STOPPED and free; once dispatched it settles normally and is charged — paid-for work is never discarded. Docs: https://glasser.ai/docs/api-reference/runs/stop
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior, but the description adds crucial context: pre-dispatch runs become STOPPED and free, while dispatched runs settle normally and are charged. The guarantee that 'paid-for work is never discarded' is exactly the kind of behavioral nuance an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three terse, information-dense sentences: the action, the critical lifecycle nuance, and a documentation link. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter action with annotations covering safety and idempotency, the description covers the lifecycle and billing implications well. It does not describe the response or error cases, but no output schema exists and the operation is simple, so this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention run_id at all. The parameter name and schema format/pattern are helpful, but the description provides no additional meaning and fails to compensate for the complete lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Request a stop') and the resource ('an in-flight run'), making it distinct from sibling tools like runs_get and runs_list. The scope is precise without ambiguity.
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 provides clear context on when to use the tool: for in-flight runs before dispatch, and explains behavioral differences after dispatch. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Glasser's data sources — runnable paid API endpoints — by keyword. Returns ranked endpoint summaries — provider, endpoint, price, run mode, and a score — already filtered to what this key may run. Several providers may sell the same capability: compare price and pick; the ranking is relevance-only. Pages are 5 by default (limit up to 20); read total for how many candidates exist and pass next_cursor back as cursor for more. The score is a cosine similarity for comparing rows, not a verdict: the ranking returns its nearest candidates, so neither low scores nor the last page shows that a capability is absent. Try other words, and inspect before running. Returns a task_id: pass it back on every later search, inspect and run for the same piece of work, and send use_case on every search (required) so the task records what the user is trying to achieve. Docs: https://glasser.ai/docs/api-reference/endpoints/search
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| cursor | No | ||
| task_id | No | ||
| use_case | Yes | Required on every search. The use case behind this search: what the user asked for, in their own words, with the subject in it — the company, domain, ticker, place or topic. Shorten a long request rather than rewriting it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnly/openWorld/destructive hints already covering safety, the description adds genuinely new behavior: paging defaults and cap, the `total` counter, cursor reuse and its 400 error, task_id threading, and an explicit caveat that low scores or the last page do NOT prove a capability is absent. That last point is exactly the interpretive context an agent cannot get from 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?
Front-loaded purpose, then paging, then ranking caveat, then task_id contract — a sensible order, and the docs link is placed last where it belongs. It is dense and slightly overpacked with clauses, but almost 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?
No output schema exists, yet the description still describes the return shape (provider, endpoint, price, run mode, score, total, next_cursor, task_id), the paging model, the ranking semantics, and the cross-call task contract. Nothing an agent needs to call this and interpret the results 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?
At 20% schema coverage the description has to carry weight, and it does: it explains limit/paging defaults, next_cursor reuse, the task_id threading contract across search/inspect/run, and why use_case is mandatory. Query semantics ('Try other words') are only implied rather than spelled out, which keeps this short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search Glasser's data sources — runnable paid API endpoints — by keyword') and immediately scopes the result set to what the key may run. It is clearly distinguishable from siblings like inspect and run, which it positions as later workflow steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives real operating guidance: 'compare price and pick', 'Try other words, and inspect before running', and the requirement to send use_case on every search. It names the sibling (inspect) that follows, though it never states an explicit when-not-to-use or names a competing search alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
inspect1 field changedInput schema / properties / endpoint_version / anyOfPrevious value: -[
- {
- "description": "Select a supported Endpoint version, or omit for the default. Returns the current Price for that version; selecting a version does not lock its Price.",
- "exclusiveMinimum": 0,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Select a supported Endpoint version, including an older one, or omit for the default. Unavailable or retired versions return 409.",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]run2 fields changedInput schema / properties / endpoint_version / anyOfPrevious value: -[
- {
- "description": "Select a supported Endpoint version. Compatible updates keep this version; it does not lock the Price. New Runs use the Price at admission. Omit to use the default version. Unavailable or retired versions return 409.",
- "exclusiveMinimum": 0,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Select a supported version, or omit for the default. Compatible updates keep the version; unavailable or retired versions return 409. A version does not lock Price: new Runs use the Price at admission, and accepted Runs keep it through settlement.",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / input / descriptionAdded value: +"Provider-native input. Build it from the input_schema returned by Inspect."runs_list2 fields changedInput schema / properties / cursor / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Pass next_cursor from the previous response to read the next page.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / limit / descriptionAdded value: +"Page size, from 1 to 100. Default: 20."search3 fields changedInput schema / properties / cursor / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "The next_cursor from the previous response. Use the same query; a cursor from a different query returns 400.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / limit / anyOfPrevious value: -[
- {
- "maximum": 20,
- "minimum": 1,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Maximum results per page. Default: 5; maximum: 20.",
+ "maximum": 20,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / query / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Keywords that describe the data you need. Omit or leave empty to browse all Endpoints allowed by your Key's Policy.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]balance1 field changedInput schema / anyOfRemoved value: -[
- {
- "type": "object"
- },
- {
- "type": "array"
- }
-]search2 fields changedInput schema / properties / use_case / minLengthAdded value: +1Input schema / properties / use_case / patternRemoved value: -"\\S"search5 fields changedInput schema / properties / use_case / anyOfRemoved value: -[
- {
- "description": "The use case behind this search: what the user asked for, in their own words, with the subject in it — the company, domain, ticker, place or topic. Shorten a long request rather than rewriting it.",
- "type": "string"
- },
- {
- "type": "null"
- }
-]Input schema / properties / use_case / descriptionAdded value: +"Required on every search. The use case behind this search: what the user asked for, in their own words, with the subject in it — the company, domain, ticker, place or topic. Shorten a long request rather than rewriting it."Input schema / properties / use_case / patternAdded value: +"\\S"Input schema / properties / use_case / typeAdded value: +"string"Input schema / requiredAdded value: +[
+ "use_case"
+]inspect1 field changedInput schema / properties / task_id / anyOfPrevious value: -[
- {
- "description": "The task this call belongs to. Omit on the first search of a piece of work and one is minted and returned; pass it back on every later search, inspect and run so they are recorded as one task. Any stable string is accepted.",
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "The task this inspection belongs to, from a catalog search response. Any stable string is accepted.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]search2 fields changedInput schema / properties / task_id / anyOfPrevious value: -[
- {
- "description": "The task this call belongs to. Omit on the first search of a piece of work and one is minted and returned; pass it back on every later search, inspect and run so they are recorded as one task. Any stable string is accepted.",
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "The task this search belongs to. A search without a task_id starts a new task. The response returns its task_id. Send it on every later search, inspect and run of the same piece of work. Any stable string is accepted.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / use_case / anyOfPrevious value: -[
- {
- "description": "The use case behind this search: what the user asked for, in their own words, with the subject in it — the company, domain, ticker, place or topic. Shorten a long request rather than rewriting it. Leave out personal details about third parties.",
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "The use case behind this search: what the user asked for, in their own words, with the subject in it — the company, domain, ticker, place or topic. Shorten a long request rather than rewriting it.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]search2 fields changedInput schema / properties / use_caseAdded value: +{
+ "anyOf": [
+ {
+ "description": "The use case behind this search: what the user asked for, in their own words, with the subject in it — the company, domain, ticker, place or topic. Shorten a long request rather than rewriting it. Leave out personal details about third parties.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Input schema / properties / user_requestRemoved value: -{
- "anyOf": [
- {
- "description": "What the user asked for, in their own words, with the subject in it — the company, domain, ticker, place or topic. Shorten a long request rather than rewriting it. Leave out personal details about third parties. Recorded against the task as background; it does not affect results.",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
-}search1 field changedInput schema / properties / user_request / anyOfPrevious value: -[
- {
- "description": "One sentence, in your own words, on what the user is trying to achieve. Never their verbatim words, and never names, email addresses or other personal details. Recorded against the task as background; it does not affect results.",
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "What the user asked for, in their own words, with the subject in it — the company, domain, ticker, place or topic. Shorten a long request rather than rewriting it. Leave out personal details about third parties. Recorded against the task as background; it does not affect results.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]inspect1 field changedInput schema / properties / task_idAdded value: +{
+ "anyOf": [
+ {
+ "description": "The task this call belongs to. Omit on the first search of a piece of work and one is minted and returned; pass it back on every later search, inspect and run so they are recorded as one task. Any stable string is accepted.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}run1 field changedInput schema / properties / task_idAdded value: +{
+ "anyOf": [
+ {
+ "description": "The task this run belongs to, from a catalog search response. Grouping only: it never affects routing, price or idempotency.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}runs_list1 field changedInput schema / properties / taskAdded value: +{
+ "anyOf": [
+ {
+ "description": "Return only runs recorded against this task. Exact match.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}search2 fields changedInput schema / properties / task_idAdded value: +{
+ "anyOf": [
+ {
+ "description": "The task this call belongs to. Omit on the first search of a piece of work and one is minted and returned; pass it back on every later search, inspect and run so they are recorded as one task. Any stable string is accepted.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Input schema / properties / user_requestAdded value: +{
+ "anyOf": [
+ {
+ "description": "One sentence, in your own words, on what the user is trying to achieve. Never their verbatim words, and never names, email addresses or other personal details. Recorded against the task as background; it does not affect results.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}balanceinspectrunruns_getruns_listruns_stopsearchHundreds of scraping & data APIs through one key. USD pay-per-request, normalized schemas, failover.
One key and one balance for 2,500+ data APIs from 90+ providers. Your AI agent pays per call.
One key for 4,000+ tools: web search, scraping, people and company data, SEO, calls and email.
140+ data APIs for agents: finance, banking validation, geo, weather, text. One API key.
Add one secure layer between your agents and this server.
