qrcode-pub-mcp

Web page → Markdown ($0.01/call)

page_to_markdown

Read-only

Convert a public web page into clean Markdown by removing scripts, styles, and navigation. Returns the title, description, and links.

Instructions

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).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "page_to_markdown"
  }
}

Input Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 16, 2026

TDQS

A4.2/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Deploy Server