Createdby.you

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that: only *current public* options and prices are returned, sizes and material stay coupled to price, and photorelief is read-only over MCP. It stops short of saying what happens when the ID is unknown or invalid.

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 primary read behavior, then the ID-resolution mode, then the boundary to sibling tools. "Maten en materiaal blijven aan de prijs gekoppeld" is dense domain phrasing that is somewhat opaque on first read, but nothing is padding.

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 the description must convey what comes back; it does at a high level (options and prices, photorelief readable only) without describing response shape or volume. For a single-parameter read tool with full annotation coverage it is close to adequate.

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 0% and the schema only declares a 1-160 char string, so the description carries the load. It explains that the ID can be a product identifier or a variant ID sourced from search_catalog, which is exactly the meaning the bare schema lacks.

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 ("Lees alle huidige openbare opties en prijzen van een product") plus a second mode ("vind de variant bij een variant-ID"), so the agent knows both the read shape and the ID-resolution use case. It names search_catalog as the source of variant IDs and start_wallpaper_design as the design path, which distinguishes it from siblings without opening any schema.

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?

"vind de variant bij een variant-ID uit search_catalog" gives a concrete upstream workflow, and "catalogusbehang ontwerp je met start_wallpaper_design" is an explicit when-not plus alternative. It does not clarify how it relates to get_wallpaper_design or the quote/handoff siblings, so the exclusion set is only partial.

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?

Well beyond the annotations, the description discloses link lifetime (24-25 hours, then it falls back to opening the design in the studio), the failure mode where a stale quote yields QUOTE_CHANGED with the new price instead of a link, and that an own-image design gives the opening browser its own copy. These are exactly the runtime traits an agent cannot infer from the readOnly/idempotent hints.

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 and dense: the core action comes first, followed by constraints, expiry, and the error case, with no filler sentences. It is occasionally terse to the point of compression, especially the final sentence about own-image copies.

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 three-parameter tool with no output schema, the description covers the important ground: what the caller gets back (a link or QUOTE_CHANGED with the new price), the time limit, and the country limit. It stops short of describing the response shape or which field carries the URL, which would matter for a tool with no output 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 description coverage is 0%, so the description carries the whole burden. It fully explains quote_sha256 (the price the customer saw, with QUOTE_CHANGED on mismatch), but says nothing about design_id beyond context and only constrains country indirectly via "Alleen voor Nederland" without explaining the parameter or its two-letter pattern.

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 opening sentence names a specific verb and outcome: produce a link that places this design at this price into createdby.you's shopping cart. It immediately delimits scope (no ordering or payment through this link), which separates it from get_wallpaper_quote and get_wallpaper_handoff without the agent needing to open any schema.

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 implied rather than stated: the description gives a country restriction ("Alleen voor Nederland") and a negative boundary (no ordering or payment), but never says when to choose this over get_wallpaper_handoff or get_wallpaper_quote. The agent must infer the routing from the sibling names.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the description wisely spends its words elsewhere: 'nothing is stored' and the fact that settings are validated against the current product, which warns that a design can come back stale or invalid. The upload status states (wacht_op_upload, klaar, verlopen) are concrete behavioral information that the annotations do not carry.

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 compact sentences, front-loaded with the core read operation, then the upload-status branch, then the no-storage guarantee. Dense but every clause carries information; only the phrasing is slightly compressed into run-ons.

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 read with no output schema, the description covers what comes back at a high level (settings, matching rooms, status enum values, a new design_id on completion) and explicitly reassures that nothing is persisted. The exact response shape is not spelled out, but the essential agent-facing behavior is present.

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 is one parameter and the schema description coverage is 0%, so the schema only gives type and length constraints. The description says designs are looked up by design_id and that a completed upload returns a new design_id, which is useful but does not explain where a design_id comes from, whether it must be a current or historical ID, or how an expired ID behaves.

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 ('read the settings of a design from its design_id') and adds the scope that the design is validated against the current product and includes the associated rooms. That distinguishes it clearly from mutating siblings such as update_wallpaper_design or start_wallpaper_design, though no sibling is named 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?

It implies the when by context: read-back after creating or updating a design, and polling an own-image upload via its status. It does not state when not to use this tool or name an alternative such as get_wallpaper_handoff or render_wallpaper_preview, so the agent has to infer the routing.

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 declare readOnly=true, idempotent=true, closed-world and non-destructive, so the safety profile is covered. The description adds real value beyond that: it explains the link's payload differs by design type — catalog wallpaper encodes product, colour, composition, room and studio settings, whereas an own-image design yields a personal copy for the customer.

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 then the branch-specific payload detail. Nothing is padded, though the catalog-versus-own-image detail is somewhat dense and would read better if split or bulleted.

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 tool without an output schema, the description does explain the differing link content per design type, which is the key behavioral nuance. It still omits how design_id is sourced and how this tool relates to the near-identical checkout-link sibling, which an agent needs to pick 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 is a single required parameter with 0% schema description coverage, so the description carries the full burden of explaining design_id. It only refers to 'dit ontwerp' (this design) without saying what ID is expected, how to obtain it, or whether it comes from start_wallpaper_design or get_wallpaper_design.

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 outcome: it produces the link that opens this design in the createdby.you studio, where the customer checks out. The resource and result are clear, but it never distinguishes itself from the very similar sibling get_wallpaper_checkout_link, leaving an agent to guess which of the two to call.

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 implied by the handoff narrative (the customer puts the design in the cart and pays), so the intent context is understandable. However, there is no explicit when-to-use versus get_wallpaper_checkout_link or get_wallpaper_quote, and no stated preconditions for the design being ready to hand off.

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, so the safety profile is covered. The description adds real behavioral context the annotations cannot: amounts are in eurocents, the quote mirrors the shop's own calculation, and the failure path returns orderable: false plus reasons instead of a price — an exception mode an agent would otherwise not anticipate.

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 action and its guarantee, then the returned figures, then the fallback branch. Given there is no output schema, enumerating the returned fields earns its space; nothing is redundant.

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 usefully covers both the success shape and the not-orderable branch, and the eurocents unit removes a common misinterpretation. The remaining gap is the country parameter and whether it changes pricing or shipping, which an agent would have to guess.

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 0%, so the description carries the full burden, and it does not name either parameter. design_id is only loosely implied by 'ontwerp', and country — which plausibly drives shipping cost and pricing — is never mentioned at all, leaving its effect on the returned quote unknown.

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 ('Bereken de actuele prijs van een ontwerp') and pins down the source of truth ('dezelfde berekening als de winkel'). It enumerates the returned quantities (totaal inclusief btw, gefactureerde m², muurmaat met snijrand, verzending, totaal met verzending), which makes it unmistakable from siblings like get_wallpaper_design or render_wallpaper_preview.

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?

Clear context: use it to get a live, shop-identical price quote for a design, and it explicitly defines the branch where the design cannot be ordered (orderable: false with reasons and no price). No sibling alternatives are named and no explicit 'when not to use' is offered, but no sibling provides pricing, so the risk of misselection is low.

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 declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is covered. The description still adds real value beyond them: output format and size cap, the no-upscaling behavior at strong zoom, the note that furniture is not a measurement reference, and the fact that preview_url is a stable address for exactly this image.

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 output format and size limit are front-loaded, followed by the two view modes and the return-address note. It is dense but every clause carries information; only the parenthetical zoom remark is close to expendable.

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 fully covers what comes back: an image, WebP, max dimension, a fixed preview_url, and the guarantee that nothing is persisted. Combined with the detailed view semantics, an agent has everything needed to call this 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 description coverage is 0%, so the description must carry the parameter meaning, and it does for 'view': flat is the default and shows the wall crop including mirroring, room shows the in-situ render with or without furniture. 'design_id' is left unexplained, but its meaning is self-evident from the tool purpose.

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: it returns an image of a wallpaper design, in WebP, capped at 1200 px. That clearly separates it from siblings like get_wallpaper_design (design data) or get_wallpaper_quote, so an agent can pick it without opening the schema.

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 implied rather than stated: the agent infers it should call this when it needs a visual preview, and the two view modes are explained in detail. However, there is no explicit 'use this instead of get_wallpaper_design' routing or statement of when a preview is not appropriate.

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 closed-world, and the description reinforces the safety scope ('Alleen lezen; geen upload of aankoop'). More valuably, it discloses what the response contains — stable product/variant IDs, exact dimensions, VAT prices, availability, and product links — which compensates for the absent output 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?

Three tight sentences: what it searches, what it returns, and its safety scope. Nothing is padded and the core purpose 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?

For a read-only search with no output schema, the description covers purpose, return fields, and safety adequately. The remaining gap is pagination behaviour (limit/offset defaults and caps), which an agent would otherwise have to guess.

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 0% for four parameters, so the description must carry the load. It accounts for 'query' (topic, colour, product name) and indirectly for 'category' by naming the two product types, but says nothing about 'limit' or 'offset' pagination semantics or the 240-character/20-result bounds.

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 and resource ('Zoek openbaar verkrijgbaar behang en fotoreliëf') and the facets searched (onderwerp, kleur, productnaam), which is far more specific than the title alone. It does not explicitly differentiate itself from siblings such as get_product, but the search-vs-retrieve distinction is inferable.

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 implied — search the public catalogue when you have a topic, colour, or product name — but there is no explicit statement of when to use this instead of get_product or the design/quote tools. An agent must infer the routing from the sibling names.

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 it discloses accepted formats (JPEG/PNG/WebP up to 40 MB), that the image is stored privately, that the returned status is wacht_op_upload when no image is supplied, that small images only produce a print_quality warning and never a rejection, and that identical image plus identical settings yield the same design_id (concrete support for idempotentHint). These are exactly the facts an agent needs before invoking.

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 primary action, then the no-image fallback, then constraints and follow-up tools. Dense but every sentence carries operational information; only the parenthetical 'tot dezelfde design_id' style tail slightly pads the end.

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, yet the description still explains return values (design_id, status, upload_url, rooms, print_quality) and what to do with them. For a 5-parameter creation tool with nested image/wall objects, nothing essential 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 0% schema description coverage the description must carry the parameters, and it does: image contents, wall_cm in cm, room as a value taken from rooms in a prior response, and furniture=false meaning an empty room. However, it says material is 'altijd vlies' while the schema enum offers vlies and vinyl, leaving a real ambiguity about whether the material parameter is meaningful.

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 wallpaper from an image the customer uploaded or created in this conversation, with wall dimensions in cm. This implicitly separates it from the catalog-based sibling start_wallpaper_design; it does not name that sibling explicitly, so a 4 rather than 5.

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 explicit branching: pass image when a file is available, call without image otherwise, then hand the upload_url (24h valid) to the customer and call get_wallpaper_design with the returned design_id once uploaded. It also explains the room and furniture switches and names the downstream tools (update_wallpaper_design, render_wallpaper_preview, get_wallpaper_quote, get_wallpaper_handoff, get_wallpaper_checkout_link).

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 reinforces this with 'er wordt niets opgeslagen' plus a statement of what is returned ('een design_id dat het hele ontwerp bevat'). It goes further by spelling out fallback behaviour for omitted optional parameters (original colour, spacious composition, default room). It does not describe whether the design_id expires or how it later feeds update_wallpaper_design/render_wallpaper_preview.

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?

Roughly five sentences, front-loaded with what the tool does and the target wall size, then parameter semantics, then the return value, then the exclusion and alternative. Every clause carries information: defaults, data sources, and the sibling pointer.

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 a nested object and no output schema, the description covers the return value (design_id), the no-persistence guarantee, defaults for all optional parameters, and the boundary against the own-image sibling. Only the product_id source is left implicit and there is no hint about lifecycle of the returned design.

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 0% schema description coverage the description carries the load, and it does: wall_cm as own wall size in cm, material as vlies/vinyl, colour as 'uitvoering' and composition as 'compositie' from the product link, room as the room of the mood image taken from 'rooms' in the response, and furniture=false showing the room unfurnished. product_id is only implied via 'uit search_catalog', and the default behaviour is stated rather than the accepted value formats.

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 opening sentence names a specific verb and resource ('Start een ontwerp voor catalogusbehang') and scopes the input source ('uit search_catalog'), the sizing unit ('eigen muurmaat in cm') and the material options ('vlies of vinyl'). It also points to the sibling that handles the adjacent case ('start_own_image_wallpaper_design'), so an agent can separate the two without opening either schema.

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?

Guidance is explicit where it matters: use this tool for catalog wallpaper but use start_own_image_wallpaper_design for a design from your own image, and 'Fotoreliëf kan niet' rules out one case outright. It also explains where the optional colour/composition/room values should come from (the product link, the 'rooms' list in the response). No explicit routing against get_wallpaper_design or render_wallpaper_preview, hence not 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?

Beyond the annotations, the description discloses high-value behavior: out-of-range values are clamped to the nearest valid one and flagged via adjusted=true, room/furniture affect only the ambience image and not the price, own-image designs cap zoom at 400 and force material to vlies, and nothing is persisted ("Er wordt niets opgeslagen"). That last line resolves the apparent tension between "Wijzig" and readOnlyHint=true, so the annotations and prose reinforce each other.

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?

Very dense with essentially zero waste, and the core action plus every changeable field sits in the first sentence. It is delivered as one continuous block without breaks or a return-value sentence, so it is efficient but harder to scan than a lightly structured version would be.

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 nested-schema mutation-style tool with no output schema, the description covers the action, the clamping contract, the adjusted flag and the design_id return, plus the own-image exception. What is missing is a fuller account of the return payload (what else is returned alongside design_id, and which fields can trigger adjusted) now that no output schema exists to fill that gap.

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 0% across 8 parameters, so the description carries the burden and does substantial work: zoom_percent 100 means full width/height, position_percent is the crop origin as a percentage from the left (x) and top (y), and room/furniture are cosmetic. Still undocumented are wall_cm, mirrored, and the material/zoom interaction for non-own-image designs, so it does not fully compensate.

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 opening clause names a specific verb ("Wijzig") plus the exact resource (a wallpaper design) and enumerates the mutable facets: wall size, zoom, crop, mirroring, material, room, furniture. It also states the outcome ("krijg een nieuw design_id"), which cleanly separates it from the sibling readers get_wallpaper_design/get_product and the initiators start_wallpaper_design/start_own_image_wallpaper_design.

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 implied rather than stated: an agent can infer this is for tweaking an existing design, and the own-image clause hints at the start_own_image_wallpaper_design path. However, no sibling is named as an alternative and no condition is given for when to call this versus re-running start_wallpaper_design or render_wallpaper_preview.

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