QRStuff MCP Server

Create digital business card

create_digital_business_card

Destructive

Use this when the user wants a digital business card: a shareable mobile page with their name, role, company, phone, email, address and links, opened by QR code. Creates the card and its QR code in one step and returns both. The details are shown publicly on the card, so include only what the user wants shared. Pass idqrcode to turn an existing vCard QR code into a card. Do not use it for a plain contact QR code that stores the details in the code (use generate_qr_code with type VCARD).

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": {
      "contact": "<contact>"
    },
    "name": "create_digital_business_card"
  }
}

Input Schema

Name	Required	Description	Default
`contact`	Yes	Card details using these keys: firstName, lastName, honorific, telephoneNumber, cellPhoneNumber, faxNumber, email, organization, street, city, state, postcode, country, url, note. Include only what the user wants shown publicly.
`idqrcode`	No	Optional ID of an existing vCard QR code to turn into this card, from `list_qrcodes`.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly structured. The description adds real value beyond that by disclosing that the details are displayed publicly and warning to include only shareable information, plus the one-step creation of card and QR code. It does not state whether the card can be edited or deleted afterward or what permissions are required, so it stops short of a 5.

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?

Four sentences, each doing distinct work: purpose, behavior, privacy caveat, and exclusion with alternative. The primary use case is front-loaded and the negative guidance is placed last where it is easy to check.

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?

An output schema exists, so the description need not detail return values, and it still notes that both the card and its QR code are returned. For a destructive, open-world, nested-parameter tool it covers purpose, privacy, and conversion, but omits post-creation lifecycle details such as whether the card is editable or deletable.

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, and the description still adds meaning: it explains the effect of idqrcode (converting an existing vCard QR code rather than creating fresh) and reiterates the public-visibility constraint on the contact object. It does not add syntax or validation detail for the contact keys beyond what the nested schema already documents.

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 (creates a digital business card, a shareable mobile page) and enumerates what it holds plus the QR code deliverable. It clearly separates itself from generate_qr_code with type VCARD, but does not address the sibling convert_vcard_to_digital_business_card, which appears to overlap with the idqrcode conversion path it describes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ('when the user wants a digital business card'), explicit when-not ('do not use it for a plain contact QR code that stores details in the code'), and names the correct alternative tool with its parameter setting. Nothing is left to inference.

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

All QRStuff MCP Server 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?