Skip to main content
Glama
Sign In
ChartQuery MCP Server

ChartQuery MCP Server

by chartquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

QR Code

qrcode
Read-only

Encode data into styled QR codes as SVG or PNG, with custom colors, shapes, gradients, and print-ready sizing for links, labels, and accessible sharing.

Instructions

QR Code. Generate a styled QR code via GET. Output: SVG (default) or PNG. Supports dot styles, gradients, custom corners and all QR versions. Credit cost: 3 credits per call.

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": {
      "data": "<data>"
    },
    "name": "qrcode"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataYesData to encode in the QR code. Examples:
descNoSVG <desc> element for extended accessibility description. Example: ?desc=Scan+to+visit+https://chartquery.com
maskNoMask pattern from 0 to 7. Default: auto (best mask selected to minimize visual patterns). Only set manually if you need a deterministic output. Example: ?mask=3
modeNoEncoding mode. Default: auto (best mode selected for the data). Use numeric for digits-only, alphanumeric for uppercase + digits, byte for arbitrary text/UTF-8. Example: ?mode=numeric Allowed values: auto, numeric, alphanumeric, byte. Default: "auto".
sizeNoOutput size in pixels (width = height). Default: 200. Examples: ?size=200 (thumbnail), ?size=300 (standard), ?size=400 (large), ?size=600 (poster). For print, use the unit param with mm/cm instead.
unitNoMeasurement unit for the size param. Default: px. Use mm, in or cm with the size param for print-ready output. Example: ?size=50&unit=mm Allowed values: px, mm, in, cm. Default: "px".
colorNoModule color as CSS hex. Default: #000. Examples: ?color=%236366f1 (indigo), ?color=%23dc2626 (red), ?color=%23059669 (green), ?color=%230891b2 (teal). Use %23 to URL-encode #. For gradient objects, use POST instead.
shapeNoOverall QR code shape. Default: square. Use circle to clip the entire QR into a circle: great for profile/avatar-style codes. Example: ?shape=circle&dot_type=dots Allowed values: square, circle. Default: "square".
shareNoSet share=true to persist the config and receive JSON instead of an image: { id, render_url, view_url, embed_url, expires_in }. Free plan: 3-day expiry with watermark. Paid plan: 6-month expiry, no branding. Default: false.
titleNoSVG <title> element shown as a browser tooltip and used by screen readers. Example: ?title=ChartQuery+Website
fieldsNoComma-separated list of fields to keep in the response, with dot notation for nested fields (e.g. name,location.city). Does not change the credit cost.
formatNoOutput format. Default: svg. Use png to get a raster image. SVG is lossless and scalable; PNG is pixel-based and suitable for email, PDF or messaging. Example: ?format=png Allowed values: svg, png. Default: "svg".
marginNoQuiet zone width in modules around the QR code. Default: 4. Minimum recommended by the QR standard: 4. Example: ?margin=2 (compact) or ?margin=6 (extra padding).
versionNoQR version from 1 to 40 (determines grid size and data capacity). Leave unset for auto-selection based on data length and ec_level. Example: ?version=5
dot_sizeNoModule size ratio between 0.1 and 1. Default: 1 (full). Values below 1 add spacing between modules for a lighter look. Example: ?dot_size=0.85
dot_typeNoModule (dot) shape. Default: square. Controls the visual style of each QR code module. Allowed values: square, rounded, dots, diamond, classy, classy-rounded, extra-rounded, vertical-line, horizontal-line, small-square, tiny-square. Default: "square".
ec_levelNoError correction level. Default: M. Higher levels allow more damage/obscuring before the code becomes unreadable. Allowed values: L, M, Q, H. Default: "M".
aria_labelNoAccessible label added as aria-label on the SVG element. Example: ?aria_label=QR+code+linking+to+chartquery.com
backgroundNoBackground color. Default: #fff. Set to transparent for no background. Example: ?background=%230f172a for dark background. Use %23 to encode #.
xml_declarationNoPrepend an XML declaration (<?xml version="1.0" encoding="UTF-8"?>) to the SVG output. Useful when the SVG will be used as a standalone XML file. Default: false. Example: ?xml_declaration=true

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover readOnly, non-destructive and open-world behavior, and the description adds genuinely useful context beyond them: the HTTP method, the default SVG output, and a concrete cost signal ("3 credits per call"). It stops short of noting that the share parameter switches the response to JSON links instead of an image.

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?

Five short, front-loaded clauses, all information-bearing except the leading "QR Code." which merely restates the name. Nothing is padded and the cost is stated up front where an agent will see it.

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?

For a 20-parameter but fully documented schema with no output schema, the description supplies what the schema cannot: cost, transport method, and the primary output choice. Return shape is partly addressed via the SVG/PNG statement, and the schema handles the rest, so an agent can call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and every parameter carries a detailed description with examples, defaults and enum-like allowed values, so the schema fully carries parameter meaning. The description's styling summary (dot styles, gradients, custom corners) adds a useful orientation layer without duplicating syntax.

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 ("Generate a styled QR code via GET") and names the capability envelope (dot styles, gradients, custom corners, all QR versions) plus output formats. It is clearly distinguishable from most siblings, though it never explicitly contrasts with the closest sibling, barcode.

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 through "via GET" and the SVG/PNG output note, but there is no explicit when-to-use or when-not guidance, no mention of choosing this over barcode, and no routing to the POST variant for gradient objects (that hint lives only in the color parameter).

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

Deploy Server

Other Tools