lookunique

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

Annotations already declare it as a read-only, idempotent, closed-world, non-destructive call, so the safety profile is covered. The description adds value beyond that by enumerating what the response contains (pictures, design_id, unfinished items, shop-check gaps) and the omitted-argument default, which annotations cannot express.

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 resource and its contents, followed by the default behavior. Every clause carries information; the phrasing 'anything the shop's own check found missing' is slightly roundabout but not wasteful.

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?

No output schema exists, so the description must carry the return-value burden, and it does so by listing the main response components. Formatting and ordering details are unspecified, but an agent has enough to interpret the result and call the 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?

With a single parameter at 100% schema coverage, the schema already documents drawing_id and its pattern. The description goes further by defining the semantics of omitting it (falls back to the conversation's newest drawing), which is behavior the schema cannot convey.

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?

Names the resource (a drawing) and states what it reports: pictures so far with design_id, in-progress work, and shop-check findings. That is specific enough to separate it from draw_from_photo, draw_shirt, and show_shirt, though the verb is implied rather than stated.

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 one real usage rule — omit drawing_id to read this conversation's newest drawing — which is useful context. However, it never says when to prefer this tool over siblings like show_shirt or the drawing tools; usage is only implied by the status-oriented content.

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, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds non-obvious behavioral context beyond that: it creates three pictures and returns the first as soon as it is ready, with the drawing's id. It does not discuss permissions, rate limits, or what happens to failed partial generations, but it meaningfully exceeds annotation coverage.

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 followed by the input forms and return behavior. Every sentence earns its place with no filler.

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 non-trivial image-generation tool with no output schema, the description covers inputs, process, and partial return behavior. It does not explain the output format beyond 'three pictures' or how to retrieve later results via siblings like check_drawing, but it is largely complete 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 baseline is 3. The description mentions the two input modes (`photo` as a file, `photo_url` as an https link), which aligns with the schema but adds no syntax or format details beyond what the schema already documents.

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: 'Turns an image into a t-shirt design in the shop’s dot-drawing style.' It also names the two image sources (a person’s photo or an AI-made picture), distinguishing it from generic image tools and from siblings like draw_shirt and print_words.

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 an implied usage example ('put this on a t-shirt') and names source types, but does not explicitly say when to choose this tool over draw_shirt, print_words, or other design tools. No alternatives or exclusions are provided.

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 it's not read-only, not idempotent, and not destructive, which is accurate. The description adds valuable behavioral context beyond annotations: it generates four pictures, returns the first as soon as ready, and provides the drawing's id. It doesn't disclose whether this consumes credits or if the other three images are accessible later, but the async/streaming behavior is well explained.

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?

One dense sentence covering purpose, input, constraints, use case, and output behavior. Front-loaded with the core function. Could be slightly more structured with separate sentences, but 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?

Given the simplicity (1 param, no output schema, clear annotations), the description covers what's needed: what it does, input format, behavior, and return. Missing details about image access after the first return and any credit usage, but those are minor for an agent to call 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?

Schema coverage is 100%, so the schema fully documents the single parameter including length constraints and description. The description adds the example and multilingual capability, but this is marginal value over the schema 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?

States a specific verb ('Draws') and resource ('t-shirt design') with the exact input form ('from a short idea in the person's own words'). It clearly distinguishes itself from siblings like draw_from_photo by specifying text-based 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?

Provides usage context ('For a shirt idea, a gift or merch') but does not explicitly state when to use this versus siblings like draw_from_photo or print_words. The examples and length constraints imply appropriate use cases without naming 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 already declare readOnly/idempotent/non-destructive, and the description adds genuinely useful context beyond them: that the link carries the price, that payment/terms/address live on lookunique.eu, and that 'nothing is bought here'. It does not, however, say what happens on failure (e.g. size out of stock).

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, front-loaded with what the tool produces and closing with the crucial scoping fact that no transaction occurs here. No filler, though the clause about colour/stock could be sharper.

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 read-only link-builder with no output schema, the description adequately conveys that the return value is a URL with an embedded price and that checkout happens elsewhere. However, with 7 parameters at 29% coverage, it leaves substantial input semantics unexplained.

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 only 29% and the description compensates only partially: it touches colour ('suits the design') and size ('in stock') and implies design_id, but says nothing about side, garment, quantity, or print_size, leaving four of seven parameters with no explanatory value anywhere.

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 resource ('the link that opens exactly this shirt on lookunique.eu, ready to order, with its price'), so the agent knows this returns a purchasable URL rather than a shirt rendering or shop metadata. It is distinguishable from show_shirt and shop_info by implication, but it never explicitly contrasts itself with those 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?

'After checking that the colour suits the design and the size is in stock' implies a pre-condition/workflow context, but there is no explicit when-to-use, when-not, or named alternative among the siblings (e.g. shop_info). Usage is inferable rather than stated.

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 the safety profile (readOnly, non-destructive, non-idempotent), and the description adds genuinely important behavior the agent could not otherwise know: the page is single-use, expires after 30 minutes, lives on the external domain lookunique.eu, and routes the uploaded photo back into this conversation. One-time use and the 30-minute window are exactly the constraints an agent must communicate to a user.

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, and the single most important fact – one-time page, 30-minute validity – is front-loaded. The second sentence adds the ownership/scoping link to the conversation without redundancy.

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 tool with annotations and no output schema, the description covers the essentials an agent needs: durability (one-time, 30 minutes), where the upload happens, and where the artifact ends up. The one remaining gap is that it never explicitly says the return value is a link the agent should hand to the user, which is left to the tool name.

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 no parameters, so there is nothing to document and the baseline is 4. The description correctly adds no parameter-level claims and does not invent any inputs.

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 makes clear this tool stands up a one-time external page where a person drops a photo, and that the resulting drawing is tied to this conversation – which distinguishes it from draw_from_photo and check_drawing. The verb ('creates/produces a link') is implied rather than stated, so the agent must infer that the tool's output is a shareable URL.

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 explains the mechanism but never says when to reach for this tool versus siblings such as draw_from_photo or order_link. There is no condition, prerequisite, or exclusion; the agent must infer the usage scenario from the phrase 'the person can drop a photo'.

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 meaningful behavior beyond annotations: it returns eight styles at once, renders only the person's words with the shop's dots as ornament, and clarifies that `after` produces eight more styles. Annotations already declare it is non-destructive and non-idempotent, and the description's 'sets... as lettering' is consistent with a write operation. It does not disclose permissions or rate-limit behavior, but this is not expected given the 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?

The description is front-loaded with the core action and then explains the two optional modes. It is efficient and largely free of filler, though the parenthetical list of styles is slightly verbose for the amount of decision-relevant information 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?

With no output schema, the description carries the burden of explaining what is returned, and it does so adequately: eight styles containing only the words, plus the ability to paginate more styles via `after`. The conditional `photo` behavior and the light-shirts-only restriction are also made 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%, so the schema already documents all three parameters in detail, including the `after` pattern and the `photo` pattern. The description repeats much of that meaning (e.g., `after` as a returned drawing_id, `photo` for light shirts only) but adds little syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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: it sets the person's own words as lettering on a t-shirt, returning eight styles at once. It clearly distinguishes this from siblings like draw_shirt by centering on user-supplied text and style generation, not on drawing a shirt.

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 explains the mode-switching logic precisely: pass `after` to get eight more styles for the same words, pass `photo` to combine words with a drawn picture (light shirts only). It does not explicitly name when to prefer a sibling tool, so it falls just 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds little beyond that, though the field list (prices, countries shipped to, printing time, returns rule) usefully tells the agent what data is available. It says nothing about result format, freshness, or whether the catalog is filtered.

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 a colon-separated inventory; no filler or repetition. The list is long but each item carries information, and it stops as soon as it is done.

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 and no parameters, the description carries the burden of telling the agent what comes back, and it does so across pricing, colours, sizes, print placement, shipping destinations, turnaround time and returns policy. Only the shape/format of the returned data is unspecified, which is a minor gap for a zero-argument informational 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?

The tool takes zero parameters, so the baseline is 4 — there is nothing for the description to disambiguate. The enumerated content items describe the response payload rather than inputs, which is mildly helpful but not a parameter contract.

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 the resource (the shirts lookunique prints) and enumerates the content categories, so an agent can infer it is a static catalog/info tool. However it is a bare noun phrase with no verb — it never says it 'returns' or 'looks up' anything, leaving the actual action implicit. It is distinguishable from the action-style siblings (draw_shirt, print_words, order_link), but only by 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?

There is no when-to-use, when-not-to-use, or alternative named. The agent must guess that this is the tool for product/catalog questions and that the other seven siblings are for generating or ordering. No prerequisites or call ordering are stated.

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 cover the safety profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower; the description usefully discloses what the result contains — a picture plus price and the colours the design can be printed on — which matters because there is no output schema. It does not, however, mention defaults for colour/garment beyond what the schema states.

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 that packs purpose, parameter summary, and return payload without filler. It is dense but readable, and nothing egregious is wasted.

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?

As a read-only preview tool with no output schema, the description reasonably covers the essentials by naming the visual output and the accompanying price and colour availability. The main omission is any routing cue versus draw_shirt/check_drawing, which an agent needs in this crowded sibling set.

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 60%, so the schema documents most fields (colour default, garment options, design_id origin). The description restates the parameter set (garment='cut', colour, print size s/m/l, side) and parenthetically re-states the enum values rather than adding meaning like which combinations are valid or how colour accepts a name or id.

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 clearly what the tool produces: a rendered picture of a design on a real shirt with its price and compatible print colours. The verb is implicit ('A picture of...') rather than action-first, and it never distinguishes itself from the similarly named sibling draw_shirt, so an agent has to infer that this is a preview rather than a drawing 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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives, despite the presence of closely related siblings draw_shirt, check_drawing, and draw_from_photo. The description describes the output but not the workflow position or prerequisites (e.g. that design_id must come from a drawing).

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