Skip to main content
Glama

toolkit-mcp-server

by io.github.cyanheads

toolkit-mcp-server: generate QR code

toolkit_generate_qr
Read-onlyIdempotent

Encode text or a URL into a QR code. data is the content to encode (a link, a generated identifier such as toolkit_generate_id's ids[0], or any string). format selects the output: svg returns inline SVG markup, png_base64 returns base64-encoded PNG bytes (with mimeType and byteLength), and terminal returns a block of Unicode block characters renderable in a monospace terminal. errorCorrection (L/M/Q/H) trades data capacity for damage tolerance, margin sets the quiet-zone width, and scale sets pixels per module for raster output. The returned version (1–40) reflects how dense the encoded data is. png_base64 renders (modules + 2 × margin) × scale pixels per side and rejects anything past 2048 px with a typed raster_too_large error, so a dense symbol needs a lower scale; svg carries no such limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesThe text or URL to encode. 2953 is the absolute ceiling (QR version 40, level L, byte mode); usable capacity drops at higher errorCorrection levels, so over-capacity data is rejected with a typed data_too_large error rather than a generic failure.
scaleNoPixels per module for raster (png_base64) output. Ignored for terminal. png_base64 also bounds the whole image at 2048 px per side, so a dense symbol or a wide margin admits a lower scale than 32.
formatNoOutput format: svg markup, png_base64 (raster bytes), or a terminal-renderable string.svg
marginNoQuiet-zone width in modules around the symbol. The spec recommends 4.
errorCorrectionNoError-correction level: L (~7% recoverable) to H (~30%). Higher tolerance lowers data capacity.M

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
formatNoThe format that was produced.
contentNoThe QR artifact: SVG markup, a terminal-renderable string, or base64 PNG bytes for png_base64.
versionNoQR symbol version (1–40); higher versions hold denser data and indicate denser content.
mimeTypeNoMIME type of content for image formats. Absent for the terminal format.
byteLengthNoDecoded byte size of the PNG. Present only for png_base64.

TDQS

A4.2/5.0
Behavior5/5

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

The description goes well beyond the annotations (readOnly, idempotent) by disclosing return formats (SVG markup, base64 PNG with mimeType/byteLength, terminal block), pixel size limits (2048 px with typed raster_too_large error), data capacity ceiling (2953 with typed data_too_large error), and the meaning of the returned version. It even explains how scale interplays with margins and density. This is rich behavioral context.

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 description is thorough but slightly wordy; it packs many details into one paragraph. It is front-loaded with purpose and then methodically covers each parameter and constraint. Given the tool's complexity (5 parameters, error cases, format-specific limits), the length is justified, though it could be tightened.

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?

The description covers every parameter's effect, document return formats, error behaviors, and physical limits. An output schema also exists for the result structure, so the absence of explicit return-field documentation is acceptable. Nothing an agent needs to call this tool correctly is missing.

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?

The input schema already has 100% coverage with detailed descriptions for every parameter, so the baseline is 3. The description repeats and slightly elaborates (e.g., explaining that png_base64 renders (modules + 2×margin)×scale pixels and that svg has no size limit), but it does not add fundamentally new meaning beyond what the schema already 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?

The description opens with a clear verb-resource pair ('Encode text or a URL into a QR code') and then details the output formats. It distinguishes the tool from siblings by focusing on QR generation, which is distinct from the other encode/hash/id tools in the sibling list.

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?

The description explains what the tool does and how to control output, but it never explicitly says when to choose this tool over alternatives. Sibling tools like toolkit_encode_value are not mentioned, so an agent gets no direct comparison or exclusion guidance. However, the purpose is specific enough that usage is inferable.

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

All toolkit-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct function: encoding, ID generation, QR generation, IP geolocation, and hashing. No two tools could plausibly be selected for the same task, and the descriptions reinforce these boundaries.

Naming Consistency5/5

All tools follow the exact toolkit_<verb>_<noun> snake_case pattern with action verbs (encode, generate, geolocate, hash). There are no mixed conventions or vague names.

Tool Count5/5

Five tools is within the ideal 3-15 range and each tool carries substantial functionality through multiple formats, algorithms, or operations. No tool feels like filler, and the set avoids bloat.

Completeness4/5

Each individual tool is internally comprehensive—encode covers four encodings in both directions, generate_id covers common ID formats, and hash covers generate/compare. As a general 'toolkit' it omits some common utility categories, but there are no dead ends or missing operations within the five advertised functions.

Resources