URLinks

save_qr_config

Destructive

Save a QR code style configuration for an existing shortlink. The generated QR encodes the urlinks.me redirect URL (https://urlinks.me/{alias}/{name} for my/ links, or https://urlinks.me/{shortlink} for yt/ and group links) — NOT the destination URL directly — so every scan is counted as a click. Personal (my/) shortlinks therefore require the user to have an alias set; use get_alias to check and create_alias to set one. Available styles: dot shapes (square, circle, rounded, classy, classy-rounded, diamond, star, heart, plus, hexagon, octagon, drop), corner styles (same set — novelty shapes fill only the inner pip), an outer frame (none/square/circle/rounded), colors, center logo or a built-in emblem (heart/star/bolt/clover/shield/moon), and a scan-me frame. Gradients are dashboard-only for now.

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": {
      "shortlink": "<shortlink>"
    },
    "name": "save_qr_config"
  }
}

Input Schema

Name	Required	Description
`frame`	No	Frame style around the QR code (default: none)
`bgColor`	No	Background color as hex (default: #FFFDF7)
`ecLevel`	No	Error correction level — higher = more resilient but denser. H recommended with a logo or styled shapes (default: H).
`fgColor`	No	Foreground color as hex (default: #1A1F2E)
`dotShape`	No	Shape of the QR code data dots (default: square). Novelty shapes (diamond/star/heart/plus/hexagon/octagon/drop) render via the shared @urlinks/qr renderer.
`logoSize`	No	Center logo size as a percent of the QR, 20–30 (default: 25).
`showLogo`	No	Show a logo in the center (default: false)
`frameText`	No	Text to display in the frame (max 30 chars)
`shortlink`	Yes	The shortlink to configure QR for (e.g., 'my/docs')
`centerIcon`	No	Built-in center glyph rendered in the middle of the QR — a no-upload alternative to a logo. Any data shape, or an emblem (bolt/clover/shield/moon). Overrides showLogo when set.
`outerShape`	No	Frame drawn around the whole QR (default: none).
`cornerStyle`	No	Shape of the three corner finder markers. The outer frame stays scanner-safe; novelty shapes only fill the inner pip (default: square).
`dotImageUrl`	No	URL of a square PNG to color the QR by — each module samples the image at its position (e.g. a flag). White/pale areas become a scannable light grey, finder eyes are forced dark, on a white background. Overrides solid color and gradient.
`transparent`	No	Use transparent background (default: false)
`fgTransparent`	No	Transparent dots — the data modules are cut out, for overlaying the QR on other images (default: false).
`useUrlinksLogo`	No	When showLogo is true, use the URLinks logo as the center image (default: true).
`centerIconColor`	No	Hex color for the center emblem (defaults to the foreground color).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare destructiveHint=true, and the description adds substantial context beyond that: the QR encodes the urlinks.me redirect URL rather than the destination (so scans count as clicks), an alias prerequisite exists for my/ links, and gradients are unsupported. It never states the destructive consequence directly — i.e. that saving replaces any existing QR config — which is exactly what the destructiveHint implies and the agent most needs to know.

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 block, but the most decision-relevant fact — that the QR encodes the redirect URL, not the destination — is front-loaded in the second clause. The style inventory runs long and duplicates schema enums, but every sentence is informative rather than filler; splitting the prerequisite and style details into separate lines would improve scannability.

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 17-parameter mutation tool with no output schema, the description covers the essentials: what is saved, what the artifact encodes, the alias precondition, the style space, and one unsupported feature. Gaps remain around the overwrite/replace semantics implied by destructiveHint and whether the call returns the saved config or a rendered image, but the core calling requirements are present.

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 coverage is 100%, so the baseline is 3, and much of the description's style enumeration (dot shapes, corner styles, emblem list, outer frame values) repeats enum values already documented in the schema. The one genuinely additive note is the 'gradients are dashboard-only' constraint, plus the clarification that novelty corner shapes only fill the inner pip. However, it conflates the schema's two distinct concepts — 'frame' (none/banner/badge/minimal) and 'outerShape' (none/square/circle/rounded) — by describing both loosely as 'an outer frame', leaving the agent to sort out which parameter does what.

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 first sentence states a specific verb and resource — 'Save a QR code style configuration for an existing shortlink' — which cleanly separates it from get_qr_config (read), apply_qr_template (template application), and get_qr_image (render). The follow-up about which URL the QR encodes removes any ambiguity about what is actually being persisted.

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?

It gives concrete routing guidance for the prerequisite case: personal (my/) shortlinks require an alias, so 'use get_alias to check and create_alias to set one.' It also states a boundary ('Gradients are dashboard-only for now'), which prevents a failed attempt. What's missing is any guidance on when to use this versus apply_qr_template, a sibling that clearly overlaps.

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

All URLinks 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.