Skip to main content
Glama
Sign In
qrtap-mcp

qrtap-mcp

by IlyaShurf
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

qrtap_create_codes_bulk

Create up to 500 managed QR codes in a single batch request, returning per-item results and using external_ref to make retries safe and duplicate-free.

Instructions

Create MANY managed codes in a single request — up to 500. Use this for any batch: stickers for a print run, one code per table or shelf, one per branch or partner. Results are per item, so one bad URL does not sink the batch: the reply is {created, reused, failed, data:[…]} where each entry is either a code (ok=true, plus reused telling you whether it already existed) or {ok:false, external_ref, error}. On a re-run after a partial failure created counts only what was actually new and reused counts what was returned unchanged, so the two numbers tell you whether the call did any work. Give every item an external_ref — the call is then idempotent per item and safe to re-run after a partial failure, without producing duplicates. Bulk requires a paid plan: on a free workspace it answers HTTP 402 plan_required, and the fallback is a loop of qrtap_create_code within the plan's limits.

Input Schema

NameRequiredDescriptionDefault
itemsYesCodes to create, 1..500 items.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.4

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses per-item results, partial-failure behavior, idempotency via external_ref, the created/reused count semantics, and the paid-plan requirement with HTTP 402 plan_required.

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?

Front-loads the main action and max batch size, then packs usage, response shape, idempotency, and plan constraints efficiently. It is slightly dense as one long paragraph, but every sentence contributes useful information.

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?

Given a bulk-creation tool with no output schema, the description covers the response envelope, per-item success/failure shape, retry behavior, idempotency, and plan restriction. An agent has enough context to invoke and handle results correctly.

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 nested item fields are already documented thoroughly in the schema. The description reinforces external_ref usage but adds little parameter syntax or meaning beyond what the schema already provides, so the baseline 3 applies.

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 and resource ('Create MANY managed codes') plus the scope ('up to 500'), and distinguishes bulk creation from the single-code sibling by explicitly naming qrtap_create_code as the fallback.

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?

Gives concrete when-to-use examples (print runs, tables/shelves, branches/partners), names the alternative for non-bulk cases, and explains the free-plan fallback explicitly.

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