Free QR code images; paid web page → Markdown, page metadata and file hosting via x402 (no API key).
Scored across 4 tools
host_file and qr_code target clearly distinct outputs (hosted URL vs QR image), and the two page-fetching tools return different payloads (metadata vs Markdown), so descriptions largely disambiguate them. page_metadata and page_to_markdown still share the same underlying action (fetch a public page), which could cause occasional misselection.
All names use lowercase snake_case with no camelCase mixing, so the surface reads consistently. There is a minor convention shift: host_file is verb_noun while page_metadata, page_to_markdown, and qr_code are noun phrases.
Four tools is a lean but sensible set for a small utility service, and each covers a distinct capability with no filler. It is on the thin side, but nothing feels redundant or missing at the count level.
host_file issues a delete token yet no delete/revoke tool is exposed, leaving an obvious lifecycle gap for hosted files. The page-fetch tools are read-only and coherent, but the overall surface is a grab-bag with no unifying CRUD coverage.
Upload a file (≤ 5 MB; png, jpeg, webp, gif, pdf, json, txt, md or csv) and get a stable public URL https://qrcode.pub/f/ that any agent, tool or browser can fetch for 30 days. Nothing executable is accepted. The answer includes a delete token. Price: $0.01 USDC per call via x402 (USDC on Base or Solana, no account; nothing is charged for a bad input).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional file name (letters, digits, . - _; max 80 chars) | |
| content | Yes | The file: plain text, or base64 when encoding is "base64" (binary types must be base64) | |
| payment | No | x402 payment: the base64 PAYMENT-SIGNATURE value (x402 v2 payment payload signed for one entry of the `accepts` list returned when this tool is called without it). Omit to get the price and payment requirements. | |
| encoding | No | How `content` is encoded (default text) | |
| content_type | Yes | MIME type of the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses retention (30 days), size limit (≤ 5 MB), an allow-list of MIME types, a hard rejection rule (nothing executable), the return of a delete token, per-call pricing ($0.01 USDC via x402 on Base or Solana), and no-charge-on-bad-input behavior. These are exactly the operational facts an agent needs and are not derivable from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and URL result are front-loaded in the first clause, followed by limits, safety rule, and payment terms. It is dense but nearly every clause carries distinct, non-redundant information; the trailing pricing sentence is slightly overloaded but still 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?
There is no output schema, and the description compensates by stating what the answer contains (the public URL and a delete token) and how payment/price negotiation works. For a write tool with a payment gate, this covers the full call lifecycle an agent must handle.
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 five parameters including the payment/encoding flow, and the baseline is 3. The description adds constraint context (5 MB cap, accepted formats, delete token in the response, no charge for bad input) but does not clarify per-parameter syntax beyond what the schema provides.
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 (upload) and resource (a file), plus the concrete outcome (a stable public URL of the form https://qrcode.pub/f/<id> lasting 30 days). This is clearly distinguishable from the sibling utilities page_metadata, page_to_markdown and qr_code without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the trigger condition clear (you need a fetchable public URL for a non-executable file) and explains the two-step payment flow: omit `payment` to get the price and payment requirements, or supply a signed PAYMENT-SIGNATURE. It does not explicitly say when NOT to use it or name an alternative for hosting, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public web page and return its metadata: title, description, canonical URL, language, OpenGraph and Twitter card tags, icons and parsed JSON-LD blocks. Price: $0.005 USDC per call via x402 (USDC on Base or Solana, no account; nothing is charged for a bad input).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) page to fetch | |
| payment | No | x402 payment: the base64 PAYMENT-SIGNATURE value (x402 v2 payment payload signed for one entry of the `accepts` list returned when this tool is called without it). Omit to get the price and payment requirements. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely non-redundant behavior: a per-call price, the x402/USDC payment channel, no account required, and that failed/bad inputs are not charged. It does not discuss rate limits, blocking on pages that refuse bots, or latency, which are relevant for an open-world fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the resource and payload, then the commercial terms. The long return-field list is informative rather than padding. Slightly dense but nothing 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?
No output schema exists, so the description compensates by enumerating the returned fields, and the payment flow is documented across the description and the `payment` schema entry. It stops short of covering failure modes (non-HTML targets, inaccessible pages) that matter for an open-world fetch.
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%, including the two-phase payment contract in the `payment` parameter, so the schema does the heavy lifting. The description adds pricing context but no extra syntax or semantics for `url` or `payment` beyond it. 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 gives a specific verb ('Fetch a public web page') and enumerates the exact return payload (title, description, canonical URL, language, OpenGraph/Twitter tags, icons, JSON-LD). An agent immediately knows what it gets. It stops short of distinguishing itself from the sibling page_to_markdown, which operates on the same resource class.
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/when-not guidance and no mention of the obvious alternative, page_to_markdown, which also targets web pages. The only implicit usage note is that no account is required. An agent must infer from the return-field list whether this or page_to_markdown is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public web page and return its title, description, clean Markdown (scripts, styles, nav chrome removed) and the list of links. No model call, deterministic. Price: $0.01 USDC per call via x402 (USDC on Base or Solana, no account; nothing is charged for a bad input).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) page to fetch | |
| payment | No | x402 payment: the base64 PAYMENT-SIGNATURE value (x402 v2 payment payload signed for one entry of the `accepts` list returned when this tool is called without it). Omit to get the price and payment requirements. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the readOnlyHint/openWorldHint annotations by disclosing that scripts, styles and nav chrome are stripped, that no model call is involved (deterministic), the exact price and chains (USDC on Base or Solana), the x402 no-account model, and that bad input is not charged. That is precisely the extra behavioral context an agent needs before spending money.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what is fetched and returned, followed by the cost/payment terms. No filler and nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so by naming all four returned fields. The paid, no-account x402 flow is fully explained, so an agent can call it correctly on the first attempt.
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, but the description adds real meaning to the payment parameter: the currencies accepted, that no account is required, and the no-charge-on-failure guarantee. The two-step price-then-pay flow is only fully spelled out in the schema, not 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?
States a specific verb and resource ('Fetch a public web page') and enumerates the exact outputs (title, description, clean Markdown, links), which implicitly separates it from the metadata-only sibling page_metadata. It never names a sibling explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose and by the payment flow note ('Omit to get the price and payment requirements'), and 'nothing is charged for a bad input' hints at retry safety. However, there is no explicit guidance on when to choose this over page_metadata or host_file, and no stated preconditions beyond 'public'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a QR code image (PNG or SVG) for any text or link. Free, no account. The answer carries the image and a permanent image URL you can embed or print.
| Name | Required | Description | Default |
|---|---|---|---|
| ecc | No | Error correction (default M) | |
| data | Yes | Text or URL to encode (max 2000 chars) | |
| size | No | Pixels (default 300) | |
| color | No | Foreground hex, e.g. 1a237e (default 000000) | |
| format | No | Image format (default png) | |
| margin | No | Quiet zone in modules (default 4) | |
| bgcolor | No | Background hex, e.g. ffffff |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: no account is needed and the response carries both the image and a permanent, embeddable image URL, which is valuable output-shape information given no output schema exists.
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 tightly written sentences with the core action front-loaded and the value-add (permanent URL, no account) following. Every clause carries information; nothing is redundant.
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 7-param tool with a fully documented schema, the description covers purpose, cost/auth model, and return shape. It omits no critical detail, though it could note size or ECC tradeoffs. Sufficient given the schema does the parameter heavy lifting.
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 7 parameters with defaults, ranges, and enums. The description adds no parameter-level detail beyond the schema, 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?
States a specific verb and resource ('Generate a QR code image') plus the supported formats (PNG or SVG) and the input domain (any text or link). This clearly separates it from siblings like host_file, page_metadata, and page_to_markdown without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'for any text or link,' but the description never states when to prefer this tool over siblings or what conditions make it inappropriate. No exclusions or prerequisites beyond 'Free, no account.' Adequate but leaves routing to inference.
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.
host_filepage_metadatapage_to_markdownqr_codeSearch, URL-to-markdown, change detection, live data, x402 trust tools. USDC pay-per-call.
30-day x402 history, calendar, DNS, RDAP, LEI, URLs, scraping, text, VAT, QR. Pay-per-call USDC.
Generate static QR codes (URL, WiFi, vCard, pixel art) and decode QR images. Codes never expire.
Fetch any URL as clean Markdown or metadata, and buy digital goods via x402 — for AI agents.
Add one secure layer between your agents and this server.
