Everyday tools for AI agents, paid per call with x402: images, markdown, speech-to-text, embeddings.
Scored across 15 tools
Most tools target clearly distinct operations (DNS, WHOIS, embeddings, image generation, transcription, translation, email verification). The main overlap is read_url vs url_to_markdown, which are near-identical operations differing only in price/limits, and summarize can also fetch a URL, creating a second axis of confusion. The descriptions do explain the free/paid split, so an agent can recover, but the boundaries are not as crisp as they could be.
The set is overwhelmingly consistent snake_case with verb_noun or noun_noun patterns (dns_lookup, domain_whois, embed_text, generate_image, verify_email). Deviations are minor: the two chat tools embed model identifiers in the name (chat_gpt_oss_120b, chat_qwen3_30b), which is a different convention and will not scale as models change, and summarize is a bare verb with no object.
Fifteen tools sits at the top of the well-scoped band for a multi-utility API. Each tool maps to one concrete paid capability with a distinct input type or output artifact, so nothing feels padded. The only redundancy is the deliberate free/paid pair of read_url and url_to_markdown.
For a general-purpose AI/network utility toolbox the surface is broad: LLM chat, embeddings, image generation, speech-to-text, translation, summarization, DNS, WHOIS, FX, email validation and document/URL conversion. Gaps exist but are not blocking — no OCR, no text-to-speech, no vision/image understanding, and no reranking endpoint to pair with embed_text. An agent can still complete most realistic workflows with what is offered.
OpenAI-compatible chat completion with gpt-oss-120b (OpenAI's open-weight reasoning model): set the base URL to /v1/llm/gpt-oss-120b in any OpenAI SDK. Up to 32,000 characters in and 2,048 tokens out per call, a fixed price per call, no streaming. Costs USD 0.005 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| messages | Yes | OpenAI chat messages: [{role: system|user|assistant, content}] (up to 32,000 characters in total) | |
| max_tokens | No | Default 2048 | |
| temperature | No | ||
| response_format | No | {"type": "json_object"} for JSON output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context annotations don't carry: fixed price USD 0.005 per call, x402/USDC-on-Base payment, failed calls not charged, no streaming, and hard token/character limits. That covers cost and failure semantics well; it could still mention rate limiting or error response format, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads model, endpoint, and integration path, then tacks on limits, pricing, and payment. Every clause is useful, though the pricing/payment tail makes it run slightly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid inference endpoint with no output schema, the description supplies the key facts an agent needs: compatibility, limits, cost, payment mechanism, and failure charging. Missing only peripheral details like error shape or rate limits.
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 75% and the schema already documents messages, max_tokens bounds, and response_format. The description reinforces the 32,000-character input and 2,048-token output caps but adds no syntax or format detail for temperature or response_format beyond what's structured.
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 (chat completion), names the exact model (gpt-oss-120b), and gives the concrete endpoint path (/v1/llm/gpt-oss-120b), which distinguishes it from chat_qwen3_30b 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?
Explains how to invoke it (point any OpenAI SDK base URL at /v1/llm/gpt-oss-120b) and states constraints like no streaming and per-call pricing. It does not explicitly say when to choose it over the sibling chat_qwen3_30b, 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.
OpenAI-compatible chat completion with Qwen3 30B (fast mixture-of-experts model): set the base URL to /v1/llm/qwen3-30b in any OpenAI SDK. Up to 32,000 characters in and 2,048 tokens out per call, a fixed price per call, no streaming. Costs USD 0.002 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| messages | Yes | OpenAI chat messages: [{role: system|user|assistant, content}] (up to 32,000 characters in total) | |
| max_tokens | No | Default 2048 | |
| temperature | No | ||
| response_format | No | {"type": "json_object"} for JSON output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing input/output token limits, no streaming, fixed per-call pricing (USD 0.002), the x402/USDC-on-Base payment requirement, and that failed calls are not charged. These are precisely the operational facts an agent needs before calling a paid endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the core capability and SDK usage, then packs limits and pricing. It is efficient, though the parenthetical and semicolon clauses make it slightly harder to scan than an ideal multi-sentence layout.
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?
Complete for a paid chat-completion endpoint with no output schema: it covers input constraints, output limits, pricing, payment method, and failure billing. Return structure is only implied by 'OpenAI-compatible', which is slightly less explicit than it could be.
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?
With 75% schema description coverage, the baseline is 3. The description's '32,000 characters in and 2,048 tokens out' largely repeats what the schema already states in the messages description and max_tokens maximum, and it adds no guidance on temperature or response_format.
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 ('OpenAI-compatible chat completion with Qwen3 30B') and names the exact model variant, which distinguishes it from the sibling chat_gpt_oss_120b tool 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?
Explains how to invoke it ('set the base URL to /v1/llm/qwen3-30b in any OpenAI SDK') and gives model characteristics that aid selection, but never explicitly contrasts when to choose it over chat_gpt_oss_120b or 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.
DNS records of a domain (A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, SRV, PTR) over DNS-over-HTTPS (1.1.1.1), with DNSSEC validation status. Costs USD 0.002 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Domain name | |
| type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial context beyond that: the DNS-over-HTTPS resolver, DNSSEC validation status, per-call cost of USD 0.002, payment via x402 with USDC on Base, and the fact that failed calls are not charged. These are meaningful operational details not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the main purpose and then adds resolver, DNSSEC, and billing details. It is efficient, though the list of record types duplicates the enum values and could be trimmed.
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 only 2 parameters, the description should explain the return shape more fully. It covers the resolver, DNSSEC status, and billing model, but it does not specify the response structure or what happens when the type parameter is omitted.
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 50%: the required name parameter is described as a domain name, and the type parameter is an enum without its own description. The description restates the enum values and clarifies that a domain is the target, but it does not explain the type parameter's optional/default behavior when omitted, so it only partially compensates for the schema 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?
The description clearly states that this tool retrieves DNS records for a domain, enumerates the supported record types, and identifies the resolver (DNS-over-HTTPS at 1.1.1.1). It is specific and actionable, but it does not explicitly distinguish itself from the related sibling domain_whois.
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 does not say when to use this tool versus alternatives such as domain_whois, nor does it state exclusions or prerequisites beyond the cost note. Usage is only implied by the resource name and supported record types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Domain registration data from RDAP (the successor of WHOIS): registrar, creation, expiry and update dates, status codes, nameservers and DNSSEC. Costs USD 0.002 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld and non-destructive, but the description adds genuinely new behavioral context: the fixed USD 0.002 per-call cost, the x402/USDC-on-Base payment path, and that failed calls are not charged. That pricing and billing detail is exactly what structured fields do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the payload comes first, the cost model second, with no filler. Sizing is appropriate for a single-parameter lookup.
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 one-parameter read tool, annotations cover safety and the description covers output fields and billing. The missing piece is the domain parameter's expected format and any sibling routing, which leaves a real gap despite the otherwise solid coverage.
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 there is one required parameter (domain) that the description never characterizes. It does not say whether the value should be a bare domain, a subdomain, or include a scheme, so the description fails to compensate for the empty 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?
States a specific verb+resource (retrieve domain registration data via RDAP) and enumerates the returned fields (registrar, dates, status codes, nameservers, DNSSEC). It is clear what the tool does, but it never differentiates itself from the sibling dns_lookup, so an agent must infer the boundary itself.
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?
There is no explicit when-to-use or when-not-to-use guidance, and the most relevant alternative, dns_lookup, is never mentioned. Usage is only implied by the RDAP content listed, leaving the agent to guess whether registration data vs DNS resolution is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Text embeddings with BGE-M3 (multilingual, 1024 dimensions) for search, clustering and RAG: up to 100 texts of up to 8,000 characters per call. Costs USD 0.002 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| texts | Yes | Texts to embed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only, open-world, non-destructive annotations, the description discloses important behavior: 1024-dimensional multilingual output, batch limits, pricing, x402/USDC payment, and that failed calls are not charged. These are exactly the kind of operational and cost details an agent needs before invoking the 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 description is a single dense sentence with no wasted clauses: model, dimensionality, use cases, limits, cost, payment rail, and failure policy are all front-loaded and relevant.
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 one-parameter tool with full schema coverage and annotations, the description covers the key operational facts: model, output dimensionality, batch and text limits, cost, and payment behavior. It does not explicitly describe the response structure, but the mention of 1024 dimensions makes the return shape largely inferable.
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% for the single 'texts' parameter, establishing a baseline of 3. The description adds value beyond the schema by specifying the per-call batch limit and an 8,000-character per-text limit, though it does not explain ordering or edge-case handling for empty strings.
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 operation, 'Text embeddings', identifies the model and dimensionality (BGE-M3, 1024 dimensions), and names concrete use cases (search, clustering, RAG). This is enough for an agent to distinguish it from generation, summarization, translation, and retrieval-adjacent siblings.
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 usage context by naming search, clustering, and RAG as intended applications. It does not explicitly say when to prefer a sibling or when not to use embeddings, so it falls short of full alternative-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an uploaded document (PDF, Word, Excel, CSV, HTML, XML, OpenDocument; up to 10 MB) to Markdown. Costs USD 0.003 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | File name with extension, e.g. report.pdf | |
| file_base64 | Yes | The file, base64-encoded |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavior: the tool costs USD 0.003 per call, payment is via x402 with USDC on Base, and failed calls are not charged. It also states the 10 MB limit and supported file formats, which are material operational details not covered by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the main action, supported formats, size limit, pricing, and failure policy. Every clause adds useful information without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description covers the input constraints, cost model, and conversion target adequately. It does not describe the exact return payload, but the tool's purpose and constraints are sufficiently clear for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains filename and file_base64. The description adds no parameter-level detail beyond restating that an uploaded document is converted, so the baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: convert an uploaded document to Markdown. It also enumerates supported document types and the 10 MB limit, which clearly separates it from the URL-oriented sibling url_to_markdown by focusing on uploaded files.
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 phrase 'uploaded document,' but the description does not explicitly state when to use this instead of alternatives such as url_to_markdown. It gives practical constraints like size and supported formats, but no direct routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Currency exchange rates and conversion for about 30 currencies (USD, EUR, GBP, INR, JPY, CNY ...) from the European Central Bank reference rates of the latest working day. Costs USD 0.002 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base currency, default USD | |
| amount | No | Amount to convert (default 1) | |
| symbols | No | Comma-separated, e.g. EUR,INR (default: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: price per call, payment via x402/USDC on Base, and that failed calls are not charged. It does not detail rate limits or deeper payment/auth requirements, keeping it at a 4.
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 front-loaded sentences carry the purpose, data source, currency coverage, cost, payment method, and failure-charge policy without waste. Every sentence 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?
The tool is simple with three optional parameters, no nested objects, and no output schema. The description covers the data source, currency count, recency, cost, and failure policy. It could explicitly describe the return shape, but that gap is minor for a simple FX rate/conversion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents base, amount, and symbols, including defaults. The description mentions the currency scope and conversion but does not add semantics beyond the schema, making 3 the appropriate baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and scope: currency exchange rates and conversion for about 30 currencies from ECB reference rates of the latest working day. This is clear enough for an agent to distinguish it from unrelated siblings such as dns_lookup or translate_text.
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 stated purpose, but the description does not explicitly say when to use this tool, when not to use it, or name any alternatives. Given that no sibling tool overlaps with FX rates, the implied usage is adequate but not strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 1024x1024 JPEG image from a text prompt with FLUX.1 schnell; every prompt passes a safety check first (sexual content and other unsafe requests are refused and not charged). Returns the image as base64. Costs USD 0.01 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | No | Diffusion steps, 1 to 8 (default 4; more is slower and finer) | |
| prompt | Yes | What to draw, up to 2048 characters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses useful behavior such as safety checks, base64 output, and per-call cost, but it directly conflicts with the readOnlyHint=true annotation. Generating an image and charging USD 0.01 per call via x402 are side effects, which contradicts a read-only tool declaration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and output, then adds safety, return format, and cost details. Every sentence carries relevant information without 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 two-parameter image generation tool with no output schema, the description covers the return format, cost model, safety behavior, and failure charging. It is nearly complete, though payment mechanics and usage conditions are not fully elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both prompt and steps. The description adds no parameter-level details beyond the schema, which meets the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: generate a 1024x1024 JPEG image from a text prompt using FLUX.1 schnell. The model, output format, dimensions, and modality clearly distinguish it from the text-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for text-to-image generation, but it does not explicitly state when to use it versus alternatives or when not to use it. The safety refusal note is a constraint, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Read a public web page or document (HTML, PDF, Word, Excel, CSV; up to 5 MB) as clean Markdown with its title. Up to 20 reads a minute per IP; for more, url_to_markdown is the paid version with no limit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A public http(s) URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent hints, the description discloses the free tier, the concrete rate limit (20 reads/minute per IP), the 5 MB payload cap, accepted content types, and the return shape (clean Markdown plus title). That is exactly the operational context the 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?
Two sentences, no waste. 'Free.' is front-loaded and the paid-alternative pointer lands last as a natural fallback, with limits stated inline rather than in a separate paragraph.
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 read tool with no output schema, everything needed to call it correctly is present: input constraints, size/rate limits, supported formats, and what comes back. No meaningful gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single url parameter is already documented as 'a public http(s) URL'. The description reinforces the public-access constraint and implicitly bounds input to web documents under 5 MB, but adds little beyond that.
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 ('read a public web page or document') and enumerates supported formats and size ceiling, so the agent knows exactly what it returns. It also names the sibling url_to_markdown and states the axis of difference (free vs paid/rate-limited).
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 to url_to_markdown when the 20/min limit is insufficient, which is a real when-to-use alternative. It does not address the other plausible alternative, file_to_markdown, for local or already-uploaded files, so routing 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.
Free. Lists every tool with its price and explains how payment works (x402 over MCP, USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new context: the call is free, and it returns per-tool pricing plus an explanation of the x402/USDC-on-Base payment flow — information not present in any structured field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero waste, front-loaded with the most decision-relevant fact ('Free') followed by the returned content and the payment model. Nothing repeats the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description carries the burden of describing returns, and it does so at an appropriate level (tool list, prices, payment explanation). It could note the response shape or that this is the discovery entry point, but it is sufficient to call 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?
The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description correctly signals a no-argument call by saying it simply lists tools and pricing.
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: lists every tool with its price and explains the payment mechanism (x402 over MCP, USDC on Base). No sibling tool overlaps with this catalog/pricing role, so it is distinguishable, though the description does not call out that distinction 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?
Usage is implied rather than stated: an agent can infer it should call this to discover available tools and pricing before invoking paid ones. There is no explicit 'use when' framing or reference to alternatives, but with zero parameters the invocation decision is low-risk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize text (up to 60,000 characters) or a public web page or PDF by URL with Llama 3.1 8B, short, medium or long, optionally focused on a topic. Costs USD 0.003 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | A public http(s) URL | |
| text | No | ||
| focus | No | Optional topic to focus on | |
| length | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, openWorld, non-idempotent, non-destructive); the description adds the facts an agent actually needs to decide: USD 0.003 per call, payment via x402 with USDC on Base, and that failed calls are free. Pricing and payment prerequisites are exactly the kind of context annotations cannot carry, and the non-idempotent hint is consistent with a paid per-call operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-front-loaded sentence that leads with the action and input forms, then appends limits, options, and cost. Every clause carries information, though the packed pricing/payment tail makes the sentence dense enough to be worth splitting.
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 conveys the essentials: model, length options, focus, size cap, and the billing model. The missing piece is that neither text nor url is required in the schema and the description never states that one must be provided, leaving a real chance of a no-input call.
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 50% (text and length have no schema descriptions), but the description compensates: it caps text at 60,000 characters, enumerates short/medium/long for length, and clarifies that focus is an optional topic and URL must be public http(s) pointing at a page or PDF. The one remaining gap is the mutual relationship between text and url.
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 (summarize) plus the exact input modalities — raw text up to 60,000 characters, or a public web page/PDF by URL — and names the model and length options. An agent can immediately distinguish this from siblings like read_url, url_to_markdown, or file_to_markdown, which convert rather than condense.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operating context: two input paths (text or URL), a hard 60,000-character limit, optional topic focus, and three length settings. It stops short of explicit routing against siblings (e.g., when to prefer url_to_markdown) and doesn't say that at least one of text/url must be supplied, since the schema marks nothing required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Speech to text with Whisper large v3 turbo: transcribe audio (mp3, wav, m4a, ogg, webm; up to 20 MB, about 20 minutes) from a URL or base64, or translate the speech into English. Returns the text, language, duration and timed segments. Costs USD 0.01 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | translate = into English | |
| language | No | Language code such as en or hi (detected when left out) | |
| audio_url | No | A public http(s) URL | |
| audio_base64 | No | The audio file, base64-encoded |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It adds substantial behavior beyond the annotations: cost per call, payment rail, non-charging on failure, file-size and duration limits, and the return fields. These are exactly the operational details an agent needs before invocation, and nothing contradicts the read-only, open-world annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is front-loaded with the core operation and then packs limits, source options, output fields, payment cost, and failure policy into a dense but waste-free description. 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 no output schema, the description correctly supplies the return shape (text, language, duration, timed segments) and enough input, cost, and failure context for an agent to call the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description still adds useful parameter-facing detail not present in the schema, especially allowed audio formats and the 20 MB / ~20 minute constraint on the audio input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: transcribe audio with Whisper large v3 turbo. It names the supported format set, source options, and the alternative translate-into-English task, so an agent can distinguish it from text-translation siblings 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 implies usage through formats, size limits, and URL/base64 input, but it never explicitly says when to choose this over translate_text or other siblings. Guidance is present but implicit rather than routing-level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate text (up to 5,000 characters) between 100 languages with M2M100 1.2B. Costs USD 0.002 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| source_lang | No | Default english | |
| target_lang | Yes | Language name or code, e.g. french or fr |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, non-idempotent, and non-destructive behavior. The description adds valuable context annotations don't cover: per-call pricing, the x402/USDC payment mechanism, and that failed calls are not charged. It stops short of describing return shape or latency, though the latter is minor.
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 tight sentences, front-loaded with the core action and scope, with pricing as the secondary clause. No wasted words.
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 three-parameter tool with no output schema, the description covers limits, model, cost, payment, and failure billing, which are the main non-obvious facts. It leaves output format and source-language handling implicit, but those are either obvious or covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%; the description adds the 5,000-character text limit and the 100-language scope for language parameters, which the schema only partially conveys. It does not explain source-language inference behavior, but adds real meaning 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?
States a specific verb and resource (translate text), names the model (M2M100 1.2B), and gives scope (100 languages, 5,000 character limit). This clearly distinguishes it from siblings like summarize and embed_text.
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 purpose implies when to use it, but there is no explicit guidance on when to choose it versus alternatives such as summarize or embed_text, and no stated prerequisites beyond the cost line. Usage is inferred rather than instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public web page or document (HTML, PDF, Word, Excel, CSV, XML; up to 10 MB) and return it as clean Markdown with its title and final URL. Costs USD 0.002 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A public http(s) URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, non-idempotent, and non-destructive behavior. The description adds important operational context beyond annotations: size limit, supported document types, return values, per-call cost via x402, and the fact that failed calls are not charged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, moving from fetch/return behavior to limits and pricing without filler. Every phrase contributes useful information for invocation or cost awareness.
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 single-parameter, read-only URL conversion tool with no output schema, the description provides enough context: input constraints, supported formats, size limit, return shape, and payment behavior. No critical invocation detail appears 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?
Only one parameter exists with 100% schema coverage, so the schema already carries parameter meaning. The description reinforces the public http(s) URL constraint and supported formats, but does not add syntax or validation details 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?
States a specific verb and resource: fetch a public web page or document and return it as Markdown. It also lists supported formats and return fields, but does not explicitly distinguish it from sibling tools such as read_url or file_to_markdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: converting a public URL to Markdown. However, there is no explicit guidance on when to prefer this over read_url or file_to_markdown, nor any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an email address: format, whether the domain exists and accepts mail (MX records), disposable providers, role accounts and free providers, with a valid / risky / invalid verdict. The mailbox itself is not probed. Costs USD 0.002 per call, paid with x402 (USDC on Base); calls that fail are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the pricing model (USD 0.002 per call), the payment rail (x402, USDC on Base), and crucially that failed calls are not charged — an economic risk fact an agent cannot get from readOnlyHint/destructiveHint. It also frames the result taxonomy (valid / risky / invalid) and an explicit accuracy boundary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the capability and verdict taxonomy, followed by the two facts an agent most needs before calling: the non-probing limitation and the cost/refund policy. No filler and no repetition 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?
With one parameter and no output schema, the description supplies the essentials: what is checked, the verdict categories, the accuracy ceiling, and the billing behavior. It stops short of describing the response shape (per-check breakdown vs single verdict string), which the agent must discover at call time.
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 carries the burden for the single required parameter. "Check an email address: format, ..." makes clear the argument is a single address whose syntax and deliverability are assessed, which is sufficient for an obvious string input. It does not state normalizations (trimming, case, plus-addressing) that could affect results.
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 ("Check an email address") and enumerates exactly what is checked: format, MX records, disposable/role/free providers, with a valid/risky/invalid verdict. The clause "The mailbox itself is not probed" cleanly separates it from a raw DNS lookup, so an agent can distinguish it from siblings like dns_lookup without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope statement ("The mailbox itself is not probed") tells the agent the precise condition under which this tool is insufficient, which is a practical exclusion. However, no sibling is named and there is no explicit "use this before sending mail / use dns_lookup for raw records" routing statement, so the agent must infer the 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.
chat_gpt_oss_120bchat_qwen3_30bdns_lookupdomain_whoisembed_textfile_to_markdownfx_ratesgenerate_imageread_urlservice_infosummarizetranscribe_audiotranslate_texturl_to_markdownverify_emailx402 pay-per-call agent tools: token safety/honeypot check, speech to text, TTS, translate, OCR, web
Pay-per-call agent tools over x402 (USDC on Base) — no signup or API key.
270 pay-per-call AI tools for agents, paid via x402 (USDC on Base). No signup, no API keys.
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
Add one secure layer between your agents and this server.