Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@aurum-mcp Show me the AurumChip component details"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Talk to the Aurum Design System from your LLM client. Components · tokens · icons · Figma node IDs · changelog — all queryable from Claude Code, Cursor, Copilot CLI, Gemini, and Claude Desktop.
aurum-mcp is a Model Context Protocol
server that surfaces the Aurum design system catalogue to LLMs. It reads a
bundled JSON manifest (auto-synced from
changejarapp.github.io/aurum-android)
and exposes 9 tools the LLM can call to answer questions like:
"Show me how to use AurumChip."
"What colour token do we have for negative-feedback text?"
"What's the Figma node for AurumTopAppBar?"
"Give me the icon for a back arrow."
"What changed in the most recent release?"
Pick your client below, paste the snippet into the matching config file, restart the client.
.mcp.json in your project root, or ~/.claude.json){
"mcpServers": {
"aurum": {
"command": "npx",
"args": ["-y", "github:atri-jar/aurum-mcp#latest-stable"]
}
}
}~/.cursor/mcp.json){
"mcpServers": {
"aurum": {
"command": "npx",
"args": ["-y", "github:atri-jar/aurum-mcp#latest-stable"]
}
}
}~/.copilot/mcp.json){
"mcpServers": {
"aurum": {
"command": "npx",
"args": ["-y", "github:atri-jar/aurum-mcp#latest-stable"]
}
}
}~/.gemini/settings.json under mcpServers){
"mcpServers": {
"aurum": {
"command": "npx",
"args": ["-y", "github:atri-jar/aurum-mcp#latest-stable"]
}
}
}~/Library/Application Support/Claude/claude_desktop_config.json)Same shape — drop the snippet above into mcpServers. Restart the app.
That's it. No npm registry, no ~/.npmrc, no PAT, no environment
variables. Public Git, public npx.
Related MCP server: WordPress Design System MCP Server
The default snippet uses #latest-stable — a CI-managed Git tag that
always points at the newest stable release. Behaves like npm's
@latest dist-tag: you get auto-updates on each fresh npx cache miss
(~10 min to a few hours, depending on your client's cache).
For reproducibility — automated scripts, audited setups — pin to an explicit tag:
"args": ["-y", "github:atri-jar/aurum-mcp#v0.1.0"]Every version of aurum-mcp ships the manifest from the matching Aurum
library version (@aurum-mcp:0.1.6 ⇄ aurum:0.1.6). Call
get_aurum_version from your LLM client to see exactly what you're
talking to.
Tool | Purpose |
| Enumerate all Aurum components, grouped by family |
| Full component spec — KDoc, signature, params, Figma deeplink |
| Token tables: color (semantic + visual), spacing, radius, borderWidth, iconSize, elevation, typography |
| Find icons by name fragment or category |
| Single icon: drawables, Compose path, line+fill Figma deeplinks |
| Per-version changelog as markdown — defaults to |
| Reverse-lookup: Figma node ID / URL → matching Aurum components & icons |
| Free-text search across all content with next-tool suggestions |
| Manifest provenance: version, SHA, generation timestamp |
See docs/tools.md for full input schemas and example
responses.
npx-from-Git, not npm?We considered three distribution channels (public npm, GitHub Packages,
npx-from-Git) and chose the third because for a team-internal tool
optimising for simplicity, full ownership, and zero new infrastructure:
Zero new accounts to govern. No npm org, no NPM_TOKEN rotation,
no 2FA recovery, no 72-hour publish-permanence anxiety. The repo IS
the artefact, end-to-end.
Branch-based testing for free. Want to try a feature branch?
Just change the snippet to #feat/branch-name — done. With npm
you'd publish a pre-release tag that lives in the registry forever.
Same auth users already have. This repo is public; team members have GitHub access; nothing new to configure.
Marginal install delay. First-spawn is ~5–10 s of clone + build vs. ~2–5 s for npm. Cached spawns are identical.
Trade-offs we accept: less polished version-pinning UX (Git tags vs.
semver ranges) and no public-npm discoverability. The full reasoning
lives in docs/architecture.md.
git clone https://github.com/atri-jar/aurum-mcp.git
cd aurum-mcp
pnpm install
pnpm dev # run the server via tsx + stdio
pnpm inspect # spawn the official MCP Inspector UI
pnpm build # tsc → dist/
pnpm smoke # end-to-end tools/list + tools/call testThe server reads data/manifest.json (committed). To pull the latest
manifest from the live Aurum gallery and update the bundled copy:
make manifest-fetchCI does this automatically (see .github/workflows/sync-manifest.yml).
The Aurum design system lives in
Changejarapp/aurum-android
(private) and ships a public gallery at
changejarapp.github.io/aurum-android.
Its tooling/gallery/generate.py script aggregates components, tokens,
icons, Code Connect mappings, and the changelog from a single set of
parsers. We added a --emit-manifest flag that produces a structured
JSON projection of the same data — the contract is
tooling/manifest/schema.json in aurum-android. This MCP server is
the JSON's read-side: it loads the manifest at boot, indexes it, and
serves the 9 tools above. One source of truth, two render targets
(HTML for humans, JSON for agents). When aurum-ios ships, its
manifest plugs in as a sibling source — the MCP code is platform-
agnostic.
Full pipeline diagram: docs/architecture.md.
Issues and PRs welcome. See docs/contributing.md
for the workflow (manifest sync, drift-check, release process). Code
style: TypeScript strict, Prettier defaults; no business logic in
markdown formatters.
MIT — see LICENSE.
Return the Aurum library version, manifest SHA, generation timestamp, and platform coverage. Use this to verify which Aurum snapshot you are reasoning about before answering version-specific questions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It discloses the returned information (version, SHA, timestamp, platform coverage) without mentioning any side effects, which is adequate for a read-only metadata tool.
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?
Two sentences that are front-loaded with the primary purpose and a usage hint. No superfluous information.
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?
Given the tool's simplicity (no parameters, no output schema), the description provides sufficient details about what it returns and its intended use case. It is fully adequate for an AI agent to select and invoke correctly.
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 tool has no parameters, and the schema coverage is 100%. The description adds no parameter info, which is acceptable since there are none to document. Baseline of 4 applies.
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 clearly states the tool returns the Aurum library version, manifest SHA, generation timestamp, and platform coverage. It distinguishes itself from sibling tools like get_changelog and get_icon by focusing on version metadata.
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 states when to use this tool: before answering version-specific questions. While it does not list alternatives, the context of sibling tools makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one or more Aurum changelog entries as markdown. Default returns the [Unreleased] section. Pass a specific version (e.g. 0.1.5) for that release, or all for the full history.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | Version to fetch (`Unreleased`, a semver string, or `all`). Defaults to `Unreleased`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output format (markdown) and parameter behavior. With no annotations, it carries the full transparency burden, which it meets without omitting key traits.
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?
Two sentences cover purpose, default, and options. Every word earns its place; no redundancy.
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?
Sufficient for a simple tool with one optional parameter. Lacks error handling or sample output, but adequate for correct invocation.
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 100% but description adds meaning by explaining default, accepted values (Unreleased, semver, 'all'), and output format.
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?
Clearly states it returns Aurum changelog entries as markdown. Distinguishes itself from sibling tools (get_component, list_tokens, etc.) by specifying a unique resource and purpose.
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?
Provides clear instructions on when to use (default Unreleased, specific version, or 'all') but lacks explicit guidance on when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full details of a single Aurum component by name: KDoc, Compose signature, every parameter (with types, defaults, and per-param docs), preview function names, Figma deeplink, Code Connect path, and gallery URL. Use after list_components or search to get the canonical snippet for a component.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Composable name, e.g. `AurumChip`. Case-sensitive. | |
| platform | No | Reserved for future cross-platform manifests. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description conveys a read-like operation ('Fetch') and details the return data. It does not contradict any annotations and adds meaningful behavioral context.
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?
Two sentences, no waste. Front-loaded with the core purpose, then usage guidance. Efficient and clear.
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?
Given no output schema, the description thoroughly explains the return data (KDoc, signature, parameters, preview, Figma link, etc.), making it complete for a fetch 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 100%, baseline 3. The description adds context: name is case-sensitive and platform is reserved for future use, enhancing the schema's meaning.
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 clearly states it fetches full details of a single Aurum component by name, enumerating specific data points (KDoc, signature, parameters, etc.). This distinguishes it from siblings like 'list_components' which list components.
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?
Explicitly advises to use after 'list_components' or 'search' to get the canonical snippet, providing clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details for a single Aurum icon by name: drawable resource paths, Compose path (AurumIcons.<Category>.<Name>), paired line/fill Figma node IDs, and deeplinks. Pass weight to focus on one variant.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Icon name, e.g. `ChevronRight`. Case-insensitive. | |
| weight | No | Which weight to highlight (`line`, `fill`, or `both`). | both |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the return types (paths, IDs, deeplinks) and the effect of the weight parameter. It does not mention side effects, authentication needs, or read-only status, but the operation is clearly a data fetch with no destructiveness implied.
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?
Two sentences with no redundancy. The first sentence states purpose and return types concisely; the second adds a usage hint. Every sentence earns its place.
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?
Given no output schema, the description adequately lists what is returned. For a simple tool with two parameters, it covers the core functionality. It could mention missing-icon behavior or pagination but is otherwise complete.
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 provides full descriptions for both parameters (100% coverage). The description adds only minor nuance ('Pass weight to focus on one variant'), which largely restates the enum's purpose. Thus, the description adds limited value beyond the schema.
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 ('Fetch full details') and identifies the resource ('single Aurum icon by name'). It lists the specific information returned (drawable resource paths, Compose path, Figma node IDs, deeplinks), clearly distinguishing it from sibling tools like search_icons which search for icons.
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 implies usage (fetch details by name) and offers guidance on the weight parameter to focus on a variant. However, it does not explicitly state when to use this tool versus alternatives like search_icons, nor does it provide conditions for use or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Aurum component in the current manifest, with one-line descriptions and family grouping. Optionally filter to a specific platform (android, ios, or all). Use this as a starting point for navigation; follow up with get_component for full details.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Restrict results to a single platform. Omit or pass 'all' for everything. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It states 'List', implying a read-only operation with no side effects. It also describes the output format ('one-line descriptions and family grouping'), but does not explicitly mention idempotency or permissions. For a listing tool, this is adequate but not exhaustive.
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?
Two sentences, no redundant information. The first sentence states purpose and scope; the second gives usage guidance. Every sentence is valuable and 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?
The tool is simple with 1 optional parameter and no output schema. The description mentions the output format ('one-line descriptions and family grouping') and positions it as a starting point. It does not cover pagination or performance, but for a listing tool of known components, this is nearly complete.
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 100%, so the schema fully documents the platform parameter. The description reiterates the filtering option but does not add new semantic detail beyond what the schema provides. 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 clearly states the verb 'List', the resource 'every Aurum component', and the scope 'in the current manifest'. It also specifies the output format: 'one-line descriptions and family grouping'. This distinguishes it from siblings like get_component (full details) and search (different use case).
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?
Explicitly says 'Use this as a starting point for navigation; follow up with get_component for full details.' This provides clear context on when to use this tool and suggests an alternative sibling for more detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Aurum design tokens by category: color (semantic + visual palette), spacing, radius, borderWidth, iconSize, elevation, typography. Omit category to get a summary of all categories with counts. Pass a category for the full table.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Token category to expand. Omit for a summary across all categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses key behaviors: the tool returns a summary with counts when category is omitted, and a full table when a category is provided. This adds behavioral context beyond the schema, though no mention of pagination, rate limits, or performance implications.
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?
Two sentences, front-loaded with the core purpose, and no extraneous information. Every word earns its place.
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?
Given the tool's simplicity (1 optional enum parameter, no output schema, no annotations), the description covers the essential behavioral aspects. It explains both use cases and the structure of the response implicitly. Could be improved by briefly describing the output format, but the context signals indicate no output schema, so the burden is on the description.
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 100% with an enum and description. The description adds value by explaining the semantic difference between omitting the parameter (summary) and providing it (detailed table), which is not present in the schema's description.
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?
Description clearly states the tool lists Aurum design tokens by category, enumerating the categories and distinguishing between summary (omit category) and detailed listing (pass category). This verb+resource+scope is specific and distinct from siblings.
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?
Explicitly tells when to omit category for a summary and when to pass a category for full table, providing clear action guidance. No mention of alternatives, but the tool is self-contained and the instructions are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reverse-lookup: given a Figma node ID (5126:2507 or 5126-2507) or a full Figma URL, return the matching Aurum components, Code Connect mappings, or icons. Designed for the designer workflow: 'I'm looking at this Figma node, what code is it?'.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeIdOrUrl | Yes | Figma node ID (`123:456`, `123-456`) or any Figma URL containing one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions input formats and output types (Aurum components, Code Connect mappings, icons) but lacks details on result cardinality, error handling, pagination, or side effects. Incomplete behavioral disclosure.
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?
Two efficient sentences, front-loaded with key term 'Reverse-lookup', includes example IDs. No unnecessary words.
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?
No output schema; description vaguely says 'return matching...' without specifying format (list vs. single) or handling of missing nodes. Lacks completeness for a simple lookup 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 100% with clear parameter description. Tool description adds example formats but does not significantly enhance beyond schema. Baseline 3 applies.
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 clearly states the tool's purpose: reverse-lookup from Figma node ID or URL to code artifacts. It specifies input formats and output types, distinguishing it from siblings like search or get_component.
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 implies usage for designer workflow ('I'm looking at this Figma node, what code is it?') but does not explicitly state when not to use it or mention alternative tools (e.g., search) for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free-text search across all Aurum content (components, tokens, icons, changelog). Returns the top hits with the next-tool to call for details. Use this when you don't know which specific tool to start with.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text query. Supports lunr's syntax (boosts, fuzzy with `~`, prefix with `*`). | |
| limit | No | Maximum number of results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover all behavioral aspects. It mentions returning top hits and a next-tool, but lacks details on result ordering, empty results behavior, or read-only nature.
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?
Extremely concise: two sentences conveying purpose, scope, and usage context. Front-loaded with the core action, no unnecessary words.
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?
Given the simplicity (2 params, no output schema) and context of sibling tools, the description covers the essential use case. Minor missing details like result ordering are acceptable.
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 covers both parameters (query and limit) with detailed descriptions including lunr syntax. Description adds no extra meaning beyond the schema, so baseline 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 clearly states it performs free-text search across all Aurum content types and returns top hits with a suggestion for a follow-up tool, distinguishing it from specific component or icon lookups.
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?
Explicitly states when to use: 'Use this when you don't know which specific tool to start with,' guiding the agent to this tool as a starting point before more targeted tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Aurum's icon catalog by name fragment or category. Returns matching icons with their drawable resource names, paired line/fill Figma node IDs, and deeplinks. Use this when a designer or engineer is looking for the right icon to use.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Substring to match against icon name or category (case-insensitive). | |
| category | No | Optional category filter (Navigation, Action, Content, etc.). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It reveals that the tool returns matching icons with specific fields, which is helpful. However, it omits details like result limits, pagination, or ordering, which are relevant for a search tool.
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 two sentences that efficiently convey purpose, output, and usage context. No unnecessary words, and the key 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?
Given the tool's simplicity (2 params, no output schema, no nested objects) and the presence of sibling tools, the description adequately covers purpose and output. It lacks details on result format (e.g., list vs single, sorting) but is generally complete for typical use.
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 100%, with both parameters fully described in the schema (query: case-insensitive substring; category: optional with examples). The description adds little beyond the schema, merely summarizing the search criteria. Given high coverage, a 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 clearly states the tool searches Aurum's icon catalog by name fragment or category, and specifies the output includes drawable resource names, Figma node IDs, and deeplinks. It differentiates from siblings like get_icon (singular) and search (generic) by providing a specific use case.
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 says to use this tool when a designer or engineer is looking for the right icon, which provides clear context. However, it does not explicitly state when not to use it or mention alternative tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_aurum_versionget_changelogget_componentget_iconlist_componentslist_tokenslookup_figma_nodesearchsearch_iconsEach tool targets a distinct resource or action: version, changelog, component details, icon details, components listing, tokens listing, Figma lookup, general search, and icon search. No overlap in purposes.
All tools use consistent snake_case with clear verb-noun patterns (get_, list_, search, lookup_). The naming logically distinguishes operations like retrieving single items (get_component) vs listing all (list_components).
With 9 tools, the server is well-scoped for a design system reference library. Each tool covers a necessary aspect (components, icons, tokens, changelog, version, Figma integration, and search) without excess.
The tool set covers the core read operations for components, icons, tokens, changelog, and Figma lookup. A minor gap is the lack of a dedicated 'list all icons' tool (only search_icons is available, requiring a query), but the overall surface is thorough.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Search the Cerebrium docs: deployment, cerebrium.toml, hardware, endpoints. Also sends feedback.
Serves your design system and coding standards to coding agents, so they stop guessing.
Retrieve information from the Medusa documentation to assist you with your Medusa development.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/atri-jar/aurum-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
