Read selection context

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool returns normalized DesignIR nodes but does not disclose what 'normalized' means, whether the operation is read-only (though 'Return' implies it), what happens if no selection exists, or any side effects. The description is minimal and leaves important behavioral aspects unspecified.

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 a single, concise sentence that front-loads the core action and output. It is appropriately sized for a simple tool, though it could have added a brief note about the host parameter or usage context without becoming verbose.

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 tool has no annotations, no output schema, and a single parameter with 0% schema description coverage, the description is too sparse. It does not explain what 'host selection' means, how the host parameter affects the result, or what DesignIR nodes are. An agent would need to infer or experiment to understand the tool's full behavior, especially in the context of many sibling tools.

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 compensate for the undocumented parameter. The description does not mention the 'host' parameter at all, but the schema provides an enum with 'figma' and 'xd', which gives the agent the necessary values. The description adds no meaning beyond the schema, so a baseline score of 3 is appropriate given the single parameter is well-constrained by the enum.

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 ('Return') and resource ('current host selection normalized as DesignIR nodes'), which clearly identifies what the tool does. It does not explicitly distinguish itself from sibling tools like get_screen_context or get_visual_context, but the mention of 'host selection' and 'DesignIR nodes' provides enough specificity to infer its purpose.

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 provides no guidance on when to use this tool versus alternatives such as get_screen_context or get_visual_context. It does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer usage from the name and description alone.

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