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.