Recommend a minimal UI stack

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds one genuinely useful behavioral trait: task text is a 'legacy inference path,' signaling it is a deprecated/fallback input rather than the primary one. No contradiction with annotations exists, but the description does not disclose output shape, ranking behavior, or handling of conflicting inputs.

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 21-word sentence with zero filler. The primary function is front-loaded ('Compute a minimal UI composition from structured host/task profiles') and the legacy qualifier trails naturally. Every word 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?

This is a high-complexity tool: 6 parameters, two nested objects containing roughly 18 fields total, no output schema, and 0% schema coverage. A single sentence cannot carry that weight. The agent is left without any indication of what the tool returns, how existing_stack or constraints influence the recommendation, or how the duplicated fields relate. Significant gaps remain for correct invocation and interpretation.

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 burden and partially compensates: it maps 'structured host/task profiles' to host_profile and task_profile, and 'task text' to the task parameter, clarifying the primary vs legacy input paths. However, constraints, existing_stack, and rive_asset_rights are entirely unmentioned, and the duplication of constraints/rive_asset_rights at both top level and inside task_profile is not clarified. Meaningful but incomplete compensation.

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 action ('Compute a minimal UI composition') with a clear input source ('structured host/task profiles'), and the title anchors the resource as a 'minimal UI stack'. It is distinguishable from siblings — list_libraries, search_components, and get_install_instructions are about discovery/guidance, while this composes a recommendation. Minor ambiguity: 'composition' vs 'stack' terminology isn't unified, and the exact nature of the output is left abstract.

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 'with task text supported as a legacy inference path' is an implicit usage signal: structured profiles are the preferred path and free-text task is a fallback. However, there is no explicit when-to-use vs alternatives (e.g., when to pick this over search_components or list_libraries), and no exclusion criteria or prerequisites are stated. The guidance is implied rather than spelled out.

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