QR Branding

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

Annotations already cover readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is fully carried by structured data. The description adds one genuinely useful fact beyond them – that scanning opens the coordinates in the device's default maps app – but says nothing about encoding precision, URI formatting, or error behavior for out-of-range input.

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, zero filler. The purpose is front-loaded and the scan-behavior detail follows immediately after, so nothing needs to be re-read.

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 two-parameter builder with a 100%-covered schema and an output schema, the description covers what the tool is and what the artifact does. The only minor gap is that it doesn't mention whether the returned QR payload is an image, string, or both – though the output schema presumably resolves that.

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%, with range bounds and units documented per parameter, so the schema does the heavy lifting. The description adds no syntax, formatting, or unit guidance beyond what latitude/longitude already declare, which is the expected baseline.

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 names a specific verb (encode), a specific resource (latitude/longitude pair), and the output artifact (geo: URI QR). That distinguishes it from the vcard/wifi template builders by resource, though it never names a sibling explicitly for extra disambiguation.

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?

Usage is only implied: you call this when you want a scannable location QR. There is no explicit when-to-use condition, no when-not-to-use, and no pointer to qr_generate or qr_build_vcard as alternatives for other payload types.

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 this as a read-only, idempotent, non-destructive, non-open-world operation, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the encoded payload is a vCard and scanning it inserts the contact into a phone's address book, which clarifies the artifact's purpose.

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 tight sentences with no filler: the first states what is encoded, the second states the end-user effect. The core action 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 an output schema present and rich annotations, the description need not explain return values or safety. It covers what is built and the user-facing outcome; the only minor omission is which field is required (firstName), which the schema's required list still supplies.

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 is already documented in the schema with its required flag and format constraints. The description merely re-lists the same field names (name, organization, phone, email, URL) without adding syntax, format, or requirement guidance, so the 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 names a specific verb ('Encode') and resource ('contact card (vCard)'), then enumerates the exact fields encoded. Combined with the tool name, an agent can immediately distinguish this from the geo/wifi QR builders among its siblings.

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?

Usage is only implied: the tool should be used when a scannable contact card is wanted. With six siblings (qr_generate, qr_generate_ai, qr_build_geo, etc.) there is no explicit statement of when to pick this one over the generic qr_generate or a template-based builder.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the output content ('WIFI:... payload string and a generated QR image'), which is modest added value since an output schema also exists, but it says nothing about limits or failure cases (e.g. missing password when authType is not nopass).

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 tight sentences, zero filler, with the action and resource front-loaded before the return description. Every clause 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?

With a full schema, an output schema, and complete annotations, the description covers what is needed to invoke the tool correctly. The remaining gap is routing information (when to pick this over a generic QR generator), which belongs to usage guidance rather than completeness of the definition itself.

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 is already documented in the schema, including the authType enum and the password-required-unless-nopass rule. The description only restates the parameter names in a parenthetical, adding no syntax or default detail beyond the schema; 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 ('Encode') and a precise resource (Wi-Fi credentials) with the fields enumerated, so an agent immediately knows this is the Wi-Fi-specific builder. It does not explicitly contrast itself with qr_build_geo/qr_build_vcard/qr_generate, though the resource name makes the distinction largely self-evident.

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?

No when-to-use guidance and no mention of alternatives among the six sibling tools. The only hint is the implicit purpose of encoding Wi-Fi credentials, which is the minimal information an agent could infer from the name alone.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds that this path gives the agent explicit design control, which is useful vs the AI sibling, but says nothing extra about auth, rate limits, or side effects beyond what annotations provide.

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 tight sentences: the capability and its scope come first, and the routing condition follows immediately. Every sentence earns its place with no filler or restated title.

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 17 parameters, a nested escape-hatch object, and an output schema, the description does not need to explain return values or enumerate parameters. It is nearly complete, but a brief explicit contrast with the AI/template siblings would make the routing decision fully self-contained.

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 enums, hex colors, dimensions, and the additionalConfig escape hatch) is already documented in the schema. The description only groups those parameters into categories and adds no syntax, defaults, or format nuance beyond 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?

The description states a specific verb+resource ("Generate a fully branded QR code") and enumerates the controllable dimensions (colors, module/finder shapes, logo, caption, output format). It aligns with the "manual" title, but it never names the AI or template siblings it differs from, so differentiation is implied rather than explicit.

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?

"Use this when the user already knows the design they want" gives a clear selection condition and implicitly excludes the AI/template paths for users who don't. It stops short of naming qr_generate_ai or qr_generate_from_template as the alternatives, leaving the routing 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 already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description usefully signals that output is LLM-driven and therefore variable, but says nothing about auth needs, rate limits, or whether the generated asset is returned inline versus stored.

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, zero waste, and the core mechanism (LLM picks the design) is front-loaded before the usage example. Nothing repeats the schema or the title verbatim.

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 an output schema present, return values need no explanation, and all 7 parameters are covered by the schema. The description is sufficient for correct invocation, though a note on determinism or cost/latency of the LLM step would have made it 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 description coverage is 100%, so every parameter including the prompt brief, stylePreset and dimension bounds is already documented in the schema. The description only restates the prompt-driven behavior and adds no format, default, or constraint detail beyond what the schema provides; 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 (Generate) and resource (QR code) and adds a real differentiator: the branding LLM picks colors and shapes from a natural-language prompt. That implicitly separates it from the plain qr_generate sibling, but no sibling is named explicitly, so the distinction still requires inference.

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?

"Best for 'make me a luxury gold dotted QR for a coffee brand' style requests" gives a concrete positive usage cue with an example, which is clearer than typical implied usage. It stops short of saying when NOT to use it or naming the non-AI alternative for deterministic output.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds useful behavioral context by framing everything except templateId as per-call overrides that fall back to the template's built-in values ('for this specific call'), implying nothing is persisted. It says nothing about invalid template ids, error behavior, or rate limits.

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?

A single front-loaded sentence with the action verb first and zero filler. It is compact and slightly enumerative rather than wasteful, though the trailing list is largely a restatement of the schema's parameter groups.

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?

An output schema exists, so return values need not be described, and the schema fully covers parameters, keeping the description's burden low. What is still missing is workflow context: that template ids come from qr_list_templates, and how this differs from the sibling generators. Adequate but with clear gaps for an eight-parameter tool.

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 eight parameters with ranges, enums, and defaults. The description's summary of overridable categories (content, colors, format, size) adds only a light grouping and no syntax or precedence detail beyond the schema. Baseline 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: 'Render one of the curated templates by id', with the override surface (content, colors, format/size) named. It is clear what the tool produces, but it never names or contrasts a sibling such as qr_generate or qr_generate_ai, so the agent must infer the boundary between template rendering and ad-hoc 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 phrase 'one of the curated templates by id' implies a template must already exist and be discoverable, and the schema points at qr_list_templates, but the description itself states no explicit when-to-use or when-not-to-use conditions. No alternative (qr_generate, qr_generate_ai) is mentioned, so routing is left 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 already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered without the description. The description adds the fixed catalog size (118) and the returned fields, which is modest extra context but nothing about pagination, ordering, or freshness of the template list.

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 core action and count, with no filler. The enumeration of return fields is partly redundant given an output schema exists, which is the only wasted space.

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 one-parameter, read-only listing tool with an output schema, the description supplies purpose, scope (118 templates), and filter behavior, so an agent can call it correctly. The missing piece is the relationship to qr_generate_from_template, which would have made the surrounding workflow explicit.

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% for the single category parameter, and the schema already documents example values and the omit-to-list-all behavior. The description's restatement ("filter by category if the user asks for a specific style") adds user-intent framing but no new syntax or semantics, so the 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 ("List the 118 pre-designed QR templates") plus the exact payload fields, so it is unmistakably the read-only catalog tool. It is clearly distinguishable from the build/generate siblings (qr_build_*, qr_generate*), which produce codes rather than enumerate designs.

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?

"Filter by category if the user asks for a specific style" gives a condition for using the filter, which is real guidance but scoped only to the parameter. It never states when to call this tool versus its siblings, nor the obvious follow-on workflow (pick a template id here, then feed it to qr_generate_from_template), so usage is only implied.

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