color_by_parameter

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

With no annotations, the description carries the full burden for side effects. It discloses that elements without a value are gray and that a legend is returned, but it does not mention whether the coloring persists, how it interacts with existing overrides, or whether it applies to all views. More disclosure is needed for a mutation tool.

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 concise and well structured: a two-sentence functional overview followed by a tidy Args list. Every sentence adds value, with no redundancy or 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?

The tool has no output schema, so the description is the only source for return values. It mentions 'get the legend back' but not the legend's format or contents. It also omits side-effect scope (e.g., active view, persistence) and prerequisites. While the core purpose is clear, these gaps leave the description incomplete for a mutation 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 schema has no descriptions (0% coverage), but the description's Args section provides meaningful explanations for all three parameters: examples ('Doors', 'Fire Rating'), type hints ('instance or type'), and optionality ('Omit for all levels'). This fully compensates for the schema gap.

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 is highly specific: 'Colour every element of a category by its value of one parameter, one colour per distinct value, and get the legend back.' This clearly identifies the action, resource, and distinct behavior (legend, gray for no value), setting it apart from siblings like override_graphics.

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 a clear use case: 'Great for visual QA, e.g. doors by Fire Rating.' This gives the agent context for when to invoke the tool, though it does not explicitly mention when not to use it or name alternatives.

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