tidy_context

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

With no annotations provided, the description takes on the full burden of behavioral disclosure. It communicates the return scope in detail and goes further by warning that not calling it leads to guessing, potentially causing 'raw hex' where components are affected. This gives an agent a strong sense of when and why the tool matters, even if it doesn't cover all edge cases like error handling or performance.

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. It opens with the core purpose, lists what's included, provides a direct instruction on when to call it, and closes with a rationale that motivates the action. Every word earns its place, and the most critical information 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 context-gathering tool with only optional parameters and no output schema, the description covers all essential information: what it returns, when to use it, and why it matters. It doesn't explicitly document default behavior for parameters, but the schema already handles that, making this description sufficient for an agent to decide when and why to invoke it.

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 input schema already describes all three parameters (detail, include, figmaFile) with enums and defaults, covering 100% of the information needed. The description adds no extra context about parameters, which is acceptable given the schema's completeness; the baseline of 3 is appropriate.

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 uses a specific verb in 'Get the design system contract' and enumerates the exact content: collections, modes, token names grouped by intent, component variant axes, and conventions. This makes it immediately differentiable from sibling tools like tidy_status or tidy_health, which likely address other aspects of the design system.

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 explicitly instructs to 'Call this before writing anything into the file,' giving clear usage context. It doesn't name alternative tools or provide when-not-to-use conditions, so it stops short of a 5, but the conditional guidance is strong and actionable.

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