de en es ja ko ru zh

aurum-mcp

Name: aurum-mcp
Author: atri-jar

by atri-jar

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

aurum-mcp

Habla con el Sistema de Diseño Aurum desde tu cliente LLM. Componentes · tokens · iconos · IDs de nodos de Figma · registro de cambios — todo consultable desde Claude Code, Cursor, Copilot CLI, Gemini y Claude Desktop.

aurum-mcp es un servidor del Protocolo de Contexto de Modelo (MCP) que expone el catálogo del sistema de diseño Aurum a los LLM. Lee un manifiesto JSON empaquetado (sincronizado automáticamente desde changejarapp.github.io/aurum-android) y expone 9 herramientas que el LLM puede llamar para responder preguntas como:

"Muéstrame cómo usar AurumChip."
"¿Qué token de color tenemos para texto de retroalimentación negativa?"
"¿Cuál es el nodo de Figma para AurumTopAppBar?"
"Dame el icono para una flecha de retroceso."
"¿Qué cambió en la versión más reciente?"

Instalación (un solo pegado, para cada cliente)

Elige tu cliente a continuación, pega el fragmento en el archivo de configuración correspondiente, reinicia el cliente.

Claude Code (`.mcp.json` en la raíz de tu proyecto, o `~/.claude.json`)

{
  "mcpServers": {
    "aurum": {
      "command": "npx",
      "args": ["-y", "github:atri-jar/aurum-mcp#latest-stable"]
    }
  }
}

Cursor (`~/.cursor/mcp.json`)

{
  "mcpServers": {
    "aurum": {
      "command": "npx",
      "args": ["-y", "github:atri-jar/aurum-mcp#latest-stable"]
    }
  }
}

Copilot CLI (`~/.copilot/mcp.json`)

{
  "mcpServers": {
    "aurum": {
      "command": "npx",
      "args": ["-y", "github:atri-jar/aurum-mcp#latest-stable"]
    }
  }
}

Gemini CLI (`~/.gemini/settings.json` bajo `mcpServers`)

{
  "mcpServers": {
    "aurum": {
      "command": "npx",
      "args": ["-y", "github:atri-jar/aurum-mcp#latest-stable"]
    }
  }
}

Claude Desktop (`~/Library/Application Support/Claude/claude_desktop_config.json`)

La misma estructura: suelta el fragmento anterior en mcpServers. Reinicia la aplicación.

Eso es todo. Sin registro npm, sin ~/.npmrc, sin PAT, sin variables de entorno. Git público, npx público.

Related MCP server: GDS MCP

Versionado

El fragmento predeterminado usa #latest-stable — una etiqueta Git gestionada por CI que siempre apunta a la versión estable más reciente. Se comporta como la etiqueta de distribución @latest de npm: obtienes actualizaciones automáticas en cada fallo de caché de npx (~10 min a unas pocas horas, dependiendo de la caché de tu cliente).

Para reproducibilidad — scripts automatizados, configuraciones auditadas — fija una etiqueta explícita:

"args": ["-y", "github:atri-jar/aurum-mcp#v0.1.0"]

Cada versión de aurum-mcp incluye el manifiesto de la versión de la biblioteca Aurum correspondiente (@aurum-mcp:0.1.6 ⇄ aurum:0.1.6). Llama a get_aurum_version desde tu cliente LLM para ver exactamente con qué estás interactuando.

Herramientas

Herramienta	Propósito
`list_components`	Enumera todos los componentes de Aurum, agrupados por familia
`get_component`	Especificación completa del componente — KDoc, firma, parámetros, enlace profundo a Figma
`list_tokens`	Tablas de tokens: color (semántico + visual), espaciado, radio, ancho de borde, tamaño de icono, elevación, tipografía
`search_icons`	Encuentra iconos por fragmento de nombre o categoría
`get_icon`	Icono individual: drawables, ruta de Compose, enlaces profundos a Figma de línea+relleno
`get_changelog`	Registro de cambios por versión en formato markdown — por defecto a `[Unreleased]`
`lookup_figma_node`	Búsqueda inversa: ID/URL de nodo de Figma → componentes e iconos de Aurum coincidentes
`search`	Búsqueda de texto libre en todo el contenido con sugerencias de herramientas siguientes
`get_aurum_version`	Procedencia del manifiesto: versión, SHA, marca de tiempo de generación

Consulta docs/tools.md para ver los esquemas de entrada completos y ejemplos de respuestas.

¿Por qué `npx`-desde-Git y no npm?

Consideramos tres canales de distribución (npm público, GitHub Packages, npx-desde-Git) y elegimos el tercero porque para una herramienta interna del equipo que optimiza la simplicidad, propiedad total y cero nueva infraestructura:

Cero cuentas nuevas que gestionar. Sin organización npm, sin rotación de NPM_TOKEN, sin recuperación de 2FA, sin ansiedad por la permanencia de publicación de 72 horas. El repositorio ES el artefacto, de principio a fin.
Pruebas basadas en ramas gratis. ¿Quieres probar una rama de características? Solo cambia el fragmento a #feat/nombre-de-la-rama — listo. Con npm tendrías que publicar una etiqueta de pre-lanzamiento que vive en el registro para siempre.
La misma autenticación que los usuarios ya tienen. Este repositorio es público; los miembros del equipo tienen acceso a GitHub; nada nuevo que configurar.
Retraso de instalación marginal. El primer inicio es ~5–10 s de clonación + compilación frente a ~2–5 s para npm. Los inicios en caché son idénticos.

Compromisos que aceptamos: una UX de fijación de versiones menos pulida (etiquetas Git frente a rangos semver) y sin capacidad de descubrimiento en npm público. El razonamiento completo vive en docs/architecture.md.

Desarrollo local

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 test

El servidor lee data/manifest.json (confirmado). Para obtener el último manifiesto de la galería Aurum en vivo y actualizar la copia empaquetada:

make manifest-fetch

CI hace esto automáticamente (ver .github/workflows/sync-manifest.yml).

Arquitectura en un párrafo

El sistema de diseño Aurum vive en Changejarapp/aurum-android (privado) y envía una galería pública a changejarapp.github.io/aurum-android. Su script tooling/gallery/generate.py agrega componentes, tokens, iconos, mapeos de Code Connect y el registro de cambios desde un único conjunto de analizadores. Añadimos una bandera --emit-manifest que produce una proyección JSON estructurada de los mismos datos — el contrato es tooling/manifest/schema.json en aurum-android. Este servidor MCP es el lado de lectura del JSON: carga el manifiesto al arrancar, lo indexa y proporciona las 9 herramientas anteriores. Una única fuente de verdad, dos objetivos de renderizado (HTML para humanos, JSON para agentes). Cuando aurum-ios se lance, su manifiesto se conectará como una fuente hermana — el código MCP es independiente de la plataforma.

Diagrama completo del pipeline: docs/architecture.md.

Contribución

Las incidencias y PRs son bienvenidas. Consulta docs/contributing.md para el flujo de trabajo (sincronización de manifiesto, verificación de deriva, proceso de lanzamiento). Estilo de código: TypeScript estricto, valores predeterminados de Prettier; sin lógica de negocio en formateadores de markdown.

Licencia

MIT — ver LICENSE.

Available Tools

9 tools

get_aurum_versionA

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

get_changelogA

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.

ParametersJSON Schema

Name	Required	Description	Default
`version`	No	Version to fetch (`Unreleased`, a semver string, or `all`). Defaults to `Unreleased`.

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

get_componentA

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.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Composable name, e.g. `AurumChip`. Case-sensitive.
`platform`	No	Reserved for future cross-platform manifests.	all

TDQS

A4.7/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

get_iconA

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.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Icon name, e.g. `ChevronRight`. Case-insensitive.
`weight`	No	Which weight to highlight (`line`, `fill`, or `both`).	both

TDQS

A4/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_componentsA

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.

ParametersJSON Schema

Name	Required	Description	Default
`platform`	No	Restrict results to a single platform. Omit or pass 'all' for everything.	all

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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_tokensA

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.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Token category to expand. Omit for a summary across all categories.

TDQS

A4.6/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

lookup_figma_nodeB

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?'.

ParametersJSON Schema

Name	Required	Description	Default
`nodeIdOrUrl`	Yes	Figma node ID (`123:456`, `123-456`) or any Figma URL containing one.

TDQS

B3.4/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

searchA

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.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Free-text query. Supports lunr's syntax (boosts, fuzzy with `~`, prefix with `*`).
`limit`	No	Maximum number of results.

TDQS

A4.2/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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_iconsA

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.

ParametersJSON Schema

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.).

TDQS

A4/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv0.1.0May 3, 2026
- First observedget_aurum_version
- First observedget_changelog
- First observedget_component
- First observedget_icon
- First observedlist_components
- First observedlist_tokens
- First observedlookup_figma_node
- First observedsearch
- First observedsearch_icons

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-05-03 09:10 across 9 tools

Disambiguation5/5

Each 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.

Naming Consistency5/5

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).

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

SupernovaOAuth
io.supernova
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Design Tools Documentation Access Developer Tools
1
21st.dev AOAuth
dev.21st
Find UI components and themes, retrieve code, and generate with hosted 21st AI when enabled.
Design Tools Developer Tools AI & Machine Learning
2
Cerebrium Docs A
ai.cerebrium
Search the Cerebrium docs: deployment, cerebrium.toml, hardware, endpoints. Also sends feedback.
Documentation Access Developer Tools AI & Machine Learning
31
Tseha A
io.tseha
Serves your design system and coding standards to coding agents, so they stop guessing.
Developer Tools Documentation Access
942

Related MCP Servers

WordPress Design System MCPofficial
Design Tools Content Management Systems
Automattic
F
license
Not graded
quality
F
maintenance
Provides AI assistants with access to WordPress Design System component information and design guidance.
Updated 4 months ago (2026-06-08 12:21 UTC)
9
-
GDS MCP
Design Tools Developer Tools Documentation Access
supin-kim-ilevit-com
F
license
A
quality
D
maintenance
Exposes Levit design system (GDS) metadata to AI coding tools, enabling queries about color tokens and component usage via natural language.
Updated 4 months ago (2026-06-04 07:52 UTC)
11
-
dsbridge
Code Analysis Developer Tools
blumaa
A
license
Not graded
quality
B
maintenance
Enables asking a consuming app in plain language to audit its design system usage, returning tables that sort every value and component by origin—design system, app-named, or none—along with token and contrast checks.
Updated a month ago (2026-08-26 11:43 UTC)
3,519 npm
1
MIT
open-design-system-mcp-starter
Developer Tools Documentation Access Code Analysis
christophhdesign
A
license
Not graded
quality
B
maintenance
Provides a real API for coding agents to look up design system components, props, and tokens, preventing guessed answers.
Updated 19 days ago (2026-09-08 08:42 UTC)
7
MIT

aurum-mcp

Instalación (un solo pegado, para cada cliente)

Claude Code (.mcp.json en la raíz de tu proyecto, o ~/.claude.json)

Cursor (~/.cursor/mcp.json)

Copilot CLI (~/.copilot/mcp.json)

Gemini CLI (~/.gemini/settings.json bajo mcpServers)

Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json)

Versionado

Herramientas

¿Por qué npx-desde-Git y no npm?

Desarrollo local

Arquitectura en un párrafo

Contribución

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

WordPress Design System MCPofficial

Claude Code (`.mcp.json` en la raíz de tu proyecto, o `~/.claude.json`)

Cursor (`~/.cursor/mcp.json`)

Copilot CLI (`~/.copilot/mcp.json`)

Gemini CLI (`~/.gemini/settings.json` bajo `mcpServers`)

Claude Desktop (`~/Library/Application Support/Claude/claude_desktop_config.json`)

¿Por qué `npx`-desde-Git y no npm?