This MCP server provides AI assistants with comprehensive access to Modus Web Components documentation, design guidelines, and setup instructions directly within your IDE.
Component Documentation: Search for components by name or keyword, list all 43+ available components organized by categories, retrieve complete API documentation (attributes, events, and usage examples), and find components by specific attributes like disabled or color.
Design System Guidelines: Access design rules for specific categories (colors, icons, spacing, typography, breakpoints, border radius/stroke), search across all guidelines using keywords, and list available design rule categories.
Project Setup & Best Practices: Get setup guides for HTML, React, and testing environments, access theme implementation instructions, and view universal development rules and best practices.
Key Features: Pre-bundled documentation for secure, fast offline operation with no network dependencies after installation.
Provides access to complete Modus Web Components documentation, design system guidelines, and project setup guides for Trimble's component library
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., "@MCP Modus show me how to create a primary button with medium size"
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.
AI assistant for Modus Web Components - Get instant help with component documentation, design rules, and setup guides directly in your IDE.
This MCP server gives AI assistants (like Cursor, Claude, VS Code) access to complete Modus Web Components documentation. Ask questions like:
"How do I use a Modus button with primary color?"
"What are the Modus color guidelines?"
"Show me how to set up a React project with Modus components"
"Which components have a disabled attribute?"
Related MCP server: Component Library MCP Server
Choose one of the two options below:
For any IDE with MCP support:
{
"mcpServers": {
"modus-docs": {
"command": "npx",
"args": ["-y", "@julianoczkowski/mcp-modus"]
}
}
}Benefits: No installation required, always uses latest version, no permission issues, secure pre-bundled documentation.
Install globally:
npm install -g @julianoczkowski/mcp-modusNote: On some systems, you may need
sudo npm install -g @julianoczkowski/mcp-modus
Use this config:
{
"mcpServers": {
"modus-docs": {
"command": "mcp-modus"
}
}
}Benefits: Faster startup, works offline after installation, secure pre-bundled documentation.
Go to Settings → Features → MCP
Click "Add New MCP Server"
Use one of the JSON configs above
Add to ~/.continue/config.json using one of the JSON configs above.
Add to your config file using one of the JSON configs above:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
Complete API documentation for all Modus Web Components including attributes, events, methods, slots, and usage examples.
Component | Description |
| Expandable/collapsible content sections |
| Contextual feedback messages |
| Text input with suggestions |
| User profile images |
| Status indicators and labels |
| Navigation path indicators |
| Interactive action buttons |
| Grouped buttons with selection modes |
| Content container with elevation |
| Boolean input control |
| Compact interactive elements |
| Animated show/hide content |
| Date picker input |
| Visual content separator |
| Contextual menu with trigger |
| Drag-and-drop file upload |
| Resizable panel divider |
| Modus icon display |
| Form validation messages |
| Form field labels |
| Loading state indicators |
| Trimble/Viewpoint brand logos |
| Navigation menu container |
| Menu navigation items |
| Dialog overlays |
| Top navigation bar |
| Numeric input with controls |
| Page navigation controls |
| Structured layout container |
| Progress indicators |
| Single-select option control |
| Star rating input |
| Dropdown selection input |
| Sidebar navigation |
| Loading placeholder |
| Range value selector |
| Multi-step process indicator |
| Toggle on/off control |
| Data table display |
| Tabbed content navigation |
| Single-line text input |
| Multi-line text input |
| Theme selection control |
| Time picker input |
| Notification messages |
| Action button container |
| Contextual hover information |
| Text styling component |
| Slide-out utility panel |
Comprehensive design guidelines for building consistent Modus applications.
Guide | Coverage |
| Color tokens, semantic colors, theme palettes |
| Icon names, sizes, usage guidelines |
| Font families, sizes, weights, line heights |
| Spacing scale, margins, padding values |
| Responsive breakpoints, media queries |
| Border radius values, stroke widths |
Step-by-step instructions for integrating Modus Web Components.
Guide | Coverage |
| HTML project setup, CDN usage, basic integration |
| React project setup, npm installation, component usage |
| Theme implementation, light/dark modes, customization |
| Testing guidelines, accessibility testing, best practices |
| General development rules, coding standards |
Once configured, ask your AI assistant:
"Create a Modus button with warning color and medium size"
"What spacing values should I use in my Modus design?"
"How do I set up a new React project with Modus Web Components?"
"Show me all Modus form components"
"What are the available Modus color tokens?"The AI will use the MCP server to fetch the latest documentation and provide accurate, up-to-date answers.
🔒 Pre-bundled Documentation: All documentation is included with the package - no runtime downloads
🛡️ No External Dependencies: Runs completely offline after installation
✅ Verified Content: Documentation is verified during our CI/CD process
🚀 Fast & Secure: No network requests during operation
🔐 Secure Publishing: Uses npm Trusted Publishers (OIDC) for secure, automated releases with automatic provenance attestation
Ensure Node.js 20+ is installed: node --version (required for npm 11.5.1+ which supports OIDC)
For global install: verify with mcp-modus --help
Check IDE logs for error messages
Documentation is pre-bundled with each release for security and reliability. No downloads occur during installation or runtime.
If you used the NPX option (Option 1), no permanent installation exists. NPX downloads are temporary.
If you used the Global Install option (Option 2), uninstall with:
npm uninstall -g @julianoczkowski/mcp-modusBuilt for developers using Modus Web Components | MIT License | Made by Julian Oczkowski
Built by Julian Oczkowski — I build AI tools for knowledge work.
🎥 YouTube · @aiforwork_app — walkthroughs and AI-for-work tutorials
✍️ Medium — deep dives on product and AI workflows
💼 LinkedIn — connect and follow along
Find components that have a specific attribute or property.
| Name | Required | Description | Default |
|---|---|---|---|
| attribute | Yes | The attribute name to search for (e.g., "disabled", "color", "size") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as case sensitivity, match type, performance, or return format. Minimally informative for a search operation.
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?
Single sentence, no wasted words. Efficient but could include more context without losing brevity, e.g., scope or return type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple input, the description lacks details on return values, pagination, or limitations. Incomplete for a search tool with no annotations.
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 has 100% coverage with a description for 'attribute'. The description adds nothing beyond 'specific attribute or property', which is already implied. Baseline score 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 finds components by attribute, distinguishing it from siblings like search_components (likely name-based) and list_all_components. However, 'attribute or property' is somewhat vague; could specify the scope.
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 vs alternatives. Implied usage when searching by attribute, but no exclusions or comparison to sibling tools like search_components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete documentation for a specific Modus Web Component including attributes, events, and usage examples.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | The component name (e.g., "button", "card", "modal") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the tool returns 'complete documentation' but does not specify the return format (plain text, markdown, etc.), any authentication needs, or limitations (e.g., if documentation is fetched from an external source). The read-only nature is implied but not explicit.
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, clear sentence that is front-loaded with the action and outcome. It could be slightly more concise but remains efficient and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter and no output schema, the description adequately conveys the tool's purpose but lacks details on the nature of the returned documentation (e.g., whether it includes styling guidelines, accessibility info). It is minimally complete for a retrieval 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?
The input schema covers the single parameter 'component' with examples, achieving 100% schema description coverage. The tool description adds minimal additional meaning beyond referencing 'specific Modus Web Component', so baseline score 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's purpose: retrieving complete documentation for a specific Modus Web Component, listing included elements (attributes, events, usage examples). This distinguishes it from sibling tools like list_all_components (which lists all components) and search_components (which searches).
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 use when needing documentation for a specific component, but does not explicitly state when to prefer this over siblings (e.g., use list_all_components to browse, or search_components to find components). No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific design rules for Modus Web Components (colors, icons, spacing, typography, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The design rule category (e.g., "colors", "icons", "spacing", "typography", "breakpoints", "radius_stroke") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior; it only mentions 'get' implying read-only but lacks details on caching, errors, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence that is front-loaded with verb and resource, containing no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description provides minimal yet sufficient purpose, but omits return type or error handling guidance.
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 single parameter 'category' is fully covered in schema and description; the description adds concrete examples beyond the schema's listing, aiding correct selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get', the resource 'design rules', and the specific scope 'Modus Web Components' with enumerated categories, distinguishing it from sibling search and listing tools.
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 like search_design_rules or list_design_categories; usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get universal development rules and best practices for Modus Web Components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the call is read-only, requires authentication, has rate limits, or returns cached data. The term 'Get' implies a read operation, but no further details are given.
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 with no wasted words. It is concise but could be slightly more informative without becoming verbose. Structure is simple and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide enough context about what the tool returns. It only names the resource but does not describe the return format, structure, or content of 'development rules'. The description is adequate but incomplete.
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?
Input schema has 0 parameters, and schema description coverage is 100%. The description does not add parameter-specific information, but with no parameters, the baseline of 4 is appropriate. No additional semantics are 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?
Description clearly states the verb 'Get' and the resource 'universal development rules and best practices for Modus Web Components'. It distinguishes this tool from siblings like get_design_rules, get_setup_guide, and get_component_docs, which cover different 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 on when to use this tool versus alternatives. Does not mention prerequisites, context, or exclusions. The description merely states what it does without helping the agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get setup instructions for HTML or React projects using Modus Web Components.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | The setup type ("html", "react", "testing") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It implies read-only behavior ('Get') but does not explicitly state that the tool has no side effects, requires no authentication, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is easy to parse. However, it is slightly under-specifying by omitting the 'testing' type, which would have been more accurate.
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 (one parameter, no output schema), the description is mostly adequate. It does not explain the return format or the difference between setup types, but for a basic retrieval tool it meets a minimum viable standard.
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?
With 100% schema coverage, the description adds little value beyond the schema. It redundantly lists 'HTML or React' but fails to mention the 'testing' option, creating a mild inconsistency.
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 identifies the tool's purpose: retrieving setup instructions for HTML or React projects using Modus Web Components. However, it omits the 'testing' type that is valid according to the schema, slightly reducing clarity.
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 its siblings (e.g., get_component_docs, list_all_components). The description does not indicate scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get theme implementation guidelines and usage instructions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose any behavioral traits beyond the basic operation, such as whether it requires authentication or is read-only.
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 directly states the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, output schema, or annotations, the description is adequate but lacks details about the format or scope of the returned guidelines.
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?
There are no parameters, and the schema coverage is 100% with an empty schema. The description adds no extra meaning, but the baseline for zero parameters is 4.
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 retrieves theme implementation guidelines and usage instructions, but does not differentiate from sibling tools like get_component_docs or get_design_rules.
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 on when to use this tool versus alternatives; usage context is only implied by the name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Modus Web Components with their categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it lists all components with categories but doesn't disclose if there are limits (e.g., pagination, max results) or how categories are structured. Adequate but not rich.
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?
Single sentence, no wasted words, front-loaded with action and scope.
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 list-all tool with no parameters and no output schema, the description is sufficient to convey the basic function. Could mention if list is sorted or grouped, but not 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?
No parameters exist, so schema coverage is 100% by default. The baseline for 0 parameters is 4, and the description correctly implies no filtering 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 clearly states the verb 'List' and the resource 'all available Modus Web Components with their categories', distinguishing it from siblings like search_components (which implies filtering) and find_by_attribute (search by attribute).
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 vs alternatives like search_components. The purpose implies it's for an overview, but no when-not or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available design rule categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description merely restates the tool's purpose without disclosing behavioral traits like return format, cardinality, or side effects. It reads as a tautology.
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?
A single, front-loaded sentence with zero wasted words. 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?
For a parameterless, read-only listing tool, the description is minimally adequate. However, it lacks details about the output format or any scope, which could be improved given the absence of an 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 tool has no parameters, so schema coverage is 100%. The description adds no parameter details, which is acceptable as there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'design rule categories', distinguishing it from sibling tools like 'get_design_rules' or 'search_design_rules'.
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, nor any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Modus Web Components by name or keyword. Returns a list of matching components with brief descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (component name, keyword, or feature) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states it returns matching components with brief descriptions, omitting details like pagination, ordering, error handling, or read-only semantics.
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?
Very concise at two sentences, with the purpose front-loaded. Efficient but could benefit from slightly more context without becoming verbose.
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 10 sibling tools and no output schema, the description is too minimal. It does not explain result format, scope, or how it differs from similar tools, leaving gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already explains 'query' as a search string. The description's 'by name or keyword' adds minimal additional meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for Modus Web Components by name or keyword and returns a list with brief descriptions. It uses a specific verb and resource, but does not explicitly differentiate from siblings like find_by_attribute or list_all_components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., list_all_components for browsing all, find_by_attribute for attribute-based search). The description lacks use cases or 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 design rules by keyword or term.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for design rules (e.g., "primary color", "icon size", "spacing scale") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'search across all design rules' but lacks details on pagination, search algorithm (exact vs fuzzy), case sensitivity, or result limits. This leaves significant behavior 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, front-loaded sentence that directly states the tool's purpose with no extraneous words. Every word is necessary and 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 simplicity of the tool (1 parameter, no output schema, no annotations), the description is minimally adequate but lacks detail on what the search results look like or any behavioral specifics. It covers the basic purpose but not enough for an agent to fully understand 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?
Schema description coverage is 100% for the single required parameter 'query'. The description repeats the concept of keyword search but adds minimal additional meaning beyond the schema's example values. Baseline 3 is appropriate as schema does the heavy lifting.
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 (search) and resource (design rules). It distinguishes itself from sibling tools like 'get_design_rules' which retrieves specific rules, and 'search_components' which searches components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when keyword search is needed, but it does not provide guidance on when not to use it or mention alternatives. No explicit when-to-use or when-not-to-use context.
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.
find_by_attributeget_component_docsget_design_rulesget_development_rulesget_setup_guideget_theme_usagelist_all_componentslist_design_categoriessearch_componentssearch_design_rulesScored across 10 tools
Tools are mostly distinct, but find_by_attribute and search_components have overlapping functionality for finding components, which could cause confusion. Descriptions help disambiguate them.
All tool names follow a consistent snake_case pattern with verb_noun structure (e.g., get_component_docs, list_all_components). The actions are clearly indicated by the initial verb.
With 10 tools, the server is well-scoped for a component library documentation and rule set. Each tool serves a clear purpose without being overwhelming.
The tool surface covers all major aspects of working with Modus Web Components: component discovery, documentation, design rules, development rules, setup, and theme usage. No obvious gaps for a documentation server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Serves your design system and coding standards to coding agents, so they stop guessing.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Versioned documentation registry and semantic search for AI tools and coding assistants.
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
