Skip to main content
Glama

set_card_project_qrcode

Place or update a QR code on a chosen invitation project page, linking it to a URL you specify.

Instructions

Place (or update) a QR code on a specific page of an invitation project. The page UUID comes from get_card_project (look under the customization's pages array).

Input Schema

NameRequiredDescriptionDefault
urlYesURL the QR code will resolve to
colorNoHex color (no #). Default: 000000
enabledNoWhether to enable the QR code. Default: true.
url_typeNoCUSTOM (default) | WEDDING_WEBSITE | WEDDING_WEBSITE_RSVP
dimensionNoSMALL | MEDIUM (default) | LARGE
page_uuidYesPage UUID of the customization to put the QR on
project_uuidYesProject UUID from list_card_projects

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observedv1.4.2

TDQS

A4/5.0
Behavior3/5

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

Annotations supply openWorldHint=true and destructiveHint=false, so the safety profile is partly covered. The description adds the meaningful upsert detail ('Place (or update)'), but says nothing about what happens to a pre-existing QR code, whether multiple codes per page are allowed, or permission requirements.

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 short sentences, zero filler, with the action and target front-loaded before the lookup hint. Every clause earns its place.

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-parameter mutation tool with no output schema, the description plus the fully documented schema give enough to call it correctly. Remaining gaps are edge-case behavior on overwrite and whether a page can hold more than one QR code.

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 provenance for page_uuid ('comes from get_card_project, under the customization's pages array'), which the schema does not explain and which directly helps the agent supply a valid value.

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 (place/update) and resource (QR code on a page of an invitation project), and clarifies the upsert nature in parentheses. An agent can distinguish it from sibling QR tools like preview_qrcode without opening a 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?

The description points to get_card_project as the source of the page UUID, which is useful prerequisite context, but it never states when to use this tool versus preview_qrcode or other card project tools, and offers no exclusions or conditions.

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