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

The annotations already declare that this is not read-only and not destructive, and the description adds useful licensing context by noting Pro versus free-tier behavior. It does not disclose overwrite semantics, partial-failure behavior, or output-return details beyond what the schema provides.

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, front-loaded with the main action and scope, and contains no filler. The Pro/free-tier note is compact and purposeful.

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, the description is largely sufficient for selection and invocation. It could say more about file output behavior and error handling, but those details are covered substantially by the schema fields.

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 input schema already documents all 10 parameters in detail. The description only restates the core batch concept and does not add materially new 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: draw many barcodes or QR codes at once from a list of rows. It also clarifies the batch scope and file-writing target, which distinguishes it from single-code siblings such as barcode_create or 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?

It clearly indicates when to use the tool: for many codes at once, and notes the Pro requirement versus free-tier single-code calls. However, it does not explicitly name barcode_create or qr_create as the single-code alternatives.

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 declare the mutation profile (readOnly=false, destructive=false); the description adds genuinely non-obvious behavior — automatic check-digit computation for short EAN/UPC values and outright refusal of a wrong check digit — plus the rule that PNG always requires out_path. It stops short of covering overwrite semantics or what a refusal looks like.

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 sentences, front-loaded with the action and output options, then the edge-case rule, then the sibling pointer. 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?

For an 8-parameter file-writing tool with no output schema, the description covers output format, where bytes go, inline return for SVG, and the check-digit edge case — enough to call it correctly. Overwrite and sizing behavior are left entirely to the schema.

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 baseline is 3, but the description adds meaning not in the schema: the value parameter's check-digit handling and refusal behavior, and the format/out_path coupling for PNG. That is real added semantics rather than repetition.

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 ('draw a linear barcode'), enumerates the supported symbologies, and names the two output formats. An agent can immediately tell this apart from 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?

Explicitly routes QR use cases to qr_create and confines this tool to linear symbologies, with each symbology's intended use stated. No inference required to pick between the two.

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?

The annotations already disclose that this is not read-only, not idempotent, and not destructive, so the description benefits from adding the data-source behavior: IBAN/name come from the shared business profile and invoice_id reads from the invoice store. However, it omits file-writing behavior and overwrite implications, and the phrase 'never asked for' sits awkwardly with the optional iban/name override parameters 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?

The description is a single front-loaded sentence with no filler, and it prioritizes the main invocation path. It is somewhat dense and run-on, but it remains efficient for the amount of usage context it conveys.

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 core invocation path is explained well: amount/reference or invoice_id, with profile-sourced beneficiary data. For an 11-parameter generation tool with no output schema, however, it leaves out important output and file behavior such as inline SVG versus PNG output, Pro restrictions, and overwrite semantics.

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 11 parameters and the baseline is 3. The description adds useful defaulting semantics for amount, reference, and invoice_id, but it does not cover the output/file parameters and its 'never asked for' wording conflicts with the optional iban and name overrides.

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 resource and action: obtaining a SEPA payment QR, with the key scoping conditions of amount/reference or invoice_id. It also distinguishes this invoice-oriented flow from a generic SEPA QR tool by explaining that IBAN and name come from the shared business profile.

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 clearly says to use the tool with amount and reference, or to pass invoice_id instead when the amount should come from an invoice. It does not explicitly name when to use a sibling such as qr_payment_sepa instead, so the guidance is strong but not fully comparative.

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?

With no annotations provided, the description carries the full behavioral burden. It discloses that verification happens offline against a built-in public key, that the key is persisted to the config file, and that invalid keys are refused and left unsaved. This is substantial transparency for an activation tool, though it could mention overwriting an existing key or the exact return behavior.

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. The first sentence front-loads the main action, source, verification method, and persistence. The second sentence efficiently covers error handling and points to the related read-back tool. Every clause adds value.

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 a single-parameter tool with no output schema and no annotations, the description covers activation behavior, verification mechanism, persistence, error outcomes, and how to read the result later. The only minor gap is an explicit statement of what the function returns upon success or failure, but the phrase 'refused, unsaved' implies a feedback mechanism. Overall, it is sufficiently complete 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 at 100% coverage, so the baseline is 3. The description adds meaningful semantics by giving the concrete key format ('MCPL1.xxx.yyy'), confirming the key comes from the checkout page, and explaining that malformed or expired keys will be rejected. This goes beyond the schema's one-line description.

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 action ('Activate a Pro key'), the exact key format ('MCPL1.xxx.yyy'), the source ('from checkout'), and the core mechanism ('verified offline against a built-in public key'). It also differentiates itself from the sibling license_status by noting that license_status reads the activation back, so there is no ambiguity about which tool does what.

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 clear context: use this when you have a Pro key from checkout that needs to be activated. It also points to license_status as the read-back tool, which implies when to use a related sibling. It does not explicitly spell out 'do not use for checking status' or list other alternatives, but the context is strong enough to avoid misuse.

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 absent, so the description carries the full burden of behavioral disclosure. It discloses that the call is local ('no network') and argument-free, and it mentions a specific explanatory behavior. The word 'Report' implies read-only, though it does not explicitly state non-destructive or permission requirements; this is adequate for a status command.

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 lists the output fields; the second adds constraints and the sibling pointer. Every clause contributes meaningful 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 zero-parameter status tool with no output schema, the description lists the expected output fields, behavioral constraints, and the relevant alternative tool. Nothing an agent needs to call it 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?

The schema has zero parameters and the description reinforces this with 'No arguments'. It adds value by listing the reported fields, helping an agent understand what the empty input will yield. The baseline for zero-parameter tools is high, and the description meets it.

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 ('Report'), a clear resource ('this server's licence state'), and enumerates the exact fields returned. It also names the sibling 'license_activate' as the tool that does something different, so an agent can distinguish them immediately.

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 usage constraints: no arguments, no network, and explains a free-tier refusal. It also directs the agent to license_activate when the task is to install a key, serving as an explicit pointer to the relevant alternative.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds real behavioral context: files get written to disk, PNG output is gated behind Pro, and the free tier is rate limited to 20 codes/month. The write side-effect path is partially covered by the schema's overwrite flag, so the description is additive but not exhaustive about overwrite semantics.

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, front-loaded with the verb and resource, then the output modes, then the return shape and quota. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with one required field and no output schema, the description covers the output modes, the file-writing requirement, the Pro gate, and even the return shape (version, module grid, payload size). Only the alternative-sibling routing and overwrite consequences are left implicit.

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 every parameter including default margin, error_correction levels, and size range is already documented. The description reinforces the format/size/out_path relationship and the Pro constraint on PNG, but adds no syntax or default information the schema lacks — baseline 3 applies.

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 concrete verb and resource ('turn text or a URL into a QR code') and names the two output modes (inline SVG, PNG to out_path), so the operation is unambiguous. It stops short of differentiating itself from the specialized siblings qr_wifi, qr_vcard, and qr_payment_sepa, which an agent would still have to infer is the generic-vs-preset split.

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?

'Call this tool to turn text or a URL into a QR code' gives an implied use condition plus a tier prerequisite (PNG requires Pro) and a quota (20 free codes/month). There is no explicit guidance on when to prefer this over the preset siblings or barcode_create, and no when-not-to-use statement.

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 non-read-only, non-destructive, non-idempotent and closed-world, so the safety profile is covered. The description adds that beneficiary details come from the shared business profile, but never mentions that the tool writes files when out_path is set (and needs out_path for PNG), which is the main side effect an agent should know about.

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 trigger condition, and no filler. Everything stated 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 14 parameters and no output schema, the description is thin: it omits that SVG is returned inline unless out_path is given and that PNG requires out_path, and it leaves the invoice_payment_qr overlap unresolved. The rich schema compensates for parameter detail, but the tool-choice and output story is incomplete.

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 every one of the 14 parameters, including defaults, ranges, enums and the validation/refusal rules, is already documented in structured fields. The description's only parameter claim (IBAN/name default to the business profile) repeats the schema, so baseline 3 applies.

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: an EPC069-12 payment QR a euro banking app can scan. That is concrete and distinguishable from qr_wifi/qr_vcard/barcode_create, but it does not explain how it differs from the sibling invoice_payment_qr, which sounds like the same job.

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?

'Amount and reference are enough' gives implied context, and the note that IBAN/name default to the business profile tells the agent not to ask for them. But there is no explicit when-to-use/when-not guidance, especially against invoice_payment_qr, which is the most likely source of a wrong selection.

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 non-read-only, non-destructive, non-idempotent, closed-world, so the safety bar is lower. The description adds the vCard 3.0 output format and the shared-profile defaulting behavior, but says nothing about file writing side effects, what happens if out_path exists, or why the operation is not idempotent — content the schema only partly covers.

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 core action and immediately followed by the most important usage caveat. No filler, though the wording 'never asked for' is slightly cryptic and costs a word of clarity.

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 generation tool with no output schema, the description covers the payload type and defaulting but omits any mention of output behavior (inline SVG vs written file) or the SVG-free/png-Pro distinction, which the schema carries alone. Adequate but not complete on its own.

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 schema already documents every parameter, including the shared-profile defaults for name, email, phone and address. The description restates the defaulting rule rather than adding new meaning, so the baseline of 3 is appropriate.

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: make a QR code that adds a contact when scanned, with the vCard 3.0 format named. That distinguishes it from qr_wifi and qr_payment_sepa implicitly by payload type, though it never names a sibling explicitly.

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?

Gives one concrete usage rule ('for your own card pass nothing'), which resolves the main ambiguity around the 14 optional params. It does not say when to choose this tool over qr_create or the other QR siblings, leaving that inference to the agent.

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 say it's a non-read-only, non-idempotent, non-destructive write; the description adds genuinely new facts: the free-tier quota (20 codes/month), that output goes to out_path or is returned inline as SVG, and that PNG requires a path. It doesn't warn about overwrite behavior or auth requirements for image generation, but coverage beyond annotations is solid.

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, front-loaded with the action and its distinguishing scope, followed by output behavior and the sibling contrast. No filler; every clause carries 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 10-parameter tool with no output schema, the description covers payload, output destination, format tiering and quota, while the rich schema handles the rest. Slightly incomplete in not mentioning that PNG is Pro-only in the description text (it's in the schema) or overwrite semantics, but nothing an agent needs to call it 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?

With 100% schema description coverage, the schema already documents all 10 parameters including enums, defaults and ranges. The description only restates ssid/password/auth and the out_path-vs-SVG return behavior, adding marginal value rather than syntax or format detail. Baseline 3 applies.

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: 'make a QR code that joins a WiFi network when scanned', with the encoded payload spelled out (ssid, password, auth). It explicitly contrasts with the sibling qr_create ('takes plain text or a URL'), so an agent can select between the two without opening schemas.

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 WiFi-join scenario is stated clearly and the nearest alternative (qr_create for plain text/URL) is named, which gives an agent a routing rule. It stops short of explicit exclusions or pointing at the other specialized siblings (qr_vcard, qr_payment_sepa), so it's clear context rather than full when/when-not guidance.

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