Skip to main content
Glama

qrtap_list_codes

List managed codes and short links newest first, filtered by group or external_ref, with optional scan totals. Find a code's id before retargeting or confirm it exists before creating more.

Instructions

List the organization's managed codes and short links, newest first. This is the way to find a code's id before retargeting it, and the way to check what already exists before creating more. Filter by group (a whole batch) or external_ref (one specific code). Set include_stats=true to get every code's all-time scan count in the same response — far cheaper than calling qrtap_code_stats per code when you only need totals.

Input Schema

NameRequiredDescriptionDefault
groupNoOptional filter: only codes filed under this group (partner | equipment | event_menu | bag_insert | training).
limitNoPage size, 1..500. Defaults to 100.
offsetNoPagination offset; add `limit` to walk further batches.
external_refNoOptional filter: only the code carrying this external reference (exact match). The fastest way to check whether a code for a given branch/SKU already exists.
include_statsNoWhen true, adds an all-time non-bot `scans` counter to every returned code. Use it to compare a whole batch in one call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.4

TDQS

A4.6/5.0
Behavior4/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 much of it: it discloses result ordering ('newest first'), org-wide scoping, and the cost tradeoff of include_stats versus per-code stats calls. It does not state read-only nature explicitly or any auth/permission requirements, which is the remaining gap.

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?

Three sentences, each front-loaded with a distinct purpose: identity/ordering, use cases, then filter and stats guidance. No filler; every clause carries actionable information.

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?

No output schema exists, and the description covers what comes back (codes with `id`, optional all-time non-bot scan counts). Pagination semantics live in the schema. Minor gaps remain around total counts and whether any codes are excluded, but an agent can call it correctly.

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 baseline is 3, but the description adds genuine meaning: group filters 'a whole batch' while external_ref targets 'one specific code', and include_stats is framed as a batch-comparison shortcut. It clarifies the decision between the two filters beyond what the schema alone conveys.

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?

Opens with a specific verb+resource plus scope and ordering: 'List the organization's managed codes and short links, newest first.' It is clearly distinguishable from siblings like qrtap_list_pages and qrtap_list_bookings by naming the resource as codes/short links.

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?

Explicitly states two when-to-use cases ('find a code's id before retargeting it', 'check what already exists before creating more') and names a concrete alternative it is cheaper than: qrtap_code_stats. It also explains when to use group vs external_ref filters.

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