Material 3 MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.1
Disambiguation5/5
Each tool targets a distinct aspect of Material 3: component discovery, code retrieval, design tokens, icon search, accessibility, theme generation, cache management, and component suggestions. Even the seemingly overlapping list and suggest tools are clearly separated by purpose—catalog filtering vs. use-case-based recommendations.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (list_, get_, search_, generate_, manage_, suggest_). Verbs are descriptive and uniform, making the API predictable and easy to navigate.
Tool Count5/5
With 8 tools, the server is well-scoped for a Material 3 design resource. Each tool covers a fundamental need without redundancy, and the count falls comfortably within the ideal 3-15 range.
Completeness5/5
The tool surface comprehensively covers Material 3 design workflows: exploring components, retrieving code and tokens, finding icons, checking accessibility, generating themes, and even providing AI-driven suggestions. The cache management tool is a sensible operational addition, and no obvious core capability is missing.
Average 3.3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on September 30, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not explicitly state the absence of side effects, return format, or any special behaviors such as caching or versioning. This minimal transparency is insufficient for safe tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that quickly gets to the point. It wastes no words and is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too sparse. It does not indicate the structure of the returned guidelines, whether the response varies by wcagLevel or includeARIA settings, or any error conditions. For a tool with four parameters and no structured output info, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 25% (componentName alone), and the description does not clarify the meanings of wcagLevel, includeARIA, or includeKeyboard. While 'WCAG 2.1' hints at the wcagLevel parameter, the description fails to explain how these parameters filter or shape the guidelines, adding little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns WCAG 2.1 accessibility guidelines for a Material 3 component. It uses a specific verb ('get') and resource ('accessibility guidelines'), and the qualifier distinguishes it from sibling tools like get_component_code and get_design_tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_component_code or list_material_components. There is no mention of prerequisite knowledge, use cases, or exclusion criteria, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the core exporting behavior and formats, but does not disclose output structure, side effects, authentication needs, or whether the operation is read-only. Since no annotations are provided, the description carries the full transparency burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that directly states the verb and resource without any filler. It is concise and well-structured, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three optional parameters and no output schema, yet the description does not explain parameter meanings or expected return values. It provides only a high-level purpose and is insufficient for an agent to fully understand how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the format options, which maps to the 'format' enum, but does not explain the meaning of 'tokenType' or 'includeDocumentation'. With 0% schema description coverage, this leaves two of three parameters unexplained, providing insufficient guidance for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (Export), a clear resource (Material 3 design tokens), and supported formats (CSS, SCSS, JSON, JavaScript). This clearly distinguishes the tool from siblings like get_component_code or generate_theme_from_color, which target other aspects of Material 3.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites, exclusions, or conditions under which other tools like generate_theme_from_color might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a safe read operation by using 'List' and mentions three filtering behaviors, but it does not disclose pagination, response format, ordering, or how deprecated components are treated (despite the includeDeprecated parameter). With no annotations, more detail on these behavioral aspects would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly communicates the purpose and key filters without any filler. It is concise and efficiently structured, though adding a second sentence with usage guidance would not detract from its conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description provides only a minimal summary. It does not explain the response structure, handling of deprecated components, or any limitations, leaving significant gaps for an agent to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only the framework parameter has a description). While the tool description mentions three filters, it omits the includeDeprecated parameter and does not explain defaults or the meaning of complexity levels, failing to compensate for the schema's lack of clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'available Material 3 components,' while also mentioning the key filtering dimensions (category, complexity, framework). This clearly distinguishes it from sibling tools that retrieve code, icons, tokens, or guidelines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, such as suggesting 'get_component_code' for code snippets or 'search_material_icons' for icon lookup. It simply states what it does without contextual recommendations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the tool searches and returns usage code, but it fails to explain what 'usage code' entails, which frameworks are supported, or whether it is a read-only operation. Details on response format and pagination are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 12 words, that front-loads the core function. No redundant or filler words are present, making it highly concise and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the output format, the meaning of 'usage code', supported frameworks, or how it differs from get_component_code. The vague 'usage code' claim leaves significant gaps for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only 'query' having a description. The description merely mentions 'filters' and does not explain the meaning of 'limit', 'style', or 'filled'. The schema's names and enums offer partial hints, but the description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the Material Symbols icon library, distinguishing it from sibling tools like list_material_components. However, the added 'get usage code for different frameworks' creates ambiguity about the exact output and its relation to get_component_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for searching icons and obtaining usage code, but it does not explicitly say when to use it over alternatives like get_component_code or list_material_components. No exclusions or alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only restates the core action without explaining side effects, whether the operation is read-only, if it makes external calls, or what the output structure will look like. This is a significant gap for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the key action and resource. Every word is necessary, and there is no filler or redundancy. This is an ideal level of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is too sparse. It leaves unanswered questions about what 'complete' means, how the format parameter affects output, and how contrastLevel influences the palette. The schema provides enums but not enough behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only contrastLevel is documented). The description adds meaning for baseColor ('single base color') but says nothing about mode, format, or contrastLevel. With such low schema coverage, the description should compensate more but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating a complete Material 3 color palette from a single base color. The verb 'generate' is specific, and the resource is well-defined. It naturally distinguishes itself from sibling tools that deal with components, icons, or design tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied but not explicit. It suggests using the tool when you have a base color and want a Material 3 palette, but it does not mention when not to use it or explicitly name alternatives. This is a clear context with no exclusions, so it falls between 'implied usage' and 'clear context'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure. It states 'Retrieve' which implies a read-only operation, but does not disclose output format, whether multiple files are returned, error behavior, or dependencies on framework support (e.g., react/angular coming soon). This is minimal disclosure for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core functionality. Every word adds value; no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, no output schema, and no annotations, the description is too brief to be complete. It does not explain what 'real source code' returns (single file vs. full project), how examples are integrated, or the implications of the framework parameter's limited support. This is insufficient for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes componentName, variant, and framework but leaves includeExamples and includeDependencies undescribed. The tool description mentions 'examples' which hints at includeExamples, but does not clarify includeDependencies or the default behavior of the boolean flags. It adds some context around variants/examples but does not fully compensate for the 60% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and clearly identifies the resource as 'real source code of specific Material 3 component', adding 'with variants and examples' to distinguish from sibling tools like list_material_components and get_design_tokens. This clearly states the tool's function and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining source code for a known component, but provides no explicit guidance on when to use this tool versus alternatives such as list_material_components or suggest_components_for_use_case. It lacks any exclusions or alternative references, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden of disclosing behavioral traits. It does mention 'invalidate stale data,' which signals a destructive operation, but it does not explain the scope of invalidation (e.g., all caches vs. component-specific), whether changes are reversible, or potential side effects on downstream tools. This lack of detail is a significant gap for a mutation-capable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that enumerates three key operations without filler or redundancy. It could be slightly more explicit about scope, but it earns its place as a concise summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (3 parameters, 4 enum actions) and no output schema or annotations. The description covers the high-level actions but leaves important contextual gaps such as what 'upstream changes' means, what data is returned, and safety implications of invalidation. The schema partially compensates, but overall the description is adequate yet incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (action, framework, componentName) having a descriptive explanation. The description adds no parameter-level detail beyond what the schema provides, landing at the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (cache) and the actions (check status, verify upstream changes, invalidate stale data). It distinguishes itself from sibling tools like list_material_components and get_design_tokens by focusing on cache health management rather than content retrieval or generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing to check cache status, verify upstream changes, or invalidate stale data) but provides no explicit guidance on when not to use it or how it compares to alternatives. Context from sibling names suggests it is the only cache management tool, but that is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must shoulder the burden of behavioral disclosure. It only mentions 'AI-powered' and 'suggestions', which hints at non-determinism and output type but provides no details on read-only behavior, return format, or edge cases like no matches. This is a significant gap for a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It states the core purpose immediately. While minimal, it earns its place in conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the tool returns (e.g., a list of components) and any constraints. It only states the purpose, leaving the agent to guess the output structure and behavior. This is inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage), so the description is not required to add more. It aligns with the useCase parameter but adds no detail beyond schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'component suggestions', and the input 'use case description'. This distinguishes it from siblings like list_material_components or get_component_code, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you have a use case description and need component suggestions. It does not explicitly mention alternatives, but the input condition is well-defined, giving the agent enough to decide. However, it lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![material3-mcp-server MCP server](https://glama.ai/mcp/servers/weppa-cloud/material3-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/weppa-cloud/material3-mcp-server)

Score Badge

Copy to your README.md:

[![material3-mcp-server MCP server](https://glama.ai/mcp/servers/weppa-cloud/material3-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/weppa-cloud/material3-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/weppa-cloud/material3-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server