list_qr_campaignsList your QR campaigns to retrieve each campaign's ID, name, status, and scan totals, plus your plan's QR limits. Use the IDs with get_qr_campaign and the QR write tools.
List your QR campaigns with each campaign's id (needed by get_qr_campaign and the QR write tools), name, status, and scan totals. Also returns your plan's QR limits.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.3.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, so safety is covered. The description adds real value by disclosing the return payload (id, name, status, scan totals) and that plan-level QR limits are included alongside the campaigns — non-obvious behavior since limits are not campaigns. It does not mention ordering, pagination, or behavior with zero campaigns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the verb and resource, then the returned fields, then the secondary plan-limits note. Nothing is redundant with the title beyond the opening phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain return contents and it does, including the otherwise surprising plan-limits field. The only gap for a parameterless list tool is scale behavior (pagination / large accounts), which is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline is 4. The description reinforces that scope is implicit ('your QR campaigns'), signaling no filtering arguments are accepted, consistent with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List your QR campaigns') and immediately differentiates from the sibling get_qr_campaign by noting that ids come from here. The returned fields are enumerated, so an agent knows exactly what this tool yields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'needed by get_qr_campaign and the QR write tools' gives a clear when-to-use trigger: call this first to discover ids before any QR mutation or single-campaign lookup. No explicit exclusion of alternatives is stated, but with only one listing sibling the routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.