get_design_context

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

No annotations are provided, so the description bears the full disclosure burden. It usefully reveals a non-obvious default (screenshots included unless includeScreenshot:false) and a scope limit ('no cloud code generation'), but says nothing about permissions, whether the operation is read-only, or how output is shaped when the budget is hit.

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 tight sentences with zero filler, and the core purpose is front-loaded ahead of the alternatives and defaults. Minor density jargon ('native properties', 'cloud code generation') slightly reduces first-read clarity but costs little.

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 an eight-parameter tool with no annotations and no output schema, the description covers purpose, the key default, and alternatives, but does not describe the returned structure or how the depth/maxNodes/maxBytes budgets interact. Adequate, with a visible gap around what the agent will actually receive.

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 coverage is only 50%, yet the description adds real meaning for two of the eight parameters: the includeScreenshot default and the quality/scale interaction are clarified in prose. It still leaves depth, maxNodes, maxBytes, and nodeId semantics to the schema, so the gap is only partly compensated.

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?

States a concrete verb and resource ('Read a target subtree and CSS for design-to-code work'), which tells the agent exactly what comes back. It partially differentiates from siblings by naming get_metadata as the lighter alternative, though the boundary with get_screenshot and get_component_context is left implicit.

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?

Gives explicit when-not guidance ('do not read an entire subtree for a few descendant values'), names concrete alternatives (bounded get_metadata or one scoped script), and states a conditional default for screenshots. An agent can decide between this and the sibling read tools without further inference.

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