Pay-per-call MCP tools over x402 (USDC/Solana): LLM, utilities, x402 market and model prices.
Scored across 17 tools
Most tools have clearly distinct domains: text processing, lookups, prices, reviews, and x402 functions are separated. There is mild overlap between the LLM text tools (answer, summarize, extract, translate) and between the two review tools, but names and descriptions are clear enough to avoid serious misselection.
All tools share the paid_ prefix and use snake_case, which gives a strong visual and structural consistency. However, the stem pattern mixes pure verbs like convert and summarize with noun phrases like crypto_price and repo_health, so it is not a fully uniform verb_noun convention.
At 17 tools, the server is slightly above the ideal 3-15 range, but the count is justified for a multi-purpose paid API marketplace. Each tool is a distinct paid capability rather than a redundant variation, so the set does not feel bloated.
The server covers a broad range of useful stateless utilities: text transformation, lookups, code and config review, pricing intelligence, and x402-specific features. It lacks obvious adjacent capabilities like billing/balance checks or embeddings, but for its stated purpose the core surface is reasonably complete.
Stateless answer API. Answers the buyer's question with a language model; NO local or server context is used. Returns only the answer text. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The question or prompt to answer | |
| max_tokens | No | Optional max answer tokens (64-1024, default 512) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond that: the API is stateless, uses no local/server context, returns only the answer text, and is paid per call. This is useful disclosure for an agent deciding whether to invoke it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The most important trait ('stateless') is front-loaded, and each sentence adds distinct useful information: operation, behavior, return value, and cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is complete. It covers what the tool does, its statelessness, its return value, and its cost. No output schema exists, but 'Returns only the answer text' sufficiently describes the response shape for this 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 fully documents both parameters. The description does not add much parameter-level meaning beyond reinforcing that the question is answered without context, which is acceptable but not a boost above the 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 names a specific verb ('answers') and resource ('the buyer's question with a language model'), and the stateless/no-context phrasing distinguishes it from the sibling tools. An agent can tell this is a standalone generation API rather than a lookup, conversion, or routing tool.
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 when to use the tool: for a direct language-model answer with no local or server context. However, it never names alternatives or explicitly says when not to use it, such as when contextual information is required. Usage context is present but only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stateless review of an infrastructure configuration (YAML, Docker Compose, Kubernetes, Terraform) provided by the caller: risks, hardening and concrete fixes. No repository or local context. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional hint: docker-compose | kubernetes | terraform | yaml | |
| config | Yes | The configuration text to review |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context beyond those: the operation is stateless, has no repository/local context, and is paid per call. This is transparent without contradicting 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?
Two tight sentences convey purpose, scope, statelessness, output, and cost with no filler. The core verb and resource are front-loaded, and every clause adds useful 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 low-complexity tool with two well-documented parameters and safety annotations, the description is complete. It covers what the tool does, what it returns at a high level, constraints on context, and the paid nature, so an agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('config' and 'kind'). The description adds little beyond confirming the config is provided by the caller and listing supported config kinds, which mostly mirrors the schema's own optional hint values.
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 action ('review'), a specific resource ('infrastructure configuration'), and names the supported formats (YAML, Docker Compose, Kubernetes, Terraform). It also states the output (risks, hardening, concrete fixes), making it clearly distinct from generic sibling review tools like paid_review_snippet.
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 gives clear context for when to use the tool: the caller provides configuration text, the review is stateless, and no repository or local context is used. It does not explicitly name alternatives or exclusion criteria, but the scope is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pure-compute data conversion (no network): json_pretty, json_minify, json_to_csv, csv_to_json, base64_encode, base64_decode. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | json_pretty | json_minify | json_to_csv | csv_to_json | base64_encode | base64_decode | |
| data | Yes | Input payload (JSON string, CSV string or plain text) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful beyond-annotation context by disclosing that no network call is made and that each invocation is billed, both of which affect agent decisions.
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 efficient sentence front-loads the core behavior ('pure-compute data conversion'), then enumerates operations and closes with the billing caveat. No filler or redundant restatement.
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, no-network conversion tool with no output schema, the description plus input schema provides the operations, input type, cost expectation, and safety profile. It is slightly thin on what exact output form each op returns, but the operation names make that 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 100%: op and data are fully described in the schema. The description restates the op values and payload types but adds no new parameter-level semantics such as format edge cases or op-specific constraints, so it earns the baseline rather than exceeding it.
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 resource (data conversion) and enumerates six exact operations (json_pretty, json_minify, json_to_csv, csv_to_json, base64_encode, base64_decode), making the tool's scope unambiguous. It also distinguishes itself from the paid_* sibling tools by narrowing to pure conversion rather than answering, hashing, summarization, or translation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pure-compute data conversion (no network)' and the operation list give clear context for when to use this tool: whenever the agent needs one of these deterministic local conversions. It does not explicitly name alternative tools or exclusion cases, so it falls short of fully explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live crypto token prices (USD or other vs_currency) for one or more coins via CoinGecko. Read-only, no local context. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Comma-separated CoinGecko ids or symbols, e.g. bitcoin,ethereum,solana | |
| vs_currency | No | Quote currency, default usd |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful extras beyond the annotations: 'Live', 'no local context', and 'Paid per call' — useful behavioral context for an agent deciding whether to invoke it.
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-load the core behavior and then add only non-redundant, decision-relevant traits: live data, CoinGecko source, read-only, no local context, and paid per call. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two fully documented parameters and no required fields, the description plus annotations are sufficient. The lack of an output schema is slightly mitigated by the phrase 'prices', which communicates roughly what the tool returns, though an explicit return-structure note would make it complete.
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%, with clear parameter descriptions and an example for ids. The description mostly restates what the schema already says about vs_currency and multi-coin support, without adding new syntax, defaults, or format details. Baseline 3 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 uses a specific verb ('get prices') and a specific resource ('crypto token prices via CoinGecko'), clarifying that it returns live market prices for one or more coins. It is clearly distinct from siblings like paid_convert or paid_model_price because it narrows scope to token price quotes.
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 use case: fetch live crypto prices in a chosen quote currency. However, it does not explicitly say when not to use it or point to alternatives, such as paid_convert for conversions. The usage context is clear but not fully differentiated from related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CVE / vulnerability lookup via OSV.dev. Give a CVE id (e.g. CVE-2021-44228) or a package+version. Returns severity, summary, affected ranges and fixed versions. Read-only, no local context. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| cve | No | CVE id, e.g. CVE-2021-44228 | |
| package | No | Or package name (e.g. log4j-core) | |
| version | No | Optional version to check against the package | |
| ecosystem | No | Ecosystem for package queries (e.g. Maven, npm, PyPI, Go) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds the critical 'Paid per call' cost signal and 'no local context' constraint, which are not in annotations. It does not contradict any annotation and provides useful operational context beyond what structured fields offer.
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, front-loaded with the core purpose and immediately followed by usage examples and expected returns. Every phrase earns its place—no redundancy, no fluff. The critical constraints (read-only, paid) are integrated naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates by listing return fields (severity, summary, affected ranges, fixed versions). It also covers the input alternatives and cost implications. Minor omissions like error handling or pagination are not critical for a lookup tool. Overall, it provides enough for an agent to call the tool 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 parameters are documented. However, the description adds interpretive value by explaining the either/or usage pattern: 'Give a CVE id (e.g. CVE-2021-44228) or a package+version.' This clarifies that cve and package+version are alternative query modes, which is not evident from the flat schema. It also explains the output fields, which are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'CVE / vulnerability lookup via OSV.dev' with specific input formats (CVE id or package+version) and expected outputs (severity, summary, affected ranges, fixed versions). This distinguishes it from siblings like paid_dns_intel or paid_crypto_price, which serve different domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: 'Read-only, no local context. Paid per call.' This informs the agent about cost and safety. It doesn't explicitly name alternatives or exclusion criteria, but the tool's purpose is so specific that no ambiguity exists. The 'Give a CVE id or a package+version' clause implies when to use which parameter combination, which is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DNS intelligence for a domain via DNS-over-HTTPS: A, AAAA, MX, TXT, NS and CNAME records. Read-only, no local context. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond those annotations: the query protocol (DNS-over-HTTPS), the external scope ('no local context'), and the per-call cost. This is valuable for an agent deciding whether to invoke 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 that front-loads the core purpose and record types, then adds key behavioral constraints. Every element earns its place with no filler or 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 simple one-parameter lookup tool, the description covers the domain target, the DNS record types returned, the transport, the read-only nature, and the paid cost. It does not detail response format or failure behavior, but no output schema exists and the tool is simple enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, 'domain', and the schema already describes it fully with an example ('example.com'). Schema description coverage is 100%, so the description adds little beyond what the schema provides. Baseline 3 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 clearly states the tool's purpose: DNS intelligence for a domain via DNS-over-HTTPS, and enumerates the exact record types returned (A, AAAA, MX, TXT, NS, CNAME). This distinguishes it from sibling tools like paid_cve_lookup or paid_gtin_lookup without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context ('via DNS-over-HTTPS', 'no local context', 'paid per call') but never explicitly states when to prefer this tool over alternatives or when not to use it. Sibling tools are unrelated, so no direct comparison is needed, but usage guidance remains implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stateless structured extraction. Sends ONLY the provided text (and optional schema) and returns a JSON object. No local context is used. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to extract data from | |
| schema | No | Optional target schema/description for the JSON output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context: statelessness, no local context usage, exclusive reliance on provided text, and a per-call payment model, none of which are captured in 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 two tight sentences with no fluff. The most important qualifier ('Stateless structured extraction') is front-loaded, and every sentence communicates a distinct fact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers input scope, statelessness, return type, and billing. It could say more about error behavior or the exact JSON shape, but nothing critical is missing for correct 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 schema already documents both parameters. The description only confirms that the schema parameter is optional, adding minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Stateless structured extraction,' which names a specific verb and resource. It clearly distinguishes this from siblings like paid_summarize or paid_answer by emphasizing that only the provided text and optional schema are sent, and a JSON object is returned.
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 states how the tool behaves but does not say when to choose it over alternatives like paid_summarize or paid_convert. No explicit usage conditions, exclusions, or sibling routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EAN/UPC/GTIN barcode lookup via Open Food Facts: returns product name, brand, quantity and Nutri-Score when available. Read-only, no local context. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| gtin | Yes | Barcode (8-14 digits) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the external source (Open Food Facts), specific return contents, and the cost signal ('Paid per call'). This goes beyond the annotations with useful behavioral context, and there is no contradiction.
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 efficient sentences: the first front-loads the primary purpose and return value, the second packs read-only, context, and cost. 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 simple one-parameter lookup with safety annotations present, the description covers purpose, returned fields, external source, and cost. It omits not-found behavior or output format, but with no output schema and low complexity, these gaps are minor.
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 input schema already documents the only parameter (gtin) as 'Barcode (8-14 digits)', giving 100% schema coverage. The tool description does not add any further parameter-specific detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('lookup') and resource ('barcode via Open Food Facts'), and lists the returned fields (product name, brand, quantity, Nutri-Score). The sibling list contains no other barcode/product lookup tool, so it clearly distinguishes 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?
Usage is implied: if you need product data from an EAN/UPC/GTIN barcode, you would use this tool. However, it does not explicitly state when to use it vs. alternatives, nor does it name any alternative. 'Read-only, no local context' provides context but not explicit selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministic hash of a text string (sha256 default; sha512, sha1, md5). Pure compute, no network. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| algo | No | sha256 (default) | sha512 | sha1 | md5 | |
| text | Yes | Text to hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description goes beyond these by adding 'deterministic,' 'pure compute, no network,' and 'paid per call,' which provide useful operational context. No contradiction with 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 exceptionally concise: three short clauses that immediately convey purpose, algorithms, offline behavior, and cost. Every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple pure-compute tool with rich annotations and fully documented parameters, the description is nearly complete. The only minor gap is that it does not explicitly state the return format (e.g., hex-encoded digest), and there is no output schema to compensate.
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 restates the algorithm options and default already present in the schema but adds no new parameter-level details such as encoding, formatting, or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action—hashing a text string—and the supported algorithms. It is specific enough to distinguish paid_hash from the sibling paid_* tools, none of which are hash utilities.
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 when to use this tool: whenever a deterministic hash of a text string is needed. It does not explicitly state alternatives or conditions to avoid this tool, though 'pure compute, no network' gives some context about its scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LLM routing catalog: given an optional need keyword and a budget, returns provider:model options with sourced prices (USD per 1M tokens), free-tier flags and signup links, cheapest first. Public catalog data; no local context. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| need | No | Optional keyword matching provider id or model id (e.g. code, llama, qwen) | |
| limit | No | Max results (1-25, default 10) | |
| free_only | No | Only free-tier models/providers | |
| max_price_usd | No | Optional cap on blended price (input+output USD per 1M tokens) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: results are sourced, ordered cheapest first, include free-tier flags and signup links, and calls are paid per use. It also notes that the tool has no local context, which is valuable for an agent deciding on data 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 description is a single, well-structured sentence that front-loads the core purpose ('LLM routing catalog') and then packs relevant details into the rest. Every clause adds information: input flexibility, output fields, pricing unit, sorting, public data scope, and cost. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only catalog tool with all optional parameters and complete schema coverage, the description provides sufficient context. It explains what the tool returns, the ordering, the data source, and the billing implication. Even without an output schema, an agent has enough to invoke the tool and interpret the result shape at a high level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful semantic context beyond the schema by clarifying that results are sorted 'cheapest first' and that the price unit is USD per 1M tokens, which helps the agent interpret the budget parameter. It also maps the 'need' keyword and budget to the optional parameters in an intuitive way.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an 'LLM routing catalog' and states that it returns provider:model options with prices, free-tier flags, and signup links. The verb 'returns' and resource are specific. It does not explicitly differentiate itself from the closely related sibling paid_model_price, though the catalog/routing framing implies a broader search role.
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 conveys when it is appropriate to call the tool: when you have a need keyword and/or budget and want provider:model options. It also clarifies that data is public and that calls are paid, which helps an agent decide whether to invoke it. However, it does not state when to choose an alternative like paid_model_price or provide explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LLM price oracle with official sources: input/output USD per 1M tokens for a provider:model plus the estimated cost of a call. Sourced from a verified price table; if there is no official source the values are null (never invented). Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model id, e.g. gpt-oss-120b, deepseek-chat | |
| provider | Yes | Provider id, e.g. groq, deepseek, anthropic | |
| tokens_in | No | Optional input tokens to price a call | |
| tokens_out | No | Optional output tokens to price a call |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable context: values are null if no official source exists, and prices are never invented. It also states 'Paid per call,' which is a behavioral trait not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste. The core purpose is front-loaded, the source credibility is stated, and the null behavior is disclosed. 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?
For a read-only lookup tool with 100% schema coverage and no output schema, the description covers the essential behavior: what it returns, the source, the null policy, and the cost model. It doesn't describe the exact response structure, but that's acceptable given no output schema and the simplicity of the 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 all four parameters. The description adds the meaning of tokens_in/tokens_out as 'to price a call' and clarifies the output format (USD per 1M tokens), but doesn't add much beyond the schema. Baseline 3 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 clearly states the tool is an LLM price oracle that returns official input/output USD per 1M tokens for a provider:model plus estimated call cost. It distinguishes itself from siblings by specifying the exact resource (LLM pricing) and the source (verified price table).
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 when to use this tool: when you need official LLM pricing or call cost estimation. It doesn't explicitly name alternatives or exclusions, but the sibling list shows other paid_* tools with different purposes, so the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public GitHub repository health check: stars, archived/maintenance status, license, last push, open issues/PRs, topics. Read-only, no local context. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | owner/name, e.g. anomalyco/opencode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive traits. The description adds valuable non-annotation behavioral context: 'Paid per call' and the explicit scope 'Public GitHub repository'. 'Read-only, no local context' restates annotations but reinforces them; no contradictions exist.
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: the purpose and key data fields come first, followed by two short trait sentences. Every sentence earns its place; there is no fluff or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single well-documented parameter and rich annotations, the description covers purpose, scope, safety profile, and cost. Although there is no output schema, the enumerated fields (stars, archived/maintenance status, license, last push, open issues/PRs, topics) effectively communicate expected return content. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the 'repo' parameter is fully documented in the schema with format and example (owner/name, e.g. anomalyco/opencode). The description adds no further parameter-level detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Public GitHub repository health check', and enumerates the exact data points returned (stars, archived/maintenance status, license, last push, open issues/PRs, topics). This clearly distinguishes it from all sibling paid_* tools, none of which target GitHub repository health.
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 gives clear context: it applies to public GitHub repos only, is read-only, and has no local context. It implies when to use it (when you need public repo health data) and implicitly warns not to use it for local repositories, though it does not explicitly name alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stateless code review. Sends ONLY the provided snippet to the model and returns findings (bugs, security, edge cases, fixes). No repository or local context is used. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code snippet to review | |
| focus | No | Optional focus (e.g. security, performance, correctness) | |
| language | No | Optional language hint (e.g. javascript, python) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by disclosing cost behavior ('Paid per call') and operational scope ('Stateless', 'No repository or local context is used'). It also lists the types of findings returned. No contradiction with 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?
Four short sentences, each earning its place: the core action, the input boundary, the no-context caveat, and the cost implication. All critical information is front-loaded.
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 description is sufficient for a simple 3-parameter tool with no output schema: it explains what is sent, what is returned, and what context is absent. A precise output format is not specified, but the listed finding categories give adequate guidance for an agent selecting and invoking the 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 code, focus, and language. The description reinforces that only the code parameter is sent to the model, but it does not add meaningful parameter-level semantics 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?
The description clearly states a specific verb and resource: 'code review' of 'the provided snippet'. It distinguishes itself from siblings like paid_repo_health by emphasizing that no repository or local context is used, and from paid_config_review by targeting code snippets rather than configs.
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 gives clear selection context: use this when you have only a snippet and want stateless review. 'No repository or local context is used' implies when full repo context is needed this tool is not appropriate, though it does not explicitly name an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stateless summarization API. Summarizes ONLY the provided text. No local context is used. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to summarize | |
| max_tokens | No | Optional max summary tokens (64-900, default 600) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'Paid per call', a cost behavior not in annotations, and reinforces statelessness. It does not disclose rate limits, auth needs, or failure modes, but the annotation coverage lowers the required burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences each carry distinct value: statelessness, scope, local-context exclusion, and cost. The most important identity information is front-loaded in the first sentence. No filler or redundancy.
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 2-parameter, stateless tool with full schema coverage and safety annotations, the description covers the essentials: purpose, scope, statelessness, and cost. It omits the return format, but absence of an output schema makes that less critical. Slight gaps around input size limits or errors are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: text and max_tokens are already fully described. The description adds no additional parameter-level meaning, so the baseline of 3 applies per the rubric.
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 a specific verb and resource: it summarizes provided text. The phrase 'ONLY the provided text' specifies scope, and the function is easily distinguished from siblings like paid_answer, paid_extract, and paid_translate. The purpose is unambiguous and immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus the many paid_* siblings. The 'No local context is used' statement implies it is not for context-dependent tasks, but it does not name alternatives or provide selection criteria. Cost is noted, but not as a usage guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stateless translation API. Translates ONLY the provided text into the target language. No local context is used. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to translate | |
| target | No | Target language (e.g. English, Portuguese). Default English. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context beyond those: 'Stateless', 'No local context is used', and 'Paid per call' (cost implication). This gives the agent useful behavioral expectations without contradicting 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?
Four crisp sentences, each carrying distinct information: stateless API type, scope of translation, absence of local context, and billing. The description is front-loaded and contains 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 two-parameter, stateless translation API, the description covers the critical operational facts: scope, statelessness, billing, and target language. It doesn't mention return format, but with no output schema and a self-evident translation result, that gap is acceptable. Sibling differentiation is implicit rather than explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description loosely aligns with the parameters ('provided text' and 'target language') but introduces no additional parameter-level nuances beyond what the schema already documents.
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 exactly what the tool does: 'Translates ONLY the provided text into the target language.' It identifies a specific verb (translates), a resource (provided text), and a target (target language). The 'Stateless' qualifier and 'ONLY' scope help differentiate it from context-aware siblings like paid_llm_route or paid_convert.
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 conveys a clear usage context—stateless translation of a single text—and implies it is not for context-sensitive tasks. However, it never explicitly names alternative tools or gives when-not-to-use guidance, leaving the agent to infer routing from the stateless/context-free clues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-payment readiness/trust check for any x402 service URL: is it reachable, does it return a valid 402 challenge, what are its accepts (network/asset/amount/payTo), is the challenge signable (EIP-712 params), is an input schema present, and a verdict. Read-only probe of PUBLIC URLs only (SSRF-guarded). Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL of the x402 resource to audit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond the read-only/idempotent annotations: PUBLIC URLs only, SSRF-guarded, paid per call, and a verdict. However, it directly contradicts the openWorldHint=false annotation: probing a PUBLIC http(s) URL necessarily accesses the open world. Per the contradiction rule, this dimension scores 1.
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 purpose, then enumerates the audit checks compactly. The final two sentences add unique constraints and cost context with no filler or redundant explanation.
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 only one required parameter and no output schema, the description still tells the agent what the audit examines and that it produces a verdict. Public-URL restriction, SSRF guard, and paid-per-call nature cover the operational context needed to call this 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% and the url parameter already states 'Public http(s) URL of the x402 resource to audit'. The description reinforces the public/schema coverage but adds no new parameter format, validation, or value semantics, so the baseline 3 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 names a specific verb and resource: it audits/pre-payment checks any x402 service URL. It enumerates concrete checks (reachability, 402 challenge, accepts, signability, input schema, verdict), making the tool's role unmistakable and clearly distinct from siblings like paid_x402_market.
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?
'Pre-payment readiness/trust check' gives a clear trigger for when to use the tool, and 'Read-only probe of PUBLIC URLs only' defines the input context. However, it does not explicitly name alternatives or state when not to use this tool, so it falls just short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402 market intelligence: prices of OTHER agents/services across public x402 directories (facilitator Bazaar + x402scan). Optionally filter by keyword, resource type or max price and get the cheapest matching services with prices, plus the market price distribution. Public data only; no local context. Paid per call.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional resource type filter: mcp or http | |
| limit | No | Optional max matches (1-50, default 15) | |
| query | No | Optional keyword matching service, tool, resource or description | |
| max_price_usd | No | Optional maximum price in USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is clear. The description adds context about being public data only and paid per call, but it does not detail what happens with the data (e.g., no caching, rate limits). Since annotations cover safety, the description's contribution is moderate, and a 3 is appropriate.
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 concise and front-loaded with the core purpose, then lists optional filters, and ends with critical notes (public data, paid). It uses 3 sentences with no fluff, and each sentence adds value. It's efficient for an agent to parse.
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?
Given the tool's complexity (4 optional params, no output schema), the description covers the usage context well: it explains what data it returns (prices, cheapest matches, distribution), the public nature, and payment. It lacks explicit mention of error behaviors or rate limits, but for a simple list-filter tool, it's nearly complete.
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%, meaning each parameter (type, limit, query, max_price_usd) already has a description in the schema. The tool description does not add meaningful detail beyond restating the filters (keyword, resource type, max price) that are already in the schema. It's baseline 3 with high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as x402 market intelligence, listing the specific directories (Bazaar and x402scan) and the resource type (prices of other agents/services). It distinguishes itself from siblings like paid_crypto_price and paid_model_price by focusing on market prices of agents/services in x402 directories, which is specific and not redundant.
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 provides clear context on when to use it—for market intelligence on other agents/services in public directories—but does not explicitly state when not to use it or name alternatives. However, the sibling names (e.g., paid_crypto_price, paid_model_price) are distinct enough that an agent can infer the difference, but the description could have explicitly said 'Use this for market prices, not for your own pricing'.
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.
paid_x402_auditpaid_answerpaid_config_reviewpaid_convertpaid_crypto_pricepaid_cve_lookuppaid_dns_intelpaid_extractpaid_gtin_lookuppaid_hashpaid_llm_routepaid_model_pricepaid_repo_healthpaid_review_snippetpaid_summarizepaid_translatepaid_x402_marketProduction-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Pay-per-call MCP tools via x402 (USDC on Base): QR codes, images, text analysis, web fetch.
Add one secure layer between your agents and this server.