Pay-per-call AI and media tools over x402. USDC on Base, no signup, no API key.
Scored across 16 tools
Most tools target a distinct operation on a distinct input type (fetch, screenshot, transcribe, tts, clip, dub), so selection is usually obvious. There is mild overlap in the text-analysis cluster — classify (caller labels), sentiment (fixed polarity), and detect (language/content type) all classify text, and summarize/keywords/outline all condense text — but the descriptions give enough signal to separate them.
Nearly every tool is a single lowercase verb or noun-verb token (fetch, summarize, transcribe, screenshot), which is a readable, predictable convention. The deviations are minor: list_prices is the only snake_case verb_noun entry, while ai-batch uses a hyphen and tokenverdict is a fused compound word.
At 16 tools the surface sits just above the comfortable range but stays well-scoped: each entry exposes a genuinely different capability (text analysis, media conversion, web fetching, pricing, token grading). Nothing appears to be a redundant duplicate of another tool.
The surface covers the apparent domain well: text ops, media transcription/dubbing/clipping/TTS, rendering, web fetch, batch AI, price discovery, and a niche token grader. The notable gap is lifecycle tooling around paid calls — no balance/usage check, no job-status or result-polling tool for potentially slow media operations like dub or clip, and no tool to inspect a prior ai-batch result.
Run up to N AI subtasks in one paid call (batch). Price: $0.01 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides highly valuable operational behavior that is not in the structured fields: the pricing ('$0.01 USDC') and the specific payment mechanism ('on Base via x402'). This crucial information dictates how the agent must handle cost and external dependencies.
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 concise and well-structured, front-loading the core functional benefit (batch execution) before providing necessary operational constraints.
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 complex because it combines orchestration with financial transactions. While the description completes the crucial operational picture (cost), it is incomplete because it fails to specify the necessary data structure for the 'payload' to successfully execute the batch tasks.
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 0% schema description coverage, the description adds zero semantic meaning to the single 'payload' parameter. It fails to specify the expected format or structure of the batch tasks intended for the payload.
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 defines the tool's function as running 'up to N AI subtasks in one paid call,' which differentiates it from single-purpose siblings. It correctly identifies its role as a batch orchestrator rather than a single function executor.
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 offers no guidance on when to use this tool relative to its numerous single-purpose siblings (e.g., summarize vs. batch_summarize). It only describes what it is, not why one should choose it over the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify text into caller-supplied labels. Price: $0.005 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It usefully discloses the price and payment rail ("$0.005 USDC on Base via x402"), but omits auth, rate limits, side effects, and return behavior, leaving key invocation expectations unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core action. The pricing sentence adds necessary operational context without padding.
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 classification tool, the definition still lacks critical invocation detail: how to pass labels, what the payload format is, and what the output looks like. No output schema is present, so the description should do more than state the action and price.
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?
There is one parameter, "payload," with 0% schema description coverage. The description mentions text and caller-supplied labels but never explains how those labels are passed through the generic payload string or what the default "{}" format means.
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 and resource: "Classify text into caller-supplied labels." This clearly indicates custom-label classification and implicitly distinguishes it from fixed-label siblings such as sentiment, but it does not explicitly name alternatives or differentiate from detect/keywords.
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 only usage signal is "caller-supplied labels," which implies a custom-label scenario. There is no explicit when-to-use guidance, no when-not guidance, and no named alternative such as sentiment for predefined labels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cut a short clip from a video URL (start/duration). Price: $0.005 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose a genuinely important behavioral trait: the call costs $0.005 USDC on Base via x402, so an agent knows a paid, wallet-backed request is involved. However, it says nothing about authentication requirements, output format/location of the resulting clip, failure modes, or size/duration limits on the 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?
Two compact sentences, front-loaded with the operation and its inputs, followed by the cost disclosure. Nothing is redundant and no sentence is 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 whose only input is an untyped JSON-in-a-string, the definition omits the one thing an agent must know: how to build the payload. With no annotations and no output schema to lean on, the missing payload contract and missing output description leave the definition inadequate for reliable 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?
The single parameter is an opaque 'payload' string with default '{}' and 0% schema coverage, so the schema alone gives the agent no way to construct a valid call. The description names the required concepts (video URL, start, duration) but never states that they belong inside the payload, nor the key names or encoding, so it only partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: cut a short clip from a video URL, with the key inputs (start/duration) named. It is clearly distinguishable from all siblings (dub, transcribe, summarize), though it does not explicitly contrast itself with any of them.
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?
No when-to-use or when-not-to-use guidance, no prerequisites, and no constraints such as maximum clip length, supported URL formats, or duration limits. The only contextual sentence is about price, which tells the agent nothing about selection between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect language and content type of a text. Price: $0.001 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full disclosure burden. It does add genuinely useful behavioral context by stating the price and payment rail ($0.001 USDC on Base via x402), which an agent needs before invoking a paid tool. However, it says nothing about failure behavior, whether the operation is read-only analysis, latency, or what the response contains.
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 with the capability front-loaded and the cost constraint second. No filler or restatement of the tool name.
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-only detection tool the description covers purpose and cost, and no output schema exists so return values need not be explained. The missing piece is the shape of the 'payload' input, which leaves the agent guessing at the exact call format.
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% for the single 'payload' parameter, so the description must compensate. It says only 'a text', while the schema declares a string defaulting to '{}', implying a JSON-encoded envelope rather than raw text. An agent cannot tell from either source whether to pass plain text or a JSON object string, which is a material ambiguity for the only 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 names a specific verb and two concrete outputs: language and content type of a text. That is far clearer than the bare name 'detect', though it does not explicitly distinguish the tool from the adjacent 'classify' or 'sentiment' siblings, which an agent could easily confuse with 'content type' detection.
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 guidance about when to use this versus 'classify' or 'sentiment', nor about input size limits, supported languages, or what happens with mixed-language text. The only extra information is pricing, which tells the agent the call costs money but not when the call is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dub a video into another language. Price: $0.003 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses one important trait — a cost of $0.003 USDC on Base via x402 — but says nothing about processing time, language support, input source (URL vs. file), or whether the operation is synchronous or job-based.
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 with no filler, and the core purpose is front-loaded. However, the brevity is partly under-specification rather than economy, since key operational details are absent.
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 mutation-style tool with a free-form untyped payload, no annotations, and no output schema, the description should cover input shape, language options, and result format. It covers only purpose and price, leaving the agent unable to construct a correct 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?
There is a single parameter named 'payload' defaulting to '{}' with 0% schema description coverage, and the description says nothing about it. An agent cannot infer what keys belong in this JSON blob, nor whether the target language, video URL, or voice options go there.
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 ('Dub a video into another language'), which is clear enough to distinguish it from siblings like transcribe or tts. It omits what 'dub' produces (audio track, full video, download link) and what input format is expected.
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?
No when-to-use guidance, no prerequisites, and no comparison to alternatives such as transcribe (which extracts text) or tts (which synthesizes speech). The pricing note hints at a paid call but does not explain how payment is authorized or what happens on failure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL and return clean text/markdown. Price: $0.005 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, and it does disclose one genuinely important behavioral trait: calls cost $0.005 USDC on Base via x402, which an agent needs to know before invoking. Beyond that it says nothing about redirects, JavaScript rendering, payload size limits, truncation, error behavior, or rate limits — all material for a network fetch 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?
Two short sentences with zero filler, and the core action is front-loaded ahead of the pricing note. Nothing could be cut 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 network tool with no annotations, no output schema, and an undocumented opaque parameter, the description should explain at minimum how to format the payload and what the returned text looks like. Neither is covered, so an agent cannot reliably construct a first call from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter is an opaque 'payload' string defaulting to '{}', so the schema offers no explanation at all. The description hints the payload carries a URL but never states the field name, the encoding (plain URL vs JSON object), or any other option, leaving the agent to guess the call shape.
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') plus the transformation performed ('return clean text/markdown'), which distinguishes it from a raw HTTP getter. It does not explicitly differentiate itself from the sibling AI utilities (summarize, screenshot, etc.), so an agent must infer the boundary on its own.
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?
No when-to-use or when-not-to-use guidance is given, and no alternative is named. The only conditional information is the pricing line, which tells the agent nothing about selecting this tool over the siblings for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract top keywords/phrases from text. Price: $0.005 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It usefully reveals a payment requirement ($0.005 USDC on Base via x402), which is genuine behavioral context, but says nothing about output shape, keyword count limits, input size constraints, or failure behavior.
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 no filler, and the core purpose is front-loaded before the pricing note. Nothing is wasted, though the brevity reflects under-specification rather than efficiency alone.
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 compute tool with an undocumented 'payload' parameter and no output schema, the description should explain what goes in and roughly what comes back. It covers only the purpose and price, leaving the agent unable to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter is named 'payload' with a '{}' default, which is opaque. The phrase 'from text' weakly implies payload holds the input text, but nothing clarifies whether it is raw text, JSON, or something else.
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 and resource: 'Extract top keywords/phrases from text.' That distinguishes it reasonably well from siblings like summarize, classify, and sentiment, though it does not explicitly contrast with them.
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 guidance on when to choose this tool over siblings such as summarize or classify, and no preconditions or exclusions are stated. The agent must infer usage from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all paid routes with prices (USDC, Base).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. 'List' implies a read-only enumeration and the currency/network detail is genuinely useful, but it does not say whether invoking it is itself free or paid, whether authentication is required, or how results are ordered or bounded.
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 short sentence with the resource and pricing context front-loaded and no filler. 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 zero-argument list tool with no output schema, the description should say what a 'route' is and roughly what the returned entries contain. It gives currency and chain but leaves the shape of the response and the meaning of 'route' undefined.
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 nothing for the description to disambiguate beyond what the schema already shows. Baseline 4 applies; no misleading parameter claims are made.
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 ('List') and resource ('all paid routes with prices'), plus the denomination and network (USDC, Base). The term 'routes' is domain jargon not explained, but no sibling tool overlaps this space, so an agent can identify it from the name and description alone.
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 only implied: an agent would infer it should call this to discover what routes exist and what they cost. There is no explicit when-to-use statement, no prerequisites, and no mention of what to do with the result or when another tool would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a structured outline from a topic or document. Price: $0.004 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full disclosure burden. It does add genuinely useful non-schema context — the tool is paid, costing $0.004 USDC on Base via x402 — which is exactly the kind of behavioral fact structured fields do not convey. However, it says nothing about output format, outline depth, length, or failure behavior, leaving significant gaps for a generative 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?
Two short sentences with the core action front-loaded and the cost disclosure following. No filler or repetition, though the pricing sentence is somewhat tangential to correct 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 generative tool with no annotations, no output schema, and an opaque single parameter, the description should explain input shape and expected output structure. It covers the action and the cost but not how to format the payload or what the returned outline looks like, so an agent cannot call it confidently without guessing.
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?
There is a single parameter, "payload", with 0% schema description coverage and a bare default of "{}". The description only obliquely hints at its contents ("a topic or document") without stating whether it is raw text, a topic string, a URL, or a JSON envelope — a real ambiguity given the stringified-JSON default. It adds marginal meaning over the schema rather than compensating for the coverage 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 gives a specific verb plus resource: "Build a structured outline" and names its input sources (a topic or a document). An agent can tell this is an outlining/structuring tool rather than a summarizer or rewriter. It stops short of explicitly distinguishing itself from siblings like summarize or rewrite.
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 guidance, no exclusion rules, and no named alternative among the many text-processing siblings (summarize, rewrite, keywords, classify). Only the implicit hint that the input may be either a topic or a document is offered, leaving the agent to infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite text in a target tone/style, return clean prose. Price: $0.004 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add real context by disclosing a paid x402/Base transaction at $0.004 USDC, but it never says how payment is authorized, what happens on a failed or unpaid call, whether text length is bounded, or what the response looks like. The one genuinely useful disclosure (cost and payment rail) is left without operational detail.
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 the capability statement front-loaded ahead of the pricing note; nothing is padded or redundant. It is efficient, though the pricing sentence would earn its place better if it also explained how to satisfy the payment requirement.
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 whose only input is an undocumented JSON-in-string payload and which has no annotations or output schema, the description leaves too much unresolved: no payload shape, no return format, no payment mechanics. The pricing disclosure is welcome but does not compensate for the missing invocation contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter is an opaque string named "payload" defaulting to "{}", which gives no hint of its internal structure. The description implies that source text and a target tone exist somewhere but never maps them to payload fields, so an agent cannot construct a valid call from this definition alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ("Rewrite text") plus the transformation goal ("target tone/style" and "clean prose"), which is enough to distinguish it from siblings like summarize, classify, or sentiment. It stops short of explicitly contrasting itself with those neighbors, so it is clear but not sibling-differentiated.
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 guidance on when to choose this tool over summarize, dub, or the other text siblings, and no stated prerequisites or exclusions. The only usage-adjacent information is the price line, which tells the agent nothing about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a URL to a PNG screenshot URL. Price: $0.01 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does add one important trait beyond the name: the operation costs $0.01 USDC on Base via x402, which is genuine payment/auth context. However, it discloses nothing about latency, rate limits, URL validity requirements, or whether the returned screenshot URL is temporary or persistent.
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 core action and immediately followed by the cost. No filler or redundant restatement of the tool name.
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 this is close, and it usefully states the return value type (a screenshot URL) despite having no output schema. But the undocumented opaque 'payload' parameter is a meaningful gap that the description does not close.
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?
There is a single parameter 'payload', a string with default '{}' and 0% schema description coverage, so the schema explains nothing. The description implies a URL is provided but never states that the URL belongs inside 'payload' or what JSON shape it should take, leaving a real ambiguity for the caller.
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 ('Render a URL to a PNG screenshot URL'), making the input and output type immediately clear. No sibling tool in the list does screenshots, so no explicit differentiation is required, though none is offered for the closest analog (fetch).
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 guidance on when to use this versus alternatives like 'fetch', which could plausibly retrieve URL content. No preconditions, exclusions, or failure conditions are mentioned, leaving the agent to infer context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify text sentiment (positive/neutral/negative + score). Price: $0.003 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does disclose one important behavior: this is a paid call at $0.003 USDC on Base via x402. However, it never explains how payment is authenticated (header, wallet, retry flow), whether calls fail without payment, or what the response body looks like. Useful but incomplete disclosure.
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 with the capability front-loaded and no filler. The second sentence is short enough to earn its place despite only covering pricing.
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, but with no annotations, no output schema, and an undocumented 'payload' parameter, the description leaves the critical input contract unexplained while giving only partial return information. A one-line example of the payload contents would have closed the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter is an opaque string named 'payload' defaulting to '{}'. The description never says that the input text must be JSON-encoded inside that payload or what keys are expected, so an agent cannot reliably construct the call from either schema or description.
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 and resource ('Classify text sentiment') and names the exact output labels (positive/neutral/negative + score), which separates it from vague siblings like classify or detect. It stops short of explicitly distinguishing itself from the generic 'classify' sibling, so a 4 rather than 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?
There is no when-to-use guidance at all – nothing says when sentiment analysis is preferred over the sibling 'classify' or 'tokenverdict' tools, and no prerequisites are stated. The price sentence is cost information, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize long text into key points (<=140 chars out). Price: $0.002 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add genuinely useful behavior: a hard output cap and a concrete cost/payment rail ($0.002 USDC on Base via x402). It omits input length limits, what happens on oversized input, failure modes, and how payment authorization is actually performed.
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 padding, with the functional contract front-loaded and cost appended. Every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter text utility the description covers purpose, output bound, and price, which is reasonable. However, for an x402-paid tool with an opaque 'payload' parameter and no output schema, the payment flow and input format remain underspecified.
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 0% and the single parameter is an undescribed 'payload' string defaulting to '{}', which is ambiguous between raw text and serialized JSON. The description partially compensates by implying the input is the long text to be summarized, but it never resolves the JSON-versus-plain-text ambiguity or the expected size.
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 (summarize long text into key points) plus an explicit output constraint (<=140 chars). It does not distinguish itself from the nearest siblings rewrite/outline/classify, so an agent gets no routing signal from the description alone.
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 when-to-use or when-not-to-use guidance and no alternatives named, even though rewrite, outline, and classify plausibly overlap. The only implicit cue is 'long text', which 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.
Grade a token A-F from live DEX liquidity, 24h volume, age and pairs; returns score, verdict line and roast. Price: $0.02 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the cost ($0.02 USDC), the payment rail and chain (Base via x402), where the underlying data comes from (live DEX liquidity/volume/pairs), and what the response contains. It stops short of covering failure modes for unknown or illiquid tokens and whether results are cached or rate-limited.
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 compact sentences, zero filler. The capability statement is front-loaded and the commercial terms trail it, which is the right ordering for an agent deciding whether to call.
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 adequately covers return values and cost. But the only input is undocumented in both schema and description, so an agent cannot construct a correct call from the definition alone.
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 single parameter is an opaque string named 'payload' with a default of '{}' and zero schema description coverage. The description never mentions the parameter, its name, or what belongs inside it — presumably a token address or symbol, but the agent must guess. This is the definition's biggest hole.
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 (grade), a specific resource (a token), the exact output scale (A-F), and the signals used (DEX liquidity, 24h volume, age, pairs). The return contents (score, verdict line, roast) are also named, so an agent knows precisely what it gets back. No sibling tool in the list overlaps, so no differentiation is needed.
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 — call it when you need an assessment of a token — but the description never says when to prefer it over doing analysis another way, nor what preconditions must hold (e.g. the token must be on a supported chain with DEX pairs). The pricing sentence gives cost context but is not when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe an audio URL to text. Price: $0.01 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden. It does earn credit for disclosing the payment model ($0.01 USDC on Base via x402), which is a real behavioral trait an agent must know before calling, but it omits everything else material: whether the URL must be publicly reachable, supported formats, timeout/processing behavior, and what is returned.
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 core action and followed by the cost. Nothing is padded or redundant; the only criticism is that the brevity leaves required operational detail unstated rather than that words are 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?
With no annotations, no output schema, and a 0%-documented opaque payload parameter, the description should explain payload construction and expected return. It covers purpose and price only, leaving the agent unable to assemble a correct invocation for a paid, irreversible 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 description coverage is 0% and the single parameter is an opaque 'payload' string defaulting to '{}', yet the description never explains how the audio URL is placed into that payload. It adds the key semantic hint that a URL is involved, but an agent still cannot construct a valid payload from either structured field alone or the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource (transcribe audio URL to text), which cleanly separates it from siblings such as tts (the inverse direction) and summarize. It stops short of naming any sibling or constraint that would fully disambiguate it, so it is clear but not sibling-differentiating.
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 guidance on when to use this versus alternatives like clip, dub, or tts, nor any stated preconditions (URL accessibility, supported audio formats, length limits). The only contextual signal given is commercial (price), which tells the agent a cost exists but not when the tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Text to speech: text in, audio URL out. Price: $0.008 USDC on Base via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | {} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does add real value by disclosing the payment model ($0.008 USDC on Base via x402), which is critical for an agent deciding whether it can even call the tool. However, it says nothing about input length limits, voice/language options, latency, or failure modes.
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 capability and followed by the return value and cost. Every clause carries information an agent needs; 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?
There is no output schema, and the description compensates reasonably by stating the return is an audio URL. But the opaque payload parameter combined with zero annotations means an agent still lacks the call format and any operational constraints, leaving the definition thin for a tool with a payment side effect.
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 single parameter is named "payload," typed as a string, defaulting to "{}", with 0% schema coverage. The description's "text in" hints that the text lives inside payload but never explains the format — raw text versus a JSON string with fields like text/voice. An agent would have to guess the encoding, which is a significant gap for a 0%-coverage 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 transformation ("Text to speech") with explicit input and output ("text in, audio URL out"), which distinguishes it from reverse-direction siblings like transcribe and from text-transform siblings like rewrite or summarize. It stops short of naming an alternative, so it doesn't earn 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?
There is no when-to-use guidance, no mention of when to prefer dub or transcribe instead, and no prerequisites stated. The only contextual signal is pricing, which tells an agent nothing about tool selection. Usage is inferable only from the name.
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.
tokenverdictai-batchclassifyclipdetectdubfetchkeywordslist_pricesoutlinerewritescreenshotsentimentsummarizetranscribetts34 pay-per-call AI and data tools over x402; USDC on Base; no API keys.
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
Pay-per-call agent tools over x402 (USDC on Base) — no signup or API key.
Pay-per-call AI infra for agents: DeFi market data, LLM inference, STT/TTS. x402 v2, USDC on Base.
Add one secure layer between your agents and this server.