label

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

The description adds meaningful behavioral context beyond the neutral annotations: every row returns as its own download link valid for one hour, and the tool is Pro-only while the free tier is limited to one code per call. This helps the agent anticipate output shape and entitlement constraints.

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?

Three tightly written sentences with no filler. The batch action is front-loaded, followed by the crucial per-row download-link behavior and the Pro/free-tier limitation. Every sentence earns its place.

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?

The schema documents all ten parameters, defaults, and enums, while the description covers the two non-obvious facts an agent needs: per-row download links with one-hour validity and the Pro/free-tier limit. It does not explicitly route single-code requests to sibling tools, but the definition is sufficient for correct invocation.

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?

Schema description coverage is 100%, so the schema carries most parameter meaning. The description reinforces the items shape by mentioning rows with their own value and file name, but it does not add parameter-level detail beyond what the schema already provides.

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?

The description opens with a specific verb and resource: 'draw many barcodes or QR codes at once from a list of rows, each with its own value and file name.' This clearly distinguishes the batch tool from the single-code siblings like barcode_create and qr_create.

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 description gives a clear invocation context: use this when you need many codes at once from a list of rows. It does not explicitly name the single-code siblings as alternatives for when-not to use it, so the exclusion guidance is implicit rather than explicit.

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

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

Annotations are all false, so the description carries the burden of behavioral disclosure. It adds a useful policy: short EAN/UPC values get their check digit computed, and invalid ones are refused rather than corrected. However, it does not mention file-creation side effects, overwrite behavior, authentication needs, or that PNG output requires a Pro plan.

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 sentences, no filler, with the core action and output formats front-loaded. The check-digit behavior and QR alternative are stated economically, and every sentence earns its place.

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?

Given the rich input schema that documents all eight parameters, the description provides the essential selection and behavioral context. The only notable gap is not distinguishing barcode_create from barcode_batch, but the tool can still be invoked correctly with the information provided.

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?

All parameters are already documented in the schema, so the baseline is 3. The description adds meaningful value by explaining that EAN/UPC check digits are computed and that a wrong one is refused, which clarifies the expected behavior of the value parameter beyond the 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?

The description clearly states it draws a linear barcode, lists the supported symbologies, and names SVG/PNG as outputs. It explicitly differentiates from qr_create, though it does not address the barcode_batch sibling, leaving a small ambiguity between single and batch barcode generation.

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 description gives explicit context: this tool is for linear barcodes, and qr_create is the alternative for QR codes. It does not mention when to prefer barcode_batch or provide broader exclusion criteria, but the core usage signal is clear.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds beyond that: it reads the register (not files), returns newest-first records, and exposes monthly quota consumption. No contradiction with annotations.

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?

Three short, information-dense sentences. The main action and ordering come first, followed by return content, quota, filter, and source caveat. No filler or repetition of schema details.

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?

There is no output schema, so describing the returned content ('what each carried and where it went', quota usage) is valuable. The main missing piece is exact output shape, but for a simple read-only list tool the description is adequate for an agent to invoke and interpret results.

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?

Schema description coverage is 100%, and the description's 'Filter by kind' only restates the kind parameter. It does add that 'newest first' applies to the result order, which aligns with limit's schema description, but it does not add meaning beyond the 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?

The description states a specific verb and resource ('List the codes this server generated'), defines ordering ('newest first'), the content ('what each carried and where it went'), quota usage, and filtering by kind. This clearly separates it from the create-oriented sibling tools.

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 intended use is implied by the verb and object, but the description never says when to prefer this over siblings such as license_status for quota or license_activate for code creation. It gives no explicit when-not or alternative guidance, only the data-source note 'reads the register, not the files'.

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

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

Annotations are all false and provide no safety or side-effect hints, so the description carries the burden. It usefully discloses that IBAN and name are pulled from the shared profile and never requested from the caller, and that invoice_id can supply the amount. But it omits behavioral details like file generation, overwrite semantics, and the difference between inline SVG return versus expiring PNG download links, which are only revealed in parameter descriptions.

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?

The entire description is one dense, front-loaded sentence with no filler. It leads with the call-to-action, then immediately explains the two data-source behaviors that matter most, and avoids repeating schema details.

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?

For an 11-parameter tool with no output schema and no helpful annotations, the description captures the core scenario but leaves significant context to parameter descriptions. It does not explain the return payload shape or file-handling behavior, and it does not address the likely confusion with qr_payment_sepa. The rich schema compensates partially, but the description alone is not fully complete.

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?

Schema coverage is 100%, so the baseline is 3. The description adds real meaning beyond the schema by explaining that IBAN and name are not needed from the caller, and that invoice_id can replace an explicit amount. This helps an agent understand the intended minimal inputs without reading every parameter detail.

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?

The description states a specific operation: generating a SEPA payment QR from an amount and reference, with the unique twist that IBAN and name come from the shared business profile. This distinguishes it from generic QR siblings like qr_vcard or qr_wifi and even implies a different workflow from qr_payment_sepa.

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?

It gives a clear positive trigger ('Call this tool for a SEPA payment QR from just an amount and reference') and describes the invoice_id alternative for sourcing the amount. However, it never explicitly contrasts this with sibling qr_payment_sepa or states when NOT to use this tool, leaving some routing ambiguity.

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

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

Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the operation.

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?

The description is two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential information.

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?

For a single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent to call it correctly.

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?

The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in the 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?

The description uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.

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 description provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.

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 dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information is front-loaded.

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 sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool correctly.

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?

There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.

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?

The description begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.

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 description explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.

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

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

Annotations are all false, providing essentially no signal, so the description carries the disclosure burden. It adds valuable behavioral traits: the 20-codes-per-month free quota, the Pro-tier requirement for PNG output, and the return payload (version, module grid, payload size). No contradiction with annotations; creating a QR code consuming quota is consistent with readOnlyHint=false.

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?

Three tight sentences with zero filler: purpose and format options first, return values second, quota constraint last. Each sentence contributes distinct information and the most decision-relevant facts (what it does, what you get, what it costs) are front-loaded.

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's mention of return values (version, module grid, payload size) is genuinely useful. All 7 parameters are fully documented in the schema, and the description adds the quota and Pro-tier gating that the schema can't express. Minor gap: the one-hour download link expiry and overwrite semantics live only in parameter descriptions, which is acceptable given their context.

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?

Schema coverage is 100%, so the baseline is 3. The description mostly echoes what the schema already states (SVG default/free, PNG Pro, size relates to pixel dimensions for PNG). The cross-parameter note tying PNG to out_path and Pro adds a little meaning, but not enough to exceed the baseline given the schema's own rich parameter descriptions.

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?

The description opens with a specific verb+resource: 'turn text or a URL into a QR code,' which precisely states the tool's function. The 'text or URL' scope implicitly distinguishes it from specialized siblings like qr_vcard, qr_wifi, and qr_payment_sepa, signaling that this is the general-purpose QR generator.

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 description implies when to use the tool (any text/URL QR need) and gives real decision context via the free/Pro format split and the '20 codes a month' quota. However, it never explicitly states when NOT to use it or names alternatives for specialized QR types (vCard, WiFi, SEPA), leaving the routing to inference.

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

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

Annotations only cover mutability/idempotence/destruction flags, so the description carries the burden of behavioral context. It adds a useful fact: beneficiary IBAN and name default to the shared business profile and are never asked for. It does not discuss output behavior, file creation, authentication needs, or side effects, though those are partially hinted at in the schema.

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 sentences with no filler. The usage condition is front-loaded, and the default-beneficiary behavior is stated in the second sentence. Every phrase earns its place.

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?

For a 14-parameter tool with no output schema, the description plus schema is mostly sufficient, and the shared-profile context is valuable. However, the description does not describe the return contract (inline SVG versus downloadable PNG) and does not clarify how this tool relates to invoice_payment_qr; the agent must infer these from the out_path parameter and sibling names.

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?

Schema coverage is 100%, so the baseline is 3. The description earns extra credit by emphasizing the minimal viable payload ('Amount and reference are enough') and clarifying that beneficiary data is supplied by defaults rather than required input. This helps an agent assemble a valid call without opening every schema field.

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?

The description opens with a specific action ('Call this tool for an EPC069-12 payment QR') and names a concrete output (a QR a euro banking app can scan). It is clearly distinguished from barcode, wifi, and vcard QR tools, though it never explicitly names or separates itself from the close sibling invoice_payment_qr.

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 description gives an explicit trigger condition: use this for an EPC069-12 SEPA payment QR. It also gives practical guidance that amount and reference are enough, and that beneficiary IBAN/name come from the shared profile. It does not name alternatives or state when not to use it, so it stops short of a 5.

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

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

The description adds a useful behavioral note: the defaults are 'never asked for', so the agent knows not to expect prompts for those values. But it leaves side effects like output-file handling, overwrite behavior, and download-link expiry to the schema, and the annotations are all false, so they provide no safety context.

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 sentences with no filler. The first sentence states the purpose, and the second delivers the key defaulting behavior. Everything earned its place.

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?

For a 14-parameter tool with no output schema and no positive annotations, the description covers the core use case and default policy but does not describe the return/output behavior, such as inline SVG vs PNG download link. The schema helps, but the description itself is not fully standalone.

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?

Schema coverage is 100%, so the baseline is 3. The description adds cross-parameter meaning by grouping name, phone, email, and address as a shared default set and explains that passing nothing is the correct approach for one's own card, which is not fully captured per-parameter in the 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?

The description uses a specific verb ('make') and a specific resource ('QR code that adds a contact when scanned (vCard 3.0)'). The 'vCard 3.0' detail clearly differentiates this from sibling QR tools, though it does not explicitly name them.

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?

It explicitly tells the agent when to call the tool and gives a concrete usage rule: pass nothing for your own card because name, phone, email, and address default to the shared business profile. However, it does not mention when not to use it or name alternatives among the QR siblings.

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

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

Annotations provide only basic hints (not read-only, not idempotent, not destructive), so the description adds useful context: it creates a file only when out_path is used, otherwise returns SVG, and it states a quota of '20 codes a month.' This goes beyond the annotations without contradicting them.

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?

The description is two sentences and every part earns its place: the first states the primary behavior and output options, while the second adds quota context and sibling differentiation. It is tightly written with no filler or repetition of schema text.

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?

Given ten parameters and no output schema, the description covers the high-level use case, output mode, quota, and relevant sibling. The schema fills in the remaining parameter details such as defaults, enums, and PNG download links, so no critical operational information needed to call the tool correctly is missing.

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?

Schema description coverage is 100%, so the schema already documents all ten parameters. The description highlights the essential parameter group (ssid, password, auth type) and the out_path-or-SVG behavior, but it does not add substantial semantic detail beyond what the schema provides, which fits the baseline of 3.

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?

The description uses a specific verb and resource: 'make a QR code that joins a WiFi network when scanned.' It also distinguishes itself from the sibling tool qr_create, so an agent can immediately understand this is the WiFi-specific QR generator and not a generic QR tool.

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?

It explicitly says 'Call this tool to make a QR code that joins a WiFi network' and contrasts with 'qr_create takes plain text or a URL,' giving the agent a clear routing rule between the two closest alternatives. This is direct usage guidance rather than implied context.

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