LLPRO Campus

Make a static QR code that never expires (text, link or stamp id)

qr_code_make

Read-onlyIdempotent

Make a QR code that never expires. Send ONE of: text (plain text, or a link), url (a link), or stamp_id (a Countersign stamp id, so the printed code opens that stamp's verify page). Get back the code as SVG and PNG, plus a signed, dated record of exactly what was made. Free, no sign-up, 500 codes a day per caller. Size: up to 300 characters, and at most 271 bytes at level L, 213 at M, 151 at Q, 119 at H. The code is static: it holds the text itself, goes through no LLPRO server when scanned, cannot be switched off and is never counted. We store nothing; the signed record holds a salted hash, not your text. Links to private, local or unresolvable addresses are refused; this is an address check, not a phishing or malware check. No tracking, no short links, no logos, no styling.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "qr_code_make"
  }
}

Input Schema

Name	Required	Description	Default
`url`	No	A public http(s) link to encode, ASCII only (percent-encode anything else). Port 80 or 443 only.
`text`	No	Plain text to encode. Active schemes (javascript:, data:, file:, tel:, sms:, mailto:, WIFI: and similar) are refused.
`scale`	No	PNG pixels per module (a code is 25 to 65 modules wide with its quiet border).
`format`	No		both
`ec_level`	No	Error correction: L 7%, M 15%, Q 25%, H 30% of the code can be damaged and still scan.	M
`stamp_id`	No	A Countersign stamp id such as cs_28d71a5f8f427055. The code opens its verify page.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description nonetheless adds substantial non-obvious behavior: the code is static and never contacts an LLPRO server, it cannot be switched off or counted, nothing is stored but a salted hash, the address check is not a malware check, and the output is SVG+PNG plus a signed dated record. That is a strong addition, but it omits any statement about what happens on rate-limit exhaustion or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single dense paragraph, but front-loaded: purpose, then input modes, then outputs, then limits and refusals. Every clause carries information; the trailing "no tracking, no short links, no logos, no styling" is compressed and earns its place as a scope boundary.

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 6-parameter, zero-required tool with no output schema, it covers return artifacts, capacity constraints, refusals and storage behavior well. The one gap is the one-of contract: the schema permits an empty or multi-field object, and the description says "Send ONE of" without stating what happens if zero or several are supplied, nor why zero parameters are formally allowed.

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 83%, so the baseline is 3, and the description earns above that by linking ec_level to concrete payload capacity (271 bytes at L down to 119 at H) — a coupling the schema's percentage description does not convey — and by clarifying that stamp_id encodes a verify page rather than arbitrary content.

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?

The description opens with a specific verb and resource ("Make a QR code") and immediately scopes it as static and non-expiring. It enumerates the three mutually exclusive input modes (text, url, stamp_id) and explains the stamp_id variant's outcome ("opens that stamp's verify page"), which is enough to separate it from countersign_stamp/countersign_verify siblings.

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?

"Send ONE of: text, url, or stamp_id" plus the size/byte ceilings, the refusal rule for private/local addresses, and the 500/day quota give clear conditions for correct invocation. What is missing is any explicit routing to an alternative tool when the caller actually wants dynamic or tracked codes, or the sibling that manages the stamp itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All LLPRO Campus tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?