Print Shop by Bottle Your Brand

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the return payload's shape (topic answers plus free artwork tools and the upload page) and warning that generic print advice is often wrong for this shop.

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 sentences, front-loaded with the capability and followed by the returned artifacts and the usage rule; every sentence carries information. The opening phrase 'Bottle Your Brand's authoritative answers' is slightly awkward and adds a little friction before the substance.

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, the description needn't detail return values, yet it summarizes them anyway; it covers scope, topics, side artifacts, and a clear invocation rule. Nothing an agent needs to decide to call this zero-parameter tool is absent.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter-level detail is needed or missing.

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 action (returns authoritative answers) and a specific resource (sticker making/printing guidance), then enumerates covered topics: sizing, resolution, bleed, materials, minimums, pricing, turnaround. It doesn't explicitly say how it differs from siblings like show_print_tool or upload_sticker_artwork, which it partially overlaps by mentioning free tools and the upload page.

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 a clear, emphatic when-to-use rule: 'Call this before answering sticker questions, including ones that sound general,' with the rationale that shop-specific specs beat generic DPI/bleed advice. It never names an alternative tool or states when not to use it, so it falls short of the top band.

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 declare readOnlyHint=false and openWorldHint=true, and the description usefully clarifies that no order is actually placed — it only returns a pre-filled order-page link and the customer picks a size. That is genuine context beyond the annotations. It could go further on what happens if the URL is unreachable or unsupported, but the key behavioral caveat is disclosed.

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?

Front-loaded with the core action, then trigger phrases, then input/output contract, then a display instruction — a logical order with no filler. It runs slightly long and repeats the format list already in the schema, but each sentence does pay for itself.

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?

Output schema exists, yet the description still gives the agent the essential operational instruction to surface the returned link as clickable, which is exactly the kind of thing schemas don't convey. For a one-parameter tool this is nearly complete; the only gap is sibling routing.

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% and the single image_url parameter is fully documented as a public https URL in PNG/JPG/PDF, so the description's restatement of 'public https URL (PNG, JPG, or PDF)' adds little. Baseline 3 is appropriate since the schema carries the semantics.

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 — turn an image into custom die-cut vinyl stickers printed by a named vendor — and specifies the concrete output (an order-page link with artwork attached). An agent can distinguish this from upload_sticker_artwork or get_sticker_guidance by the 'produce an ordering link' framing.

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?

Provides explicit trigger conditions with quoted user phrasings ('make this into stickers', 'print my logo as stickers'), which is strong when-to-use guidance. It does not, however, state when NOT to use it or name the sibling tools it should be preferred over, so routing between order_custom_stickers and upload_sticker_artwork 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 readOnly/openWorld=false/destructive=false, so the safety profile is covered. The description adds the otherwise-unknown interaction model: the result is a card the customer can open rather than plain text, which changes how the agent should present it. It doesn't say what happens if the customer can't open cards or whether the tool returns any text, but the essential behavior is disclosed.

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?

Leads with the action and resource before the enumeration, and the usage rule lands in a second, short clause. The parenthetical glosses make the first sentence long and dense, but every element (tool list, per-tool meaning, routing rule) carries information the agent needs to choose a 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?

One required parameter with full schema coverage, an output schema handling return values, and annotations covering the safety profile — the description fills the remaining gaps: which tools exist, what each solves, and when to prefer a card over a name mention. Nothing needed to invoke 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?

Schema coverage is 100% and the enum is self-describing, so the baseline is 3. The description earns extra credit by explaining the effect of specific values ('measure-by-photo (what size sticker fits a real object)', 'background-remover (… add bleed and a cut path)'), letting the agent pick a value from customer intent, though cutline-generator, resolution-tester, contrast-check, size-guide and design-online get no gloss.

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 (show) and resource (one of Bottle Your Brand's free artwork tools) and names all seven tools with a gloss of what each does, e.g. 'measure-by-photo (what size sticker fits a real object)' and 'background-remover (remove a photo's background and add bleed and a cut path)'. The rendering behavior ('as a card the customer can open') further distinguishes it from siblings like get_sticker_guidance or upload_sticker_artwork.

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 says when to use it: 'when one of them solves the problem the customer just described,' and gives a contrast case: 'Use this instead of only mentioning a tool by name.' No sibling tool is named, so the agent must infer the boundary with get_sticker_guidance and upload_sticker_artwork, which keeps it below 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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely useful behavior beyond that: the panel opens in the conversation, the customer sees their file, and a button hands off to the Bottle Your Brand order page with artwork attached. It also explains the key constraint that chat-shared files cannot be passed to a tool directly. It stops short of saying whether anything is persisted before the hand-off, which keeps it from a 5.

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?

Front-loaded with what the tool does, then the trigger condition, then the user-visible flow, then the routing rule to the sibling. Four sentences and every one carries distinct 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?

With no parameters, an existing output schema, and annotations covering safety, the description supplies exactly the missing pieces: the trigger, the on-device/no-URL constraint, the hand-off outcome, and the sibling routing. Nothing an agent needs in order to select and call it correctly is absent.

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 the baseline is 4. The description reinforces this by clarifying that the file is selected by the customer inside the panel rather than supplied as an argument, which preempts an agent trying to pass a path or file reference.

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 action (show an upload panel) and the exact resource it handles (on-device artwork), and explicitly frames the mechanism: the customer picks the file in-conversation rather than the agent passing it. This is clearly distinguishable from order_custom_stickers, which the description names directly.

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 an explicit trigger ('whenever someone wants stickers made from a file they have but no public image URL') and an explicit exclusion plus alternative ('prefer order_custom_stickers instead when a public https image URL is available'). Nothing about tool selection 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.