Enables access to Angular-specific component documentation within the IGDS Storybook, allowing retrieval of component details, source code, stories, and examples.
Enables access to React-specific component documentation within the IGDS Storybook, allowing retrieval of component details, source code, stories, and examples.
Provides tools for querying IGDS component documentation from Storybook, including component lists, argTypes, source code, CSS, stories, and rendered HTML examples for Angular, React, and Core-Web frameworks.
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., "@IGDS Storybook MCP Server Show me the React button component documentation"
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.
An MCP server that gives coding agents the component contract for the Israeli Government Design System (IGDS) — props, legal values, defaults, usage snippets and design rules — and nothing else.
No rendered HTML. No CSS. No Storybook chrome. A get-component call costs about 3–6 KB, where the previous version returned up to 153 KB for a single component.
Why not the official Storybook MCP? It cannot serve IGDS consumers today: IGDS runs Storybook 10.3.5 / Angular, while the official MCP requires 10.5+, is React-only in preview, and attaches to a local dev server. See docs/EVALUATION.md for the full assessment and the conditions under which we should switch to it.
get-component("Button")# Button `<igds-button>`
The component allows the user to perform actions with one click
**Frameworks:** angular, react, core-web · **Category:** Buttons
**Import:** `import '@igds/core-web';`
## Props (14)
| prop | type | default | required | description |
|---|---|---|---|---|
| disabled | boolean | false | | Disables interaction. |
| loading | boolean | false | | Shows loading state and disables interaction while active. |
| size | 'small' \| 'medium' \| 'large' | medium | | Button size. Defaults to 'medium'. |
| type | 'button' \| 'submit' \| 'reset' | button | | Native button type. Defaults to 'button'. |
| variant | 'primary' \| 'secondary' \| 'alternative' \| 'link' \| 'link-inline' | primary | | Visual style of the button. Defaults to 'primary'. |
...
## Events
| event | description |
|---|---|
| igds-click | payload: CustomEvent<{ value: { nativeEvent: PointerEvent } }> from ig |
...
## Usage — Default (core-web)
```html
<igds-button class="button" variant="primary" size="medium">
כפתור ראשי
</igds-button>
The legal values, descriptions and events are real — from IGDS's own hand-written per-framework API tables where they exist, falling back to the component's manifest and finally to values mined from the design system's own stories — so an agent cannot invent a `variant` that does not exist.
Related MCP server: storybook-renderer
Build once locally — this doesn't change per client, every one of them below just needs to point node at the resulting file:
git clone https://github.com/michab23/igds-storybook-MCP.git
cd igds-storybook-mcp
npm install
npm run build # produces dist/index.jsThen use the generic config shape most MCP clients read directly:
{
"mcpServers": {
"igds": {
"command": "node",
"args": ["<path-to-project>/dist/index.js"]
}
}
}A few tools use a different entry point or config shape instead of the generic block above:
Claude Code
claude mcp add igds --scope project -- node <path-to-project>/dist/index.js--scope project writes the entry to .mcp.json in the current repo so teammates get it via version control; drop the flag for a personal-only entry, or use --scope user to make it available across every project.
Gemini CLI — add the same mcpServers block above to .gemini/settings.json (project) or ~/.gemini/settings.json (user).
OpenCode — different shape: mcp instead of mcpServers, and command is an array. Add to opencode.json in the workspace root:
{
"mcp": {
"igds": {
"type": "local",
"command": ["node", "<path-to-project>/dist/index.js"],
"enabled": true
}
}
}Kiro — same mcpServers shape as the generic block, plus two Kiro-specific fields. Add to .kiro/settings/mcp.json (workspace) or ~/.kiro/settings/mcp.json (user):
{
"mcpServers": {
"igds": {
"command": "node",
"args": ["<path-to-project>/dist/index.js"],
"disabled": false,
"autoApprove": []
}
}
}autoApprove lists tool names Kiro should run without a confirmation prompt — leave it empty to confirm every call.
Use an absolute path for <path-to-project> in all of the above — a relative one resolves against whatever working directory each tool happens to launch from.
npm run http # http://localhost:3000/mcp (PORT to override)Each session gets its own server instance, so concurrent clients are safe. GET /health reports version and live session count.
/mcp implements the MCP Streamable HTTP protocol, not a webpage — opening it directly in a browser shows {"error":"Invalid or missing session ID"}, which is expected since every request needs an mcp-session-id header obtained via an initialize POST. To exercise it:
MCP Inspector: npx @modelcontextprotocol/inspector --transport streamable-http http://localhost:3000/mcp
A real MCP client — point its config at the URL, e.g. { "mcpServers": { "igds": { "url": "http://localhost:3000/mcp" } } }
npm run verify:http — spins up its own instance and drives two full MCP sessions through it automatically
search-components to find the right component.
get-component before writing any markup — use only props and values it lists.
get-component-examples if you need more than the canonical snippet.
get-design-guidance when accessibility or RTL matters.
Five tools, ~3 KB of tool definitions total.
Tool | Parameters | Returns |
|
| Matching component names + why they matched. References only — never bodies. |
|
| Index of components: name, tag, category, summary. |
|
| The API contract: props with types, legal values, defaults, plus one usage snippet. |
|
| Usage code snippets from the design system's stories. Code only. |
|
| When to use, when not to, accessibility requirements, RTL notes. |
Freshness metadata (scrapedAt, builtAt, known gaps) is exposed as the MCP resource igds://meta, so it costs no tool-list context.
The component data behind these tools ships pre-built in the npm package (data/igds-agent-docs.json) — there's nothing for a consumer to fetch or generate. It's produced once, offline, by the maintainers from a scrape of IGDS's own Storybook and Zeroheight sites, then distilled down to just the API contract:
igds-storybook.globalbit.dev ──► data/igds-agent-docs.json ──► the 5 tools above
+ zeroheight docs (~500 KB, committed & published)Rendered HTML is captured in that process only to mine the real attribute vocabulary and distil usage snippets — it is never served to an agent. npm run verify enforces that.
Import statement shapes (import { Button } from '@igds/react' vs. import '@igds/core-web' vs. Angular's per-component deep imports) are configured in data/packages.json from the IGDS monorepo's publish targets, and confirmed against real IGDS usage samples rather than assumed.
Path | Purpose |
| The agent-facing model and the store tools read from. |
| The five MCP tools. |
| Markdown rendering and context budgets. |
| stdio and HTTP entry points. |
| Raw scrape → agent docs transform (maintainer use only). |
| Mines attribute vocabulary and usage snippets from captured markup. |
| Strips site chrome from Zeroheight text, extracts guidance. |
| Scraping pipeline (maintainer use only). |
| Official-MCP and Graphify assessment. |
npm run verifyChecks that the served artifact contains no renderedHtml, cssStyles, <storybook-root, _ngcontent or site navigation; that components have props, usage and legal values; that the tool surface stays small; and that every get-component response stays within budget.
Current measurements:
Metric | Value |
Components | 50 |
With props / usage | 49 / 50 |
With documented legal values | 40 |
With documented events | 38 |
| 2,720 / 4,818 / 5,678 chars |
Worst case vs. previous version | 5,678 vs. 153,245 chars (27× smaller) |
Child elements attached to parents | 12 |
Tool definitions | 5 tools, 3,125 chars |
Numbers are from a full live scrape of all three frameworks, not a partial or synthetic run.
Command | Purpose |
| Content and context-budget gates (see above). |
| Starts the HTTP server and drives two concurrent sessions. |
| MCP Inspector over stdio. |
Refreshing data/igds-agent-docs.json from a new IGDS release is a maintainer task, not part of normal setup — see src/scrape-all.ts and src/build-agent-docs.ts if you're doing that.
ISC
Compare a component across Angular, React, and Core-Web frameworks
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | Component name to compare |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Compare' without describing what the comparison entails, the output format, or whether it has side effects. It does not contradict annotations because none exist.
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?
One sentence, front-loaded with the verb, no redundant words. 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?
For a single-param tool without output schema, it covers the main action but omits what 'compare' returns (e.g., side-by-side diff, compatibility matrix) and any error conditions. It's minimally adequate but not 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 schema already provides 100% coverage with 'Component name to compare'. The tool description adds the context that the name is used across three specific frameworks, but no additional syntax or format details, so baseline 3.
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 the specific verb 'Compare' with a clear resource 'component' and a scope 'across Angular, React, and Core-Web frameworks', distinguishing it from sibling tools like 'get-component' which likely retrieve a single 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?
No explicit guidance on when to use this tool versus alternatives. It doesn't mention that one should use this instead of get-component for cross-framework comparisons, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed documentation for a specific IGDS component
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes | Framework | |
| componentName | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the transparency burden. It states the action ('get') implying a read operation, but does not disclose what the returned documentation contains, whether any special permissions are needed, or any side effects. The description is too vague to fully inform the agent about the tool's behavior.
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 a single, concise sentence that front-loads the core purpose. Every word earns its place, and there is no filler or 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?
Given the extensive sibling list and lack of output schema/annotations, the description is incomplete. It does not clarify what constitutes 'detailed documentation,' nor how this tool differs from zeroheight-get-component or get-component-source. The agent lacks sufficient context to confidently select and invoke this 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 description coverage is 100%, so the schema already documents both parameters. The description does not add any additional meaning beyond the schema, so the baseline score 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 retrieves detailed documentation for a specific IGDS component, using a specific verb and resource. However, it does not differentiate from sibling tools such as zeroheight-get-component or get-component-source, which may also return component information.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions or scenarios where a sibling tool would be more appropriate, leaving the agent to infer the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get CSS styles for a component. Requires cached data.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes | Framework | |
| componentName | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose one key behavioral trait: the tool relies on cached data. However, it does not describe what happens if the cache is missing, whether the operation is read-only, or any side effects. The single precondition adds value but leaves significant behavioral aspects unspecified.
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 a single, efficient sentence: 'Get CSS styles for a component. Requires cached data.' It front-loads the core purpose and adds a necessary constraint. Every word earns its place, with no redundancy or filler.
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?
This is a simple tool with 2 parameters and no output schema. The description conveys the core purpose and a key prerequisite, which is adequate for basic invocation. However, it lacks details about what 'cached data' entails, how the output is structured, and potential failure modes (e.g., missing cache). Given the absence of an output schema and annotations, a more complete description would be beneficial.
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% (both parameters have descriptions), but the descriptions are mere labels: 'Framework' for the enum and 'Component name' for the string. The tool description adds no semantic meaning beyond these labels—it does not explain how the framework enum affects the CSS returned or what specific component names are valid. Since coverage is high, the baseline of 3 applies, but no additional value is provided.
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 function: 'Get CSS styles for a component.' This uses a specific verb ('Get'), a distinct resource ('CSS styles'), and a target ('component'), which differentiates it from sibling tools like 'get-component' (general info) and 'get-component-source' (source code).
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 provides a usage precondition: 'Requires cached data.' This implies the tool should only be used when cached data is available, but it does not explicitly state when to prefer this tool over alternatives like 'get-component-source' or 'get-story'. There is no mention of when not to use it, so the guidance is minimal and largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get source code structure for a component (properties, CSS, defaults). Requires cached data.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes | Framework | |
| componentName | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions the dependency on cached data and the scope of the returned structure (properties, CSS, defaults), but does not describe error behavior or confirm safety/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?
The description is a single, front-loaded sentence that conveys the core purpose and a key prerequisite without redundancy. 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 and complete parameter schema, the description covers the main purpose and a key constraint. However, it lacks return format details, error-handling behavior, and does not position itself among the sibling tools. Without annotations or an output schema, these gaps make it only minimally 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%, with both parameters already documented. The description does not add additional parameter semantics, so the baseline score of 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 it gets source code structure for a component, specifying contents as properties, CSS, and defaults. This distinguishes it from siblings like get-component-css and 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 provides a key usage prerequisite ('Requires cached data') that gives context, but it does not explicitly compare this tool with alternatives or state when not to use it. This implies usage rather than offering clear when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all story variants for a component
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes | Framework | |
| componentName | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses only that it returns all story variants. It does not mention return structure, error behavior, pagination, or prerequisites, leaving the agent without important 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?
The description is a single, front-loaded sentence with no redundant information. It is concise and to the point.
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 simple read tool, the description is adequate but lacks details on return format and differentiation from sibling tools like get-story-examples. Given the absence of annotations and output schema, more context would be helpful, but the tool's simplicity keeps it within acceptable bounds.
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 documents both parameters with 100% coverage, including an enum for framework. The description adds no additional parameter context, but the schema suffices.
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 retrieves all story variants for a component, using a specific verb ('Get') and resource ('story variants'). The phrase 'all' distinguishes it from tools that retrieve a single story or 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?
Provides no guidance on when to use this tool versus alternatives like get-story-examples or get-component. The description simply states what it does without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics about loaded storybook data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'get statistics' without specifying what statistics are returned, whether the operation is purely read-only, or whether it depends on a prior load action. This leaves significant ambiguity for an agent invoking the 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 a single, short sentence with no extraneous words. It is front-loaded and immediately conveys the tool's purpose, making it highly concise and well-structured.
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 low complexity and no output schema, the description is too vague to be considered complete. An agent cannot infer what 'statistics' will be returned (e.g., counts of components/stories, metadata about the loaded data) or how to interpret the result. More specifics would greatly improve completeness.
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 zero parameters, so the baseline is 4. The description adds minimal but helpful context by clarifying that the statistics relate to 'loaded storybook data', which is not fully expressed in the empty schema. No parameter documentation is needed.
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 verb 'Get' and the resource 'statistics about loaded storybook data' clearly describe a read-only tool for retrieving aggregate information. It is distinct from sibling tools like get-component or get-story, which focus on specific items rather than overall statistics, though it does not explicitly name those alternatives.
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?
No usage context is provided. There is no mention of when to use this tool (e.g., only after load-storybook) or how it differs from alternatives like searching or listing components. The word 'loaded' implies a prerequisite, but this is not stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific story entry by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| storyId | Yes | Story ID | |
| framework | Yes | Framework |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for disclosing behavioral traits. It implies a read-only operation but does not explicitly state safety, error behavior, permissions, or what happens if the ID does not exist. The description adds minimal transparency beyond the verb 'Get'.
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 a single, concise sentence with no redundant words. It is front-loaded and immediately communicates the tool's action and target.
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 simple 2-parameter get tool with full schema coverage and no output schema, the description is mostly adequate. It could mention the return value or the framework parameter explicitly, but the complexity is low and the core purpose is conveyed.
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%, with both 'storyId' and 'framework' having descriptions. The tool description adds no additional meaning over the schema, so the baseline score 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 retrieves a specific story entry by its ID. It uses a specific verb ('Get') and resource ('story entry'), and the ID-based scope differentiates it from sibling tools like get-component-stories or get-story-examples.
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 provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it, prerequisites, or comparisons with related sibling tools such as get-story-examples or get-component-stories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get rendered HTML examples from Storybook stories for a component
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes | Framework to search | |
| storyName | No | Specific story name (optional, returns all if omitted) | |
| componentName | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. The verb 'Get' implies a read-only operation, but the description does not disclose any error behavior, output format details, or limitations (e.g., what happens when no stories exist). It adds minimal behavioral context beyond the basic action.
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 a single, front-loaded sentence that efficiently states the tool's purpose without unnecessary words. It follows a clear structure: action, object, and target component.
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 three parameters and no output schema, the description provides a basic understanding of purpose but does not elaborate on return enrichments, edge cases, or prerequisites. Given the presence of closely related sibling tools, this minimal description may be insufficient for an agent to confidently select the correct tool in all contexts.
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 fully describes all three parameters with 100% coverage, including 'storyName' optionality and 'framework' enum. The description adds only the context of 'rendered HTML examples', which aligns with componentName but does not enrich the understanding of any individual parameter 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 'Get' and clearly identifies the resource as 'rendered HTML examples from Storybook stories' for a component. It distinguishes from sibling tools like get-story (likely metadata) and get-component-stories (story list) by focusing on the rendered HTML output.
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 the tool is for retrieving HTML examples, but it does not explicitly state when to use it over alternatives like get-story or get-component-stories. There is no mention of exclusions or conditions, leaving the usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available IGDS components for a specific framework
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes | Framework to list components for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It states the action but omits details like whether results are paginated, read-only nature, authentication requirements, or output format. Since it's a list operation, it likely has no side effects, but this is not stated.
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 a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose.
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 simple one-parameter schema and no output schema, the description covers the basic purpose but lacks behavioral context such as pagination or return format. It is adequate but not thorough for an agent to understand all nuances.
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 schema fully describes the parameter 'framework' with an enum and description. The description adds no additional semantic detail beyond the schema, so it earns the baseline score of 3.
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 'List' and resource 'IGDS components' with a clear scope 'for a specific framework'. This clearly distinguishes it from sibling tools like get-component (single component) and search-components (search).
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 when to use it (to list components for a framework) but does not explicitly mention alternatives or when not to use it. There is no guidance comparing it to search-components or get-component.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load IGDS Storybook data for a specific framework or all frameworks
| Name | Required | Description | Default |
|---|---|---|---|
| framework | No | Framework to load (omit for all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only says 'Load' without explaining side effects, return data, or whether the operation is read-only. The description adds minimal behavioral context beyond the verb itself.
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 a single concise sentence, front-loaded with the verb and resource. Every word serves a purpose, and there is no redundant or filler content.
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 one optional enum parameter, and the description covers the invocation logic. However, with no output schema or annotations, it does not explain what 'IGDS Storybook data' entails or what the agent should expect as a result, leaving some ambiguity.
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 schema already fully covers the 'framework' parameter with a description and enum values, achieving 100% coverage. The tool description echoes this by saying 'specific framework or all frameworks' but adds no new meaning, so the 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 the action (load), the resource (IGDS Storybook data), and the scope (specific framework or all frameworks). However, it does not explicitly distinguish this from sibling tools like get-story or zeroheight-get-storybook-ref, so it stops short of full differentiation.
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 by defining the framework selection and the 'omit for all' behavior, but it does not provide explicit guidance on when to use this tool versus alternatives. No when-not-to-use or comparison with sibling tools is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for IGDS components across all frameworks
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the search function and scope, but does not describe return format, pagination, auth needs, or whether it is read-only. Minimal behavioral context is provided.
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 a single sentence of seven words, completely free of fluff. It earns its place and is appropriately concise.
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 but lacks annotations and output schema. The description does not explain what the search results look like, how this relates to sibling search tools (e.g., zeroheight-search), or any limitations. It feels incomplete for an agent trying to decide between tools.
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 schema description coverage is 100% for the single parameter 'query', which is described as 'Search query'. The description adds no additional parameter-level meaning, so 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 uses a specific verb ('Search') and identifies the resource ('IGDS components') with a scope qualifier ('across all frameworks'). It is not a tautology and the purpose is clear, though it does not explicitly differentiate from sibling tools like zeroheight-search.
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 provides no guidance on when to use this tool versus alternatives. It states the function but does not mention when to choose this over list-components or zeroheight-search, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full component documentation from Zeroheight
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. 'Get' implies a read-only operation, but the description does not disclose what 'full documentation' includes, any required permissions, or possible limitations. It lacks details on return structure or behavior beyond the basic 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?
The description is a single sentence that is front-loaded with the main action and resource. It contains no redundant words and is appropriately concise for a simple retrieval tool.
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 (one parameter, no output schema), but the description does not fully explain what the returned 'full component documentation' contains, nor how it relates to the many sibling tools. It is adequate but leaves ambiguity about the exact output and usage context.
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 schema has one parameter with a description ('Component name') and 100% coverage. The tool description adds no further meaning or context for the parameter, so the score is the baseline 3 as the schema already handles the semantics.
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 'Get' and clearly identifies the resource as 'full component documentation' from 'Zeroheight'. This distinguishes it from sibling tools like 'get-component-source' or 'get-component-css' by emphasizing that it returns comprehensive documentation.
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 phrase 'full component documentation' implies the tool should be used when complete documentation is needed, but there is no explicit guidance on when not to use it or which alternative to choose. Nothing in the description explains how it differs from similar siblings like 'get-component'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific section (design/code/usage/accessibility) for a component
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | Section to retrieve | |
| componentName | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that it retrieves a section, adding no details about side effects, permissions, error behavior, or response format. This is minimal disclosure for a tool without annotation support.
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 a single, front-loaded sentence with no extraneous words. It efficiently conveys the tool's purpose and the relevant section types.
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 low complexity (two required params, one with an enum) and the absence of an output schema, the description is reasonably complete for understanding the tool's basic function. However, it omits return value details and does not mention any prerequisites or exclusions, leaving some gaps for an agent.
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 baseline is 3. The description mentions the sections in parentheses, but these are already enumerated in the schema. It does not add meaning beyond what the property descriptions already provide.
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 'Get a specific section (design/code/usage/accessibility) for a component' clearly states the action (get), the resource (a section for a component), and the specific types of sections. This distinguishes it from sibling tools like get-component or get-component-source, which likely retrieve whole components or source code respectively.
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 phrase 'specific section' implies this tool is for retrieving one section rather than the whole component, giving clear context on when to use it. However, it does not explicitly mention alternatives or when not to use it, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Storybook cross-references for a Zeroheight component
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | Zeroheight component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It only states that it retrieves cross-references, but does not indicate read-only nature, potential side effects, authentication needs, or response characteristics.
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 a single, front-loaded sentence with no unnecessary words or repetition. It is concise and immediately readable.
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 low complexity (one parameter, no output schema, no annotations), the description is adequate for basic understanding. However, it could slightly benefit from hinting at the return format or the nature of 'cross-references' to fully compensate for the missing output schema.
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 a description for componentName ('Zeroheight component name'), achieving 100% coverage. The tool description adds no additional parameter meaning, so it does not exceed the schema baseline.
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 specific action ('Get') and resource ('Storybook cross-references') for a Zeroheight component. This distinguishes it from siblings like get-component or load-storybook, making the tool's purpose unambiguous.
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?
No guidance is provided on when to use this tool versus alternatives. With a large sibling set, the description does not mention exclusions or preferred scenarios, leaving the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all component categories from Zeroheight design system documentation
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. While 'List' implies a read-only operation, the description does not explicitly state safety, whether authentication is required, pagination behavior, or the return format. It adds minimal context beyond the name.
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 a single, concise sentence that is front-loaded with the action and resource. It contains no filler or redundant phrases, earning a perfect score for conciseness.
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 simple, parameterless list operation, the description is mostly complete. It identifies the source (Zeroheight documentation) and the object (component categories). However, it does not clarify what a 'category' entails or what the response structure looks like, though with no output schema this is less critical.
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 zero parameters, making parameter semantics trivial. With a schema coverage of 100% (empty schema) and a baseline of 4 for 0-param tools, the description correctly avoids inventing parameter details, and no additional semantic explanation is needed.
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 'List all component categories from Zeroheight design system documentation' clearly states the action (list), the resource (component categories), the scope (all), and the source (Zeroheight design system documentation). This distinguishes it from sibling tools like list-components, which likely list components instead of categories.
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?
No guidance is provided on when to use this tool versus alternatives. Unlike the high-calibration example that explicitly names an alternative for filtered searches, this description gives no contextual pointers, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List components from Zeroheight (optionally filtered by category)
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the optional filter and does not disclose return format, pagination, auth needs, or whether the filter is exact-match. For a list tool this is a minimal but not entirely absent 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?
The description is a single, front-loaded sentence with no filler. 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?
For a simple tool with one optional parameter and no output schema, the description is adequate but sparse. It doesn't specify what the returned component list looks like or whether category filtering behaves a certain way. It meets the minimum viable bar but leaves some gaps.
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 schema already describes the only parameter (category) as 'Filter by category name', and the description adds that it is optional. Since schema description coverage is 100%, the description does not need to compensate, but it adds little 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 clearly states the tool's function: 'List components from Zeroheight' with an optional category filter. This distinguishes it from sibling tools like zeroheight-list-categories (categories) and zeroheight-get-component (single 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 the tool is used when you need a list of components, with an optional filter by category. However, it provides no explicit guidance on when to prefer this over alternatives like search-components or get-component, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across all Zeroheight content
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the action and scope, lacking any detail on result format, read-only nature, pagination, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it is under-specified in terms of valuable detail, slightly reducing the score from perfect.
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 absence of an output schema and annotations, the description should explain what results are returned and any behavioral nuances. It only states the search across all content, leaving significant gaps for an agent to understand the tool's full behavior.
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 schema already provides 100% coverage with the 'query' parameter described as 'Search query'. The description adds no additional semantics beyond the schema, matching the baseline for high schema coverage.
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 performs a search across all Zeroheight content, distinguishing it from sibling search-components which is component-specific. However, it does not specify what types of content are included, making it slightly less precise than ideal.
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 a general search use case but offers no explicit guidance on when to prefer this over alternatives like search-components or zeroheight-list-categories. No exclusions or prerequisites are mentioned.
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.
v1.0.0compare-componentget-componentget-component-cssget-component-sourceget-component-storiesget-statsget-storyget-story-exampleslist-componentsload-storybooksearch-componentszeroheight-get-componentzeroheight-get-sectionzeroheight-get-storybook-refzeroheight-list-categorieszeroheight-list-componentszeroheight-searchSeveral tools overlap in purpose: list-components vs search-components vs zeroheight-list-components all deal with component discovery, and get-component vs zeroheight-get-component both retrieve component docs. Story-related tools (get-story, get-component-stories, get-story-examples) have distinct but somewhat ambiguous boundaries. Descriptions help, but an agent may struggle to pick the right tool without careful reading.
Naming is inconsistent: most tools use kebab-case with verb-noun (get-stats, list-components), but zeroheight tools use a 'zeroheight-' prefix with camelCase (zeroheight-search, zeroheight-list-categories). There is no uniform verb convention (get, list, search, load, compare), and the mix of styles reduces predictability.
With 17 tools, the server is on the heavy end but each tool addresses a specific need (storybook data, Zeroheight docs, comparisons, CSS, examples). The scope is broad enough to justify the count, though it could be streamlined by merging some overlapping component/story tools.
The domain is well-covered: data loading, listing, searching, retrieving details, stories, CSS, examples, and Zeroheight integration. The only minor gap is lack of explicit framework management (e.g., unloading data) but this is a read-only documentation server, so core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The official MCP Server from Mia-Platform to interact with Mia-Platform Console
MCP server for querying Forkast documentation
MCP server for innovationlab documentation, generated by doc2mcp.
MCP server for the HubSpot Integrations Center HubDB: search and retrieve integration data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/michab23/igds-storybook-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
