Deterministic AI agent microtools, no accounts/API keys. fetch_extract: 98% token cut. 47 tools.
Scored across 17 tools
The fetch/extraction family (fetch_extract, fetch_html, fetch_metadata, html_to_markdown) covers related URL-to-content workflows; descriptions distinguish output types, but an agent may still deliberate between clean text vs Markdown. The query, paid image/SEO, and meta tools are mostly distinct, and use_tool is explicitly limited to tools not in tools/list.
All names use snake_case, but the pattern mixes verb_noun (fetch_extract, remove_background, use_tool) with noun_verb (csv_query, rss_parse, screenshot_url) and noun-only (pricing). It remains readable, but there is no single predictable convention throughout.
17 tools is slightly above the typical 3-15 sweet spot, but the server spans several families (fetch/extract, data query, paid media/SEO, discovery). Most tools earn their place; the meta/discovery tools add some overhead but support navigation of the set.
The surface covers core read-only extraction and query workflows plus paid utilities and a catalog escape hatch via use_tool. The main gaps are documented limitations (no JS rendering, no OCR, no table-preserving PDF extraction) rather than missing core lifecycle operations.
Query a CSV: select/filter/sort/limit. One of url or csv.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | No | Raw CSV (alt. to url). | |
| url | No | CSV URL (alt. to csv). | |
| limit | No | Default 500, max 5000. | |
| filter | No | 'col op value'. | |
| format | No | Default json. | |
| select | No | Columns, comma-separated. | |
| headers | No | Headers to forward (Authorization, Cookie…). | |
| sort_by | No | Sort column. | |
| sort_dir | No | Default asc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read behavior is covered. The description adds the useful constraint that exactly one of url/csv should be supplied, but it does not describe return shape, pagination behavior, or authentication beyond what the schema already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste; the core operations and source-input constraint are front-loaded. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With nine parameters, 100% schema description coverage, and no output schema, the definition is nearly self-sufficient: the schema handles parameter semantics while the description covers purpose and input sourcing. It would be stronger if it clarified query output or filter operators, but those are largely covered elsewhere.
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 every parameter already has documented meaning and defaults. The description adds the mutual-exclusivity note for url/csv, which is helpful beyond the schema, but it does not enrich the semantics of the remaining query parameters.
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 gives a specific verb ('Query') and resource ('CSV'), and enumerates the core operations select/filter/sort/limit. It does not explicitly differentiate from the sibling json_query, so it stops short of a 5.
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 specifies a key usage constraint ('One of url or csv'), which tells the agent how to provide input. However, it gives no guidance on when to choose csv_query over json_query or other query tools, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL, return clean text. Free. Median 98% fewer tokens than raw HTML. Not for JS SPAs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL. | |
| headers | No | Headers to forward (Authorization, Cookie…). | |
| maxChars | No | Default 8000, max 32000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares the safety profile, and the description adds useful context beyond it: free of cost, token-efficient output, and a hard limitation on JS-rendered pages. It doesn't disclose truncation behavior (what happens past maxChars) or whether failures return partial content, which matters for a fetching tool.
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?
Four terse fragments, front-loaded with the action and result, then cost, then the disqualifying condition. Every clause carries information 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 fetch with fully documented parameters and no output schema, the description covers purpose, cost, and the primary failure mode. The remaining gap is what truncation looks like when maxChars is hit, which no other field explains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with url, headers, and maxChars default/max all documented inline. The description adds no parameter-level detail beyond what the schema provides, so the 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 ('Fetch a URL, return clean text') and adds the output characteristic (clean text rather than raw HTML). It gestures at sibling differentiation with 'Not for JS SPAs', implying fetch_html, but never names the alternative, so an agent must infer the mapping from the sibling list.
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?
'Not for JS SPAs' is a genuine exclusion criterion that tells the agent when this tool will fail. However, it doesn't name the sibling to use instead (fetch_html, screenshot_url) nor mention redirects, auth, or paywalled pages, so the guidance is clear but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, read-only. Fetch a page and return its HTML minus scripts, styles, svg, iframes, comments and inline handlers; tags and attributes stay, so structure is readable. For inspecting or rebuilding markup, not plain text (fetch_extract gives that). Runs no JavaScript: SPAs return an empty shell. Cut at maxChars with a marker.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | http(s) page URL. Private addresses are refused. | |
| headers | No | Headers to forward (Authorization, Cookie…). | |
| maxChars | No | Output cap, chars. Default 16000, max 64000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint; the description carries the real behavioral burden: sanitization of scripts/styles/handlers, absence of JS execution with the SPA consequence, and truncation behavior at maxChars with a marker. These are non-obvious traits an agent needs before calling.
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?
Four dense sentences, each loading information: safety/scope first, then the fetch_extract contrast, then the JS limitation, then truncation. No filler or restatement of the title.
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 characterizes the return value precisely (tag/attribute-preserving HTML with listed elements stripped, truncated with a marker). For a 3-parameter tool with a nested headers object, nothing an agent needs to call 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. The description adds beyond the schema by noting that maxChars produces a cut with a visible marker, which tells the agent how truncation manifests in output rather than just that a cap exists.
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?
Specific verb+resource ('fetch a page and return its HTML') plus an explicit statement of what is removed (scripts, styles, svg, iframes, comments, inline handlers) and what is preserved. It also names the sibling it is not (fetch_extract) so an agent can discriminate 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?
Explicitly routes the agent: 'For inspecting or rebuilding markup, not plain text (fetch_extract gives that).' It also gives a negative condition — no JavaScript, so SPAs return an empty shell — which tells the agent when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL, extract title/description/OG/Twitter/canonical/JSON-LD. Not for body text.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL. | |
| headers | No | Headers to forward (Authorization, Cookie…). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true is consistent with a fetch operation, and the description adds useful detail by listing the exact fields returned, effectively sketching the output shape absent an output schema. It says nothing about network behavior an agent would care about: timeouts, redirect handling, non-HTML content, or failure modes on unreachable URLs.
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 the action and extraction list, with the exclusion trailing. No filler whatsoever.
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 two-parameter read tool with full schema coverage and no output schema, listing the extracted fields gives the agent enough to know what comes back. The only real gap is runtime behavior on fetch failures, which is minor at this complexity level.
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 both url and headers are already documented, including the Authorization/Cookie forwarding hint. The description adds no additional parameter semantics, so the 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 (fetch) and resource (a URL) and enumerates exactly what is extracted: title/description/OG/Twitter/canonical/JSON-LD. The trailing 'Not for body text' sets a boundary that separates it from the body-text siblings, though no sibling is named explicitly.
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 negative case is called out directly ('Not for body text'), which is the key routing decision against fetch_extract/fetch_html/html_to_markdown. It stops short of pointing at the correct alternative by name, so the agent must infer which sibling to use for body text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, read-only. Convert a fetched URL or an HTML string you pass (one of the two) to Markdown: headings, links, lists, emphasis, code, quotes. Drops nav, header, footer, aside, script and style. Returns text, cut at maxChars with a marker. Runs no JavaScript: SPAs return an empty shell. Tables become plain text.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page URL to fetch. Not with html. | |
| html | No | HTML text to convert. Not with url. | |
| headers | No | Headers to forward (Authorization, Cookie…). | |
| maxChars | No | Output cap, chars. Default 12000, max 50000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint; the description adds substantial behavior beyond that: which elements are discarded, truncation at maxChars with a visible marker, no JavaScript execution so SPAs return an empty shell, and table flattening. These are exactly the failure modes and output-shape facts an agent needs before calling.
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 zero throat-clearing. Safety and mutuality constraints are front-loaded, then output scope, then limitations – a sensible order for an agent scanning before invocation.
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 converter with no output schema, the description supplies the return type ('text'), the truncation behavior, and the JS limitation that determines whether the tool is even viable for a given page. The empty-shell warning on SPAs is the kind of edge case that otherwise causes silent bad results.
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. The description adds two things beyond the schema: it reiterates the url/html mutual exclusivity as a top-level constraint, and it reveals that maxChars truncation is signaled by an inserted marker, which the schema does not say. It says nothing extra about headers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Convert ... to Markdown') and then enumerates the exact conversion scope: headings, links, lists, emphasis, code, quotes. It distinguishes itself from the sibling fetch tools by framing both a URL-fetch path and a raw-HTML path, and from fetch_extract by naming what gets stripped.
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 clear context for when this applies: post-processing a fetched page or converting a string you already have ('one of the two'). It cues the workflow with 'a fetched URL' and the stripped-element list, but never names fetch_html explicitly as the upstream sibling or states when to prefer it over fetch_extract.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, read-only. JSONPath-lite query on JSON from a URL or an inline string (one of the two). Returns matches as JSON: one match bare, several as an array. Supports $, .key, ['key'], [0], [-1], [*], ..key and [?(@.k op v)]; no slices or jq. Errors on invalid JSON or over 5 MB (json_query_xl: paid, 25 MB).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | JSON URL, max 5 MB. Not with json. | |
| json | No | Inline JSON text. Not with url. | |
| limit | No | Default 100, max 1000. Above it: {results,total,returned}. | |
| query | Yes | Starts with $: '$.users[*].name', '$..price', '$.items[?(@.price<10)].id'. Filter ops: = != > >= < <= =~. '$' = whole document. | |
| headers | No | Headers to forward (Authorization, Cookie…). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, and the description adds real value beyond that: free tier, an explicit 5 MB cap with the failure mode ('errors on invalid JSON or over 5 MB'), and the non-obvious return shape (one match bare, several as an array). Those are exactly the traits an agent cannot infer 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?
All the critical facts come first — free, read-only, source exclusivity, return shape — in one tight paragraph with no filler. The density borders on cryptic in the syntax list, but 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?
There is no output schema, so the description must carry return semantics, and it does partially (match cardinality, error conditions, limit-truncation guidance lives in the schema). A brief note on the error payload shape would close the remaining 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 100%, so the schema already documents every parameter including the filter operators and the limit envelope. The description's main additions are negative constraints ('no slices or jq') and the 5 MB bound, which are useful but largely restate schema-level facts, so the baseline of 3 is right.
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 (JSONPath query over JSON from a URL or inline string) and pins the exact syntax subset supported. It also distinguishes itself from the paid sibling json_query_xl, so an agent can place it 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?
Explicitly notes url and json are mutually exclusive ('one of the two') and names json_query_xl with its 25 MB ceiling as the alternative for larger payloads. It stops short of routing against other siblings (csv_query, fetch_extract), so it is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Ads volume/CPC/competition for 1-20 keywords. $0.04 USDC/call. Paid: calling without a payment payload returns a structured 402 with payment options — that response is the documented behavior, not a failure.
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | 1-20 keywords. | |
| language_code | No | ISO 639-1. | es |
| location_code | No | DataForSEO location (default Spain). | |
| include_suggestions | No | Add related suggestions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint, so the description adds substantial context: cost per call, required payment payload, and the structured 402 response. It prevents the agent from misclassifying a normal payment challenge as an error.
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 compact sentences with the purpose, cost, and payment behavior front-loaded. Every sentence carries operational value 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 tool with no output schema, the description identifies the returned metrics and explains the payment flow, which is the main complexity. It could say more about response shape, but the key behavioral information is present.
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 explains all four parameters. The description reinforces the 1-20 keyword constraint but adds no extra semantics for language_code, location_code, or include_suggestions.
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 the specific data source and metrics (Google Ads volume/CPC/competition) and the exact input scope (1-20 keywords). This is more precise than a generic 'keyword research' label and makes the tool's output obvious.
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 clearly states the paid nature and that a 402 response without a payment payload is expected behavior, which is critical invocation guidance. It does not explicitly compare against sibling tools, but none of the listed siblings are close alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, read-only. Returns static text: a short note on when ToolSnap tools suit a task, plus how to store a note in your runtime's memory. This tool saves nothing. Use only if your user asks about persistent memory or ToolSnap setup; show them the text and save it only with their approval.
| Name | Required | Description | Default |
|---|---|---|---|
| harness | No | Your agent runtime, to tailor the save instruction. Omit for a generic one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with 'Free, read-only' and 'This tool saves nothing.' It also discloses the human-approval requirement before persisting anything, which annotations cannot express.
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: cost/safety first, then what it returns, then usage guidance. Every clause carries a decision-relevant fact, with nothing 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?
With no output schema, the description correctly summarizes the return value ('static text' with a note and save instructions) and covers the side-effect and approval model. Nothing needed 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% and the single 'harness' parameter is fully documented in the schema, including enum values. The description never mentions the harness parameter or why one would omit it, so it adds no meaning beyond the schema. 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: returns static text containing a note on when ToolSnap tools fit and how to save it in the runtime's memory. This is clearly distinguishable from siblings like tool_catalog, use_tool, and task_recipes, which do other things.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('only if your user asks about persistent memory or ToolSnap setup') and adds the operating instructions: show the user the text, save only with approval. No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, read-only. Extract plain text from a PDF given as a URL (max 20 MB) or inline base64 (max 5 MB), one of the two. Returns text, cut at maxChars with a marker. Text-layer PDFs only: scans return little or nothing (no OCR). Layout and tables are not preserved. Fails if the URL serves HTML, not a PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Direct link to the .pdf file, not a viewer page. Not with data. | |
| data | No | Base64 PDF, max 5 MB decoded. Not with url. | |
| headers | No | Headers to forward (Authorization, Cookie…). | |
| maxChars | No | Output cap, chars. Default 20000, max 100000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint; the description adds the constraints that actually shape a call — 20 MB URL / 5 MB base64 caps, mutual exclusivity of the two inputs, truncation at maxChars with a marker, no OCR, no layout/table preservation, and the HTML-mislabeled-URL failure mode.
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?
Four short sentences, front-loaded with safety and scope, then inputs, then return behavior, then failure modes. No filler and nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what the tool returns (text, cut at maxChars with a marker) despite there being no output schema, and documents every behavioral risk of a 4-parameter extraction tool: size ceilings, input exclusivity, missing OCR, and non-preserved layout.
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 already 100%, so the baseline is 3; the description earns extra by adding size limits per input mode and confirming the url/data either-or that the schema only hints at, plus the truncation behavior tied to maxChars.
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 — extract plain text from a PDF — plus the two accepted input forms. The 'PDF' scope cleanly separates it from fetch_html, html_to_markdown and fetch_extract even though no sibling is named.
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?
Makes the applicable domain explicit ('Text-layer PDFs only: scans return little or nothing'), which tells the agent when not to call it, and 'Fails if the URL serves HTML, not a PDF' routes HTML content elsewhere. No sibling is named outright, so the routing is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Machine-readable pricing menu: free vs paid tools, pricing, deposit/spend flow.
| 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 openWorldHint=false, establishing a safe, closed-world read. The description adds useful behavioral context by labeling the tool 'Free' and describing what the pricing menu contains. It stops short of explaining the response structure or any limits, which is a minor gap for a zero-parameter info tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is extremely compact: one short sentence plus the upfront 'Free.' label. Every phrase earns its place by either naming the resource, stating cost behavior, or enumerating the covered pricing topics.
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-parameter, read-only pricing-info tool with no output schema, the description gives enough detail about what the response covers. It does not describe the exact output format beyond 'machine-readable,' but the topic enumeration is sufficient for an agent to decide whether to call it.
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 there is no parameter semantics burden. The baseline for zero-parameter tools is 4, and nothing in the description creates confusion about inputs.
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 identifies the resource as a machine-readable pricing menu and enumerates its scope: free vs paid tools, pricing, and deposit/spend flow. It is specific enough for an agent to know what information the tool provides, though it does not explicitly differentiate itself from sibling utility tools like tool_catalog.
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 content description—an agent should call this when it needs pricing or payment-flow details. However, there is no explicit statement of when to use this versus tool_catalog or another informational sibling, nor any stated preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an image's background, return a transparent PNG URL. $0.03 USDC/call. Paid: calling without a payment payload returns a structured 402 with payment options — that response is the documented behavior, not a failure.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | Public image URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=false, which conveys little about a paid, non-mutating compute call. The description adds the price ($0.03 USDC/call) and pre-empts the most likely failure misread: a 402 without a payment payload is documented behavior, not an error. That is exactly the kind of context annotations cannot carry.
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 short sentences, front-loaded with the capability and result, then cost, then the payment caveat. No filler and nothing repeated 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?
For a one-parameter tool with no output schema, the description covers purpose, return value, cost, and the expected 402 path. An agent has everything needed to call it and interpret both success and the unpaid response.
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?
Single required parameter with 100% schema description coverage ('Public image URL'), so the schema does the work. The description adds only that the output is a transparent PNG URL, not anything about the input beyond what the schema states.
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 ('Remove an image's background') and even the output ('transparent PNG URL'). No sibling tool in the catalog does image manipulation, so the description alone is enough to distinguish it.
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 payment clause effectively tells the agent how to invoke it correctly: without a payment payload you get a 402 rather than a result. There is no explicit when-not guidance or named alternative, but none of the sibling tools overlaps with this capability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch/parse an RSS or Atom feed into JSON. Saves 90%+ tokens vs raw XML.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Feed URL. | |
| maxItems | No | Max 200. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares the safety profile, so the description's burden is lighter. It adds that output is JSON and token-efficient, but says nothing about network failure behavior, redirects, feed validity handling, or truncation semantics when maxItems applies.
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, the core action front-loaded and the token rationale second. Nothing repetitive or 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 two-parameter read tool with readOnlyHint and full schema coverage, most essentials are present. However, with no output schema the description never characterizes the returned JSON (field names, item structure, behavior when the feed is empty or invalid), leaving a real 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 100%, so both parameters (url, maxItems) are already documented, including the 'Max 200' bound. The description adds no syntax or format detail beyond that, making baseline 3 correct.
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 ('Fetch/parse an RSS or Atom feed') plus the output form ('into JSON'). It implicitly distinguishes itself from generic siblings like fetch_extract and fetch_html by naming the feed formats, though it never explicitly says it is the specialized choice.
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 format-specific framing and the 'saves 90%+ tokens vs raw XML' rationale, which hints at when to prefer it. But there is no explicit when-to-use/when-not guidance and no alternative tool named for non-feed content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screenshot a page → public image URL. $0.04/call. Paid: calling without a payment payload returns a structured 402 with payment options — that response is the documented behavior, not a failure.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL. | |
| width | No | Viewport px. | |
| format | No | Default png. | png |
| height | No | Viewport px. | |
| quality | No | JPEG only, 1-100. | |
| fullPage | No | true = whole page, not viewport. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing per-call cost ($0.04) and explicitly framing the 402 payment-required response as expected behavior rather than an error — a real trap for an agent. It stops short of describing rate limits, timeouts, or what the image URL looks like/expires.
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 compact line with the core action front-loaded, followed by cost and the non-failure 402 semantics in priority order. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essentials an agent needs for a 6-param, no-output-schema tool: what comes back (a public image URL) and how billing/payment surfaces. Parameter details are fully handled by the schema, leaving only minor gaps like URL lifetime and error conditions other than 402.
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 width, height, format, quality, and fullPage are already documented with defaults and constraints. The description adds no parameter meaning beyond the schema, so the 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?
"Screenshot a page → public image URL" names a specific verb, resource, and the shape of the output, which cleanly separates it from the fetch_* and conversion siblings. An agent knows exactly what it gets back 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?
The description clarifies the paid call model and what a 402 response means, which is genuinely useful usage context. It does not say when to prefer this over fetch_html or other rendering tools, so the alternative-selection 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.
Fetch/parse an XML sitemap into JSON. Enumerate a site's pages.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Sitemap URL. | |
| maxUrls | No | Max 1000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, and the description adds the output shape (JSON) plus the transform (XML to JSON). However, it omits behaviors an agent would care about: whether sitemap index files (nested sitemaps) are followed, how gzip sitemaps are handled, and whether results are truncated at maxUrls silently.
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, zero filler, with the core action stated first and the agent-facing purpose second. Nothing could be removed without losing 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 two-parameter read-only tool with full schema coverage and no output schema, the definition is minimally sufficient. It stops short of covering the edge cases that actually distinguish sitemap parsing (sitemap index recursion, truncation behavior) that an agent would need to interpret incomplete results.
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 are documented in structured data and the baseline of 3 applies. The description adds no extra meaning about the url parameter (e.g., whether it must point directly at an .xml sitemap) or about what happens when maxUrls truncates the list.
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?
Names a specific verb and resource ("parse an XML sitemap into JSON") and adds the intent ("enumerate a site's pages"), so the agent knows exactly what comes back. It does not distinguish itself from nearby siblings like fetch_extract, fetch_html, or rss_parse, which also retrieve page content, leaving the boundary 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?
The phrase "enumerate a site's pages" implies the use case (bulk URL discovery from a sitemap) but never states when to prefer this over fetch_extract or fetch_html, nor any prerequisite such as the site actually having a published sitemap. Usage is inferable, not instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Multi-tool workflow prompts (clone a site, SEO audit). No args → menu; recipe='' → prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe | No | Recipe id; omit for menu. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the main behavioral burden is covered. The description adds useful non-schema context: the tool is free, it returns workflow prompts, and omitting arguments produces a menu rather than an error.
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?
It is three compact fragments, front-loaded with cost and purpose, then invocation behavior. Every part carries useful information with no waste.
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, zero-required-parameter tool with full schema coverage and annotations, the description is nearly complete. It still does not explain what the menu contains or the shape of the returned prompt, but those are modest gaps given the tool's simplicity.
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 sole parameter is already documented. The description restates the omit-for-menu behavior and adds that a recipe id yields a prompt, but it does not add syntax, ID format, or discovery detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource — "Multi-tool workflow prompts" — and gives concrete examples ("clone a site, SEO audit"), so its purpose is clear beyond the title. It is not fully explicit about how it differs from sibling tools such as tool_catalog, but the recipe/prompt framing is distinct enough for selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit call patterns: "No args → menu" and "recipe='<id>' → prompt." This is clear invocation context, though it does not name alternatives or say when to prefer this over a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Full catalog. No args → families. family='' → tools. tool='' → detail.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | Tool name → detail. | |
| family | No | Family id → its tools. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the useful fact that the catalog is 'Free' and that output varies by argument tier, but says nothing about result size, pagination, or truncation for a full catalog.
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?
Telegraphic but front-loaded: cost, scope, then the argument-to-output mapping. Every token carries information and there is 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 2-param read-only browser with no output schema, the mode routing is well covered, but the description never defines what a 'family' is, how many families/tools exist, or what 'detail' contains, leaving an agent to discover scale and response shape by trial.
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 the schema descriptions ('Tool name → detail.', 'Family id → its tools.') mirror the description almost verbatim, so the description adds no meaning beyond the schema. 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 resource (full tool catalog) and enumerates the three routing modes (no args → families, family → tools, tool → detail), which lets an agent predict the response shape. It does not explicitly contrast itself with the sibling use_tool, so it falls short of a 5.
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 mode table implies usage (call with no args to discover, then drill down with family or tool), but there is no explicit guidance on when to prefer this over directly calling use_tool or the other siblings, and no prerequisite/ordering statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Run any tool not in tools/list (see tool_catalog). Same pricing as a direct call.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Args per that tool's inputSchema. | |
| name | Yes | Tool name (see tool_catalog). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint false and destructiveHint false, so the key safety posture is structured. The description adds useful context that the tool is free and priced like a direct call, plus the catalog-routing role, but it does not disclose how forwarded tools' side effects are bounded, error behavior, or argument forwarding 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?
The description is two short sentences with no filler and a front-loaded pricing note. Every clause contributes routing or cost context.
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 meta-tool with nested args and no output schema, the description provides the essential routing information and references tool_catalog and the target schema. It remains thin on what the call returns, how failures are surfaced, and whether the wrapper alters the invoked tool's behavior, leaving meaningful gaps for a dispatcher.
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 are already documented in the input schema. The description only points to tool_catalog and the target tool's inputSchema, adding little semantic detail beyond what structured fields provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair ('Run any tool') and scopes execution to tools not exposed in tools/list, while pointing to the sibling tool_catalog for discovery. It is specific enough to separate the dispatcher from the catalog, though the phrase 'any tool not in tools/list' is somewhat circuitous.
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 an implied usage condition: use this for tools that are not in tools/list and consult tool_catalog. However, it does not explicitly state when not to use it, what happens for tools already in tools/list, or what the alternative direct call conditions are beyond pricing parity.
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.
fetch_html2 fields changedInput schema / properties / maxChars / descriptionPrevious value: -"Default 16000, max 64000."New value: +"Output cap, chars. Default 16000, max 64000."Input schema / properties / url / descriptionPrevious value: -"Page URL."New value: +"http(s) page URL. Private addresses are refused."html_to_markdown3 fields changedInput schema / properties / html / descriptionPrevious value: -"Raw HTML (alt. to url)."New value: +"HTML text to convert. Not with url."Input schema / properties / maxChars / descriptionPrevious value: -"Default 12000, max 50000."New value: +"Output cap, chars. Default 12000, max 50000."Input schema / properties / url / descriptionPrevious value: -"Page URL (alt. to html)."New value: +"Page URL to fetch. Not with html."json_query4 fields changedInput schema / properties / json / descriptionPrevious value: -"Raw JSON (alt. to url)."New value: +"Inline JSON text. Not with url."Input schema / properties / limit / descriptionPrevious value: -"Max results."New value: +"Default 100, max 1000. Above it: {results,total,returned}."Input schema / properties / query / descriptionPrevious value: -"e.g. '$.users[*].name'."New value: +"Starts with $: '$.users[*].name', '$..price', '$.items[?(@.price<10)].id'. Filter ops: = != > >= < <= =~. '$' = whole document."Input schema / properties / url / descriptionPrevious value: -"JSON URL (alt. to json)."New value: +"JSON URL, max 5 MB. Not with json."memory_snippet1 field changedInput schema / properties / harness / descriptionPrevious value: -"Agent runtime; omit for generic."New value: +"Your agent runtime, to tailor the save instruction. Omit for a generic one."pdf_text_extract3 fields changedInput schema / properties / data / descriptionPrevious value: -"Base64 PDF, ≤5MB decoded (alt. to url)."New value: +"Base64 PDF, max 5 MB decoded. Not with url."Input schema / properties / maxChars / descriptionPrevious value: -"Default 20000, max 100000."New value: +"Output cap, chars. Default 20000, max 100000."Input schema / properties / url / descriptionPrevious value: -"PDF URL (alt. to data)."New value: +"Direct link to the .pdf file, not a viewer page. Not with data."pdf_text_extract3 fields changedInput schema / properties / dataAdded value: +{
+ "description": "Base64 PDF, ≤5MB decoded (alt. to url).",
+ "type": "string"
+}Input schema / properties / url / descriptionPrevious value: -"PDF URL."New value: +"PDF URL (alt. to data)."Input schema / requiredRemoved value: -[
- "url"
-]memory_snippet1 field changedInput schema / properties / harness / enumPrevious value: -[
- "claude-code",
- "claude-desktop",
- "hermes",
- "openclaw",
- "generic"
-]New value: +[
+ "claude-code",
+ "claude-desktop",
+ "hermes",
+ "grok-build",
+ "openclaw",
+ "generic"
+]csv_query8 fields changedInput schema / properties / csv / descriptionAdded value: +"Raw CSV (alt. to url)."Input schema / properties / format / descriptionAdded value: +"Default json."Input schema / properties / headers / descriptionAdded value: +"Headers to forward (Authorization, Cookie…)."Input schema / properties / limit / descriptionAdded value: +"Default 500, max 5000."Input schema / properties / select / descriptionAdded value: +"Columns, comma-separated."Input schema / properties / sort_by / descriptionAdded value: +"Sort column."Input schema / properties / sort_dir / descriptionAdded value: +"Default asc."Input schema / properties / url / descriptionAdded value: +"CSV URL (alt. to csv)."fetch_extract3 fields changedInput schema / properties / headers / descriptionAdded value: +"Headers to forward (Authorization, Cookie…)."Input schema / properties / maxChars / descriptionAdded value: +"Default 8000, max 32000."Input schema / properties / url / descriptionAdded value: +"Page URL."fetch_html3 fields changedInput schema / properties / headers / descriptionAdded value: +"Headers to forward (Authorization, Cookie…)."Input schema / properties / maxChars / descriptionAdded value: +"Default 16000, max 64000."Input schema / properties / url / descriptionAdded value: +"Page URL."fetch_metadata2 fields changedInput schema / properties / headers / descriptionAdded value: +"Headers to forward (Authorization, Cookie…)."Input schema / properties / url / descriptionAdded value: +"Page URL."html_to_markdown4 fields changedInput schema / properties / headers / descriptionAdded value: +"Headers to forward (Authorization, Cookie…)."Input schema / properties / html / descriptionPrevious value: -"Alt. to url."New value: +"Raw HTML (alt. to url)."Input schema / properties / maxChars / descriptionAdded value: +"Default 12000, max 50000."Input schema / properties / url / descriptionAdded value: +"Page URL (alt. to html)."json_query4 fields changedInput schema / properties / headers / descriptionAdded value: +"Headers to forward (Authorization, Cookie…)."Input schema / properties / json / descriptionAdded value: +"Raw JSON (alt. to url)."Input schema / properties / limit / descriptionAdded value: +"Max results."Input schema / properties / url / descriptionAdded value: +"JSON URL (alt. to json)."keyword_research4 fields changedInput schema / properties / include_suggestions / descriptionAdded value: +"Add related suggestions."Input schema / properties / keywords / descriptionAdded value: +"1-20 keywords."Input schema / properties / language_code / descriptionAdded value: +"ISO 639-1."Input schema / properties / location_code / descriptionAdded value: +"DataForSEO location (default Spain)."memory_snippet1 field changedInput schema / properties / harness / descriptionAdded value: +"Agent runtime; omit for generic."pdf_text_extract3 fields changedInput schema / properties / headers / descriptionAdded value: +"Headers to forward (Authorization, Cookie…)."Input schema / properties / maxChars / descriptionAdded value: +"Default 20000, max 100000."Input schema / properties / url / descriptionAdded value: +"PDF URL."rss_parse1 field changedInput schema / properties / url / descriptionAdded value: +"Feed URL."screenshot_url5 fields changedInput schema / properties / format / descriptionAdded value: +"Default png."Input schema / properties / height / descriptionAdded value: +"Viewport px."Input schema / properties / quality / descriptionAdded value: +"JPEG only, 1-100."Input schema / properties / url / descriptionAdded value: +"Page URL."Input schema / properties / width / descriptionAdded value: +"Viewport px."sitemap_parse1 field changedInput schema / properties / url / descriptionAdded value: +"Sitemap URL."task_recipes1 field changedInput schema / properties / recipe / descriptionAdded value: +"Recipe id; omit for menu."tool_catalog2 fields changedInput schema / properties / family / descriptionAdded value: +"Family id → its tools."Input schema / properties / tool / descriptionAdded value: +"Tool name → detail."use_tool2 fields changedInput schema / properties / args / descriptionAdded value: +"Args per that tool's inputSchema."Input schema / properties / name / descriptionAdded value: +"Tool name (see tool_catalog)."csv_query1 field changedInput schema / properties / headersAdded value: +{
+ "type": "object"
+}fetch_extract1 field changedInput schema / properties / headersAdded value: +{
+ "type": "object"
+}fetch_html1 field changedInput schema / properties / headersAdded value: +{
+ "type": "object"
+}fetch_metadata1 field changedInput schema / properties / headersAdded value: +{
+ "type": "object"
+}fetch_structuredhtml_to_markdown1 field changedInput schema / properties / headersAdded value: +{
+ "type": "object"
+}json_query1 field changedInput schema / properties / headersAdded value: +{
+ "type": "object"
+}pdf_text_extract1 field changedInput schema / properties / headersAdded value: +{
+ "type": "object"
+}csv_query2 fields changedInput schema / properties / csv / descriptionRemoved value: -"Alt. to url: raw CSV text to query. Provide this OR url, not both."Input schema / properties / url / descriptionRemoved value: -"URL of a CSV to fetch (http:// or https://). Provide this OR csv, not both."csv_query2 fields changedInput schema / properties / csv / descriptionAdded value: +"Alt. to url: raw CSV text to query. Provide this OR url, not both."Input schema / properties / url / descriptionAdded value: +"URL of a CSV to fetch (http:// or https://). Provide this OR csv, not both."screenshot_url1 field changedInput schema / properties / fullPage / descriptionAdded value: +"true = whole page, not viewport."account_balanceaccount_depositbase64_decodebase64_encodecount_tokenscsv_query8 fields changedInput schema / properties / csv / descriptionRemoved value: -"Raw CSV text (alternative to url)."Input schema / properties / filter / descriptionPrevious value: -"Row filter expression: 'column op value'. Operators: = != > >= < <= contains startswith endswith. E.g. 'age > 30' or 'country = US'."New value: +"'col op value'."Input schema / properties / format / descriptionRemoved value: -"Output format: 'json' (default) or 'csv'."Input schema / properties / limit / descriptionRemoved value: -"Maximum number of rows to return (default 500, max 5000)."Input schema / properties / select / descriptionRemoved value: -"Comma-separated column names to include (e.g. 'name,age,country'). Omit to include all columns."Input schema / properties / sort_by / descriptionRemoved value: -"Column name to sort by."Input schema / properties / sort_dir / descriptionRemoved value: -"Sort direction: 'asc' (default) or 'desc'."Input schema / properties / url / descriptionRemoved value: -"URL of the CSV file to fetch (http/https)."diff_textfetch_extract2 fields changedInput schema / properties / maxChars / descriptionRemoved value: -"Max characters to return (default 8000, max 32000)"Input schema / properties / url / descriptionRemoved value: -"The URL to fetch and extract text from"fetch_html2 fields changedInput schema / properties / maxChars / descriptionRemoved value: -"Max characters to return (default 16000, max 64000)."Input schema / properties / url / descriptionRemoved value: -"The URL to fetch (http:// or https://)."fetch_metadata1 field changedInput schema / properties / url / descriptionRemoved value: -"URL to fetch (http:// or https://)."fetch_structured2 fields changedInput schema / properties / schema / descriptionPrevious value: -"JSON Schema (as a JSON string) describing the fields to extract. E.g. {\"type\":\"object\",\"properties\":{\"title\":{\"type\":\"string\"},\"price\":{\"type\":\"number\"}}}"New value: +"JSON Schema string."Input schema / properties / url / descriptionRemoved value: -"URL to fetch and extract data from."hash_texthtml_to_markdown3 fields changedInput schema / properties / html / descriptionPrevious value: -"Raw HTML string to convert directly (alternative to url)."New value: +"Alt. to url."Input schema / properties / maxChars / descriptionRemoved value: -"Max characters of Markdown to return (default 12000, max 50000)."Input schema / properties / url / descriptionRemoved value: -"URL to fetch and convert (http:// or https://)."json_formatjson_query4 fields changedInput schema / properties / json / descriptionRemoved value: -"Raw JSON string to query (alternative to url)."Input schema / properties / limit / descriptionRemoved value: -"Max number of results to return (default 100, max 1000)."Input schema / properties / query / descriptionPrevious value: -"JSONPath-lite expression. Examples: '$.users[*].name', '$..price', '$.items[?(@.stock > 0)].id', '$.store.books[0].title'"New value: +"e.g. '$.users[*].name'."Input schema / properties / url / descriptionRemoved value: -"URL returning JSON to query (http/https)."keyword_research4 fields changedInput schema / properties / include_suggestions / descriptionRemoved value: -"Whether to fetch top-5 related keyword suggestions per seed keyword. Default true. Set false to skip the suggestions call and reduce latency."Input schema / properties / keywords / descriptionRemoved value: -"One keyword (string) or up to 20 keywords (array of strings, max 20). Pass a single string for one keyword or an array for multiple keywords in one API call."Input schema / properties / language_code / descriptionRemoved value: -"ISO 639-1 language code for Google Ads data. Default \"es\" (Spanish). Use \"en\" for English, \"fr\" for French, etc."Input schema / properties / location_code / descriptionRemoved value: -"DataForSEO location code for Google Ads geo-targeting. Default 2724 (Spain). Use 2840 for USA, 2826 for UK. Full list: https://api.dataforseo.com/v3/keywords_data/google_ads/locations"memory_snippetpage_assetspage_linkspdf_text_extract2 fields changedInput schema / properties / maxChars / descriptionRemoved value: -"Max characters to return (default 20000, max 100000)."Input schema / properties / url / descriptionRemoved value: -"URL of the PDF to fetch (http/https). Must be a PDF file."regex_extractremove_background1 field changedInput schema / properties / image_url / descriptionPrevious value: -"Public URL of the source image (JPEG, PNG, or WEBP). Must be accessible from the internet — local paths and data: URIs are not supported."New value: +"Public image URL."rss_parse2 fields changedInput schema / properties / maxItems / descriptionPrevious value: -"Max feed items to return (default 20, max 200)."New value: +"Max 200."Input schema / properties / url / descriptionRemoved value: -"RSS or Atom feed URL (http:// or https://)."screenshot_url6 fields changedInput schema / properties / format / descriptionRemoved value: -"Image format: \"png\" (default) or \"jpeg\"."Input schema / properties / fullPage / descriptionRemoved value: -"Capture the entire scrollable page instead of just the viewport. Default false."Input schema / properties / height / descriptionRemoved value: -"Viewport height in pixels (default 800, 100–4000). Ignored when fullPage is true."Input schema / properties / quality / descriptionRemoved value: -"JPEG quality 1–100 (only applies when format is jpeg)."Input schema / properties / url / descriptionRemoved value: -"The URL of the page to screenshot (http:// or https://)."Input schema / properties / width / descriptionRemoved value: -"Viewport width in pixels (default 1280, 100–4000)."sitemap_parse2 fields changedInput schema / properties / maxUrls / descriptionPrevious value: -"Max URLs to return from a urlset (default 100, max 1000). Has no effect on sitemapindex (all child sitemaps are always returned)."New value: +"Max 1000."Input schema / properties / url / descriptionRemoved value: -"Sitemap URL (http:// or https://). Accepts sitemap.xml, sitemap_index.xml, or any XML sitemap."task_recipes1 field changedInput schema / properties / recipe / descriptionRemoved value: -"The recipe id to expand (e.g. 'replicate_website', 'seo_audit'). Omit to list the menu."text_statstimestamp_converttool_catalogupload_fileurl_decodeurl_encodeuse_tooluuid_generatewallet_setupextract_structuredfetch_metadatafetch_structuredwebpage_metadatawallet_setupupload_file13 micro-tools for agents: read pages, verify email, convert, validate, diff, extract. AI-operated.
10 deterministic micro-tools for agents. x402 on X Layer, zero LLM.
Pay-per-call (x402/USDC-Base) web + crypto data tools for AI agents: audit, extract, crypto, DeFi.
Pay-per-use agent tools: screenshots, web to Markdown, PDF tables, OCR, UK company checks
Add one secure layer between your agents and this server.
