xd_get_design_system

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

No annotations exist, so the description carries the full behavioral burden. It implies a read-only extraction and does usefully describe the three output shapes (json, css custom properties, tailwind theme.extend), but says nothing about permissions, cost, failure modes, or whether the file must be open — significant gaps for a document-wide extraction.

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 dense sentence with zero filler; the extracted artifacts are listed first and the output formats come last, which is the right front-loading order.

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?

With no output schema, the description does an adequate job of enumerating returned content, and it covers the format parameter. What is missing is the relationship to xd_get_design_tokens and any operational preconditions, which matter for a document-wide extraction 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?

Schema coverage is 50%: 'file' is documented in the schema but 'format' only has an enum and default with no description. The description compensates well by explaining what each format produces ('css (custom properties)', 'tailwind (theme.extend)'), adding real meaning beyond the bare enum values.

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 specific verb ('Extract') and resource ('the design system actually used in the file') and enumerates exactly what is returned: color palette with usage ranking, typography and size scale, radii, stroke widths, shadows. The one gap is that the near-identical sibling xd_get_design_tokens is never mentioned, so an agent cannot tell the two apart from the description alone.

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?

There is no guidance on when to choose this over xd_get_design_tokens, xd_get_shared_assets, or xd_audit_design, all of which plausibly overlap. No preconditions are stated either, such as whether the .xd file must be open in Adobe XD or whether this is a costly full-document scan.

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