Get design context (Figma compatible)

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

Annotations already establish the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's job is to add context beyond that. It does so by disclosing the composition of the returned payload in detail — auto layout, styles, variables, component links, interactions — which is meaningful behavioral context, especially since there is no output schema. It does not explain how depth controls traversal or the cost of a deep fetch.

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 front-loaded sentence that puts the resource first and the purpose clause last; no filler or restated boilerplate. The long enumeration is dense but each item is a real content type rather than padding. Slightly heavy punctuation (dash-separated list) but well structured overall.

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 five-parameter tool with a six-value language enum, no required parameters, and no output schema, the description covers only the return payload. It omits parameter behavior entirely — what depth defaults to, whether includeProperties/includeCode gate the returned fields, and what nodeId expects — and gives no routing guidance against sibling readers. The annotations cover safety, but the parameter and selection gaps are too large for a tool of this complexity.

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% across five parameters, including an enum (language: css/html/react/leptos/swiftui/compose) and control flags (includeCode, includeProperties, depth 0-64). The description's mention of 'the facts a code generator needs' only faintly hints at includeCode, and it says nothing about nodeId, depth semantics, or the language enum. With zero schema descriptions, the description should have compensated and largely does not.

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 names the resource precisely ('the design context of a layer') and enumerates exactly what that context contains — geometry, auto layout, fills, strokes, effects, typography, styles, variables, component links, interactions. An agent immediately understands what this returns. It loses a point because it never distinguishes itself from close siblings like get_node, get_metadata, inspect_document, or get_code, which an agent must disambiguate on its own.

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 closing clause 'the facts a code generator needs' implies the downstream use case (feeding code generation), which is a genuine usage signal. However, there is no explicit when-to-use, no when-not-to-use, and no named alternative among the many sibling read tools (get_node, get_metadata, get_code, inspect_document). Usage is implied rather than stated.

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