Skip to main content
Glama

Lexington

get_design

The theme's design system: typography recipes, what each colour scale means, spacing rhythm, components, do and don't, plus roles.json (the same as data: action, panel, ink, muted, rule, radius, heading and body recipes, measured from the sections). Read before changing anything visual, reskinning, or aliasing the palette onto a host.

Input Schema

NameRequiredDescriptionDefault
themeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It implies a read-only retrieval operation through 'Read before' and describes the content categories returned, but it does not state permissions, auth requirements, response format, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description front-loads the resource and then enumerates its contents without filler. The long single sentence and parenthetical roles list are dense and slightly hard to parse, but the information is purposeful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter retrieval tool with no annotations and no output schema, the description covers the return categories and the trigger for reading it. It still omits how to supply the theme parameter and does not mention permissions, auth, or output form, leaving meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one required 'theme' parameter and schema description coverage is 0%. The description only frames it as 'The theme's design system' and never explains what value the theme parameter expects, such as an ID, name, or identifier from list_themes, so the schema gap is not compensated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource, 'The theme's design system,' and enumerates what it returns: typography recipes, colour scale meanings, spacing rhythm, components, do/don't, and roles.json details. It does not explicitly distinguish itself from siblings such as get_guidelines or get_theme_setup, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear when-to-use guidance: 'Read before changing anything visual, reskinning, or aliasing the palette onto a host.' However, it provides no when-not-to-use guidance and does not name alternatives among the sibling tools.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources