Which integrations are available for this server?

Supports x402 payments in USDC on Solana mainnet for paid tools, allowing agents to pay per request without an account or API key.

How do I use qrcode-pub-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@qrcode-pub-mcp make a QR code for https://example.com" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

qrcode-pub-mcp

by AgentiLoop

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

qrcode-pub-mcp

🤖 Built by the makers of Agent!, an autonomous macOS agent. 🌐 agentiloop.ai

MCP server for QRCode.Pub tools, runnable with one command and no API key:

Tool	What it does	Price
`qr_code`	QR code image (PNG or SVG) for any text or link — returned inline plus a stable image URL	free
`page_to_markdown`	Fetch a public web page → title, description, clean Markdown, links (deterministic, no model call)	$0.01 USDC via x402
`page_metadata`	Page metadata: title, description, canonical, language, OpenGraph/Twitter cards, icons, JSON-LD	$0.005 USDC via x402
`host_file`	Upload a file (≤ 5 MB: png, jpeg, webp, gif, pdf, json, txt, md, csv) → public URL `https://qrcode.pub/f/<id>` for 30 days	$0.01 USDC via x402

This package is a dependency-free stdio bridge (Node 18+, ~60 lines) to the hosted Streamable-HTTP server at https://qrcode.pub/mcp. Clients that speak Streamable HTTP natively can skip the bridge and use that URL directly.

Install

npx -y github:AgentiLoop/qrcode-pub-mcp        # runs the stdio bridge

Claude Code

claude mcp add qrcode-pub -- npx -y github:AgentiLoop/qrcode-pub-mcp
# or, no bridge:
claude mcp add --transport http qrcode-pub https://qrcode.pub/mcp

Claude Desktop / Cursor / Windsurf / Cline (stdio)

{
  "mcpServers": {
    "qrcode-pub": {
      "command": "npx",
      "args": ["-y", "github:AgentiLoop/qrcode-pub-mcp"]
    }
  }
}

Cursor / VS Code / any Streamable-HTTP client (no bridge)

{
  "mcpServers": {
    "qrcode-pub": { "type": "http", "url": "https://qrcode.pub/mcp" }
  }
}

Verify

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y github:AgentiLoop/qrcode-pub-mcp

Related MCP server: @melis-ai/x402-tools-mcp

Paid tools and x402

The three paid tools cost cents, paid in USDC with the open x402 protocol (v2, scheme exact) on Base (eip155:8453) or Solana mainnet. No account, no key, no subscription:

Call the tool without payment → the result is isError: true with structuredContent.paymentRequired (the full x402 accepts list: network, asset, amount, payTo).
Sign one entry with any x402 client (e.g. @x402/fetch, x402-axios, or the agent's own wallet) and call the tool again with the base64 payment payload as payment.
The server verifies and settles through the facilitator and returns the result; a 4xx answer is never charged.

The same endpoints are plain HTTP for agents that prefer fetch + x402 middleware: GET /x402/extract?url=…, GET /x402/meta?url=…, POST /x402/store. Catalog: https://qrcode.pub/x402, OpenAPI: https://qrcode.pub/openapi.json.

Environment

Variable	Default	Purpose
`QRCODE_PUB_MCP_URL`	`https://qrcode.pub/mcp`	remote endpoint
`QRCODE_PUB_MCP_TIMEOUT_MS`	`60000`	per-request timeout

License

MIT — the bridge is open source; the hosted service terms are at https://qrcode.pub/.

Available Tools

4 tools

host_fileHost a file at a public URL for 30 days ($0.01/call)A

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
`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

TDQS

A4.4/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

page_metadataWeb page metadata ($0.005/call)A

Read-only

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.

TDQS

A3.5/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

page_to_markdownWeb page → Markdown ($0.01/call)A

Read-only

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.

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.

qr_codeQR code image (free)A

Read-onlyIdempotent

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
`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

TDQS

A4/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Oct 16, 2026
- First observedhost_file
- First observedpage_metadata
- First observedpage_to_markdown
- First observedqr_code

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-10-16 23:10 across 4 tools

Disambiguation4/5

qr_code and host_file are clearly distinct, and page_to_markdown vs page_metadata differ by output (clean Markdown vs structured metadata/OG tags). The two page-fetching tools overlap in the fetch step and could be momentarily confused, but their return contracts are different enough to guide selection.

Naming Consistency4/5

All names use snake_case (qr_code, page_to_markdown, page_metadata, host_file), which is consistent. The verb/noun style varies a bit (noun-only qr_code, noun_to_noun page_to_markdown, verb_noun host_file), but each name is readable and predictable.

Tool Count4/5

Four tools is a compact, well-scoped set for a QR generation plus file-hosting/page-fetching utility. Slightly thin, but each tool earns its place and nothing looks redundant.

Completeness3/5

Generation (qr_code), fetching (page_to_markdown, page_metadata) and upload (host_file) are covered, but host_file returns a delete token with no corresponding delete tool, leaving a dead end for cleanup. No QR decoding or content-size/format management operations either.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

x402-mcp-tools A
io.sslip.249.111.77.187
Pay-per-call MCP tools via x402 (USDC on Base): QR codes, images, text analysis, web fetch.
Image & Video Processing Web Scraping Research & Data
41
https://mcp.187.77.111.249.sslip.io/mcp
QRCode.Pub tools A
pub.qrcode
Free QR code images; paid web page → Markdown, page metadata and file hosting via x402 (no API key).
Image & Video Processing Web Scraping Cloud Storage
41
https://qrcode.pub/mcp
Benchline A
io.github.fabwaseem
Open-source developer, PDF, image, SEO and security tools over a stateless HTTP MCP server. No key.
Developer Tools Image & Video Processing Security
821
https://benchline.fabwaseem.com/mcp
botoi-mcp B
io.github.XogZ3
49 developer tools via MCP: DNS, WHOIS, IP lookup, JWT, hashing, QR, and more.
Developer Tools Networking & Infrastructure
492
https://api.botoi.com/mcp

Related MCP Servers

mcp-iteratools
fredpsantos33
A
license
Not graded
quality
F
maintenance
Multi-tool API for AI agents with MCP support: image generation (Flux), web scraping, TTS, OCR, QR codes, weather, crypto, PDF, screenshots, and more. Pay-per-use with x402 protocol.
Updated 8 months ago (2026-03-04 08:07 UTC)
7 npm
1
MIT
@melis-ai/x402-tools-mcp
RAG Systems Web Scraping Autonomous Agents
mizukaizen
A
license
B
quality
F
maintenance
An MCP server providing 22 pay-per-call utility tools for AI agents (scrape, validate, embed, store, moderate, notify, convert, prevent loops) without accounts or API keys, using USDC payments via the x402 protocol.
Updated 4 months ago (2026-06-23 09:10 UTC)
17
38 npm
1
MIT
ImagePay MCP
Image & Video Processing AI & Machine Learning
neuralmint
A
license
Not graded
quality
B
maintenance
Enables MCP-capable agents to call 40 paid API tools—including OCR, PDF, image, tabular, and web utilities—by paying per request via x402 micropayments on Base, with no API key, subscription, or signup required.
Updated 2 months ago (2026-08-26 15:38 UTC)
MIT
world.agentindex/x402
Search Text Summarization Payments & Billing
comallagency
A
license
Not graded
quality
B
maintenance
Enables MCP clients to call pay-per-use tools for search, PDF processing, web reading, extraction, summarization, fact-checking, translation, jobs, and discovery, with each call paid in USDC on Base via x402 and no API key or account required.
Updated 5 days ago (2026-10-20 17:19 UTC)
AGPL 3.0

qrcode-pub-mcp

Install

Claude Code

Claude Desktop / Cursor / Windsurf / Cline (stdio)

Cursor / VS Code / any Streamable-HTTP client (no bridge)

Verify

Paid tools and x402

Environment

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers