Muibook Guidelines MCP Server
Click on "Deploy 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., "@Muibook Guidelines MCP ServerShow me the button component guidelines"
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.
Muibook Guidelines MCP Server
An MCP (Model Context Protocol) server that provides design system guidelines and component documentation to Cursor Desktop.
Overview
This MCP server delivers comprehensive design system guidelines directly to Cursor, enabling it to provide accurate, consistent advice about UI components, patterns, and best practices from your design system.
Related MCP server: WordPress Design System MCP Server
Features
Component Guidelines: Detailed documentation for UI components (buttons, forms, navigation, etc.)
Visual References: Direct links to component anatomy diagrams and examples
Accessibility Standards: Built-in accessibility requirements and best practices
Design Tokens: Access to color, typography, spacing, and other design tokens
Usage Patterns: Real-world examples and usage guidelines
Installation
Prerequisites
Node.js (v16 or higher)
Cursor Desktop application
Setup
Clone this repository
git clone https://github.com/your-org/muibook-guidelines-mcp.git
cd muibook-guidelines-mcpInstall dependencies
npm installConfigure Cursor Desktop
Edit your Cursor Desktop config file:
macOS:
~/Library/Application Support/Cursor/mcp_config.jsonWindows:
%APPDATA%\Cursor\mcp_config.json
Add this server:
{
"mcpServers": {
"muibook-guidelines": {
"command": "node",
"args": ["/absolute/path/to/muibook-guidelines-mcp/server.js"]
}
}
}Replace /absolute/path/to/muibook-guidelines-mcp/ with the actual path where you cloned this repository.
Restart Cursor Desktop
Completely quit and reopen Cursor Desktop to load the MCP server.
Usage
Once installed, you can ask Cursor about design guidelines:
Examples:
"Show me the button component guidelines"
"What are the accessibility requirements for buttons?"
"What button variants are available?"
"How should I use primary vs secondary buttons?"
Available Prompts
serve_guidelines - Returns comprehensive design system guidelines including component anatomy, usage patterns, accessibility requirements, and visual references.
What's Included
Button Component Guidelines
Complete anatomy breakdown with visual diagrams
Usage guidelines and best practices
Five button variants (Primary, Secondary, Tertiary, Link, Icon)
Accessibility requirements
Component states and behaviors
Full documentation: https://guides.muibook.com/button
Troubleshooting
Red indicator in Cursor Desktop
The server isn't connecting. Try these steps:
Verify the path in your config file is correct and absolute
Check Node.js version: Run
node --version(needs v16+)Test the server manually:
cd /path/to/muibook-guidelines-mcp node server.jsCheck for errors in the console output
Restart Cursor completely (quit and reopen)
Guidelines not appearing
Confirm the server shows as connected in Cursor (not red)
Try asking explicitly: "Show me the serve_guidelines prompt"
Check Cursor's MCP logs for errors
Images not loading
Ensure you have internet connectivity (images are hosted externally)
Check that the URLs in the guidelines are accessible
Try fetching an image URL directly in your browser
Development
Running the server locally
node server.jsMaking changes
Edit
server.jsto modify guidelinesRestart Cursor Desktop to reload changes
Test your prompts
Adding new components
Edit the prompt content in server.js:
if (request.params.name === "serve_guidelines") {
return {
messages: [
{
role: "user",
content: {
type: "text",
text: `# Add your new component guidelines here`,
},
},
],
};
}Project Structure
muibook-guidelines-mcp/
├── server.js # MCP server implementation
├── package.json # Dependencies and metadata
└── README.md # This fileResources
Contributing
We welcome contributions! To add or improve guidelines:
Fork this repository
Create a feature branch (
git checkout -b feature/new-component)Add or update component guidelines in
server.jsTest with Cursor Desktop
Submit a pull request
License
[Your License Here]
Support
For issues or questions:
Open an issue on GitHub
Check the troubleshooting section above
Contact the design system team
NPM Package
Versioning
Follow semantic versioning:
major.minor.patchPatch: bug fixes, no API changes
Minor: new features, backward-compatible
Major: breaking changes, API changes
Keep
package.jsonandserver.jsonversions synchronized.
Bumping Versions
Patch:
npm version patchMinor:
npm version minorMajor:
npm version majorThis updates package.json version and creates a Git tag automatically.
Publishing to NPM
Option A – Direct publish (NPM will prompt for credentials if needed):
npm publish --access publicOption B – Pre-login (recommended for repeated releases):
npm login
npm publish --access public--access public ensures the package is publicly available.
Make sure package.json includes the MCP identifier:
"mcpName": "io.github.YOURUSERNAME/muibook-guidelines-mcp"⸻
Optional MCP Registry Update
Ensure server.json matches the current version:
"version": "1.0.0"Publish to MCP Registry:
mcp-publisher publish⸻
GitHub Release (Optional)
Tag the release:
git tag v1.0.0
git push origin v1.0.0Add release notes in GitHub for tracking changes.
⸻
Local Development & Testing
Install dependencies:
npm installRun locally:
npm startConnect via MCP client (Cursor, Cline, etc.) or mcp.json:
{
"servers": {
"muibook-guidelines-mcp": {
"command": "node",
"args": ["./node_modules/muibook-guidelines-mcp/server.js"]
}
}
}Release Checklist
• Test MCP server locally • Update package.json and server.json versions • Bump version (patch, minor, or major) • Commit and push changes • Publish to NPM (--access public) • Optionally publish to MCP Registry (mcp-publisher publish) • Optionally create GitHub release with notes
References
• NPM Publishing Docs • MCP Registry Docs • Semantic Versioning
Available Tools
1 toolserve_guidelinesB
Access guidelines for your design system as you build to ensure consistency.
| Name | Required | Description | Default |
|---|---|---|---|
| json | Yes | Access guidelines for your design system as you build to ensure consistency. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Access' implies a read operation but the description does not explicitly state that the tool is non-mutating, what it returns, or any behavioral characteristics. This is a significant gap for a tool with no annotation coverage.
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 filler, and the central purpose is front-loaded. It could pack in more behavioral or parameter detail without losing conciseness, but as written it is efficient.
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 tool with one required parameter, no annotations, and no output schema, the description should explain what to pass in 'json' and what the tool will return. It instead focuses on design workflow, leaving an agent without enough information to construct a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is nominally 100%, the parameter's description is just a repetition of the tool description ('Access guidelines for your design system...') and gives no actual meaning about what the required 'json' string should contain, what format it should be in, or how it affects the operation. The description adds no clarifying value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Access', and identifies the resource, 'guidelines for your design system', along with the purpose, 'ensure consistency'. It clearly states what the tool does, though with no sibling tools it does not need to differentiate from 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?
The phrase 'as you build' provides a clear usage context: the tool is meant to be consulted while building to maintain design consistency. With no sibling tools and no exclusions, this context is sufficient.
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.
1 tool update
v1.0.0- First observed
serve_guidelines
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion or overlap. The tool's purpose is clear and unique.
The single tool name follows a clean verb_noun pattern (serve_guidelines), which is consistent and easily readable.
With only one tool, the server feels minimal but not unreasonable for a narrowly scoped guideline-serving purpose. It sits at the thin end of acceptable.
The tool provides access to guidelines, but there are no options for searching, filtering, or retrieving specific sections. This may force agents to process a large blob of content, though it could suffice for very simple use cases.
Related MCP Connectors
Serves your design system and coding standards to coding agents, so they stop guessing.
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Accessible React components, tokens, usage guidance, and install commands for product interfaces.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides AI assistants with access to a production-ready design system including Tailwind CSS component patterns, style guides (colors, typography, spacing), and Web Components specifications for consistent UI development.5 npmMIT
- FlicenseNot gradedqualityFmaintenanceProvides AI assistants with access to WordPress Design System component information and design guidance.9-
- AlicenseNot gradedqualityCmaintenanceEnables Cursor and Claude Code to read design tokens and rules, and validate component code against a design system before generating UI.MIT
- AlicenseAqualityBmaintenanceProvides deterministic, read-only design knowledge for AI coding agents to help them choose visual directions, plan UI states, and compose design tokens, all without network access.612 npm4MIT