A
licenseNot graded
qualityA
maintenanceProvides design systems, UI prompts, and layout variation guidance to AI coding tools for generating better user interfaces.
475
1,851
MIT
mcp
Server Details
Provides UX capabilities to enhance the design output and understanding of AI systems.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
5 toolsdescribe_fontARead-onlyIdempotentInspect
Describes a font family in detail, including its look and feel, supported styles, weights and how to use it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Required. The platform in which the font family is going to be used. | |
| fontFamily | Yes | Required. The full name of the font family to describe. Example: "Roboto", "Noto Sans". |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| features | No | Supported features of the font family such as weight, style and variable axes, if available, in Markdown format. |
| guidance | No | Guidance on how to effectively use the font family, if available. |
| errorHelp | No | Optional. Contextual help text if the font family name was not found or is invalid. |
| languages | No | List of supported language and script in BCP47 format. |
| description | No | Description of the font family, in Markdown format. |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only and idempotent. The description is consistent with these annotations and adds useful context about the content of the response (look and feel, styles, weights, usage). It does not contradict the annotations and provides some additional behavioral context beyond the flags.
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, well-crafted sentence that front-loads the core purpose and lists specific details. There is no unnecessary information, and it is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only describe operation with two well-documented parameters, an output schema, and clear annotations, the description is fully sufficient. It communicates the essence without extraneous detail, and the output schema covers return values.
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% for both parameters, so the baseline is 3. The description does not add any parameter-specific information beyond what is already in the schema (e.g., fontFamily and platform descriptions are present in the schema). No extra value added to parameter understanding.
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 the tool 'describes a font family in detail' and lists specific aspects (look and feel, supported styles, weights, usage). It is distinct from sibling tools like search_fonts and search_icons, but does not explicitly contrast itself. The verb+resource is specific and unambiguous.
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 (to get detailed font information) but provides no explicit guidance on when not to use it or how it compares to alternatives like search_fonts. There is no mention of exclusions or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_color_schemeARead-onlyIdempotentInspect
Generates a Material Design color scheme from one or more key colors. Always use this when you need to create a color scheme for an application. The input is one or more named colors in hex format, and the output is a color scheme with a map of color role names to colors in hex format.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| primaryKey | Yes | Required. The primary key color used as the main seed for the scheme. Can be a 6-character hex code (e.g., "#4285F4" or "4285F4"), or any standard CSS color name (e.g., "blue"). | |
| tertiaryKey | No | Optional. The tertiary key color used to generate the color scheme. If omitted, it will be automatically derived from the other keys. Can be a hex code or any CSS color name. | |
| secondaryKey | No | Optional. The secondary key color used to generate the color scheme. If omitted, it will be automatically derived from the other keys. Can be a hex code or any CSS color name. | |
| backgroundKey | No | Optional. The neutral key color used to generate the color scheme. If omitted, it will be automatically derived from the other keys. Can be a hex code or any CSS color name. | |
| contrastLevel | No | Optional. The contrast level of the color scheme. Values range from -1 (minimum contrast) to 1 (maximum contrast). 0 represents standard contrast (i.e. the design as specified). | |
| optionalTheme | No | Optional. Whether to generate a light or dark theme. If unspecified, and a background key is supplied, it will be inferred from that. If not, it will default to light theme. | |
| optionalSchemeVariant | No | Optional. If only the primary key color is supplied, this will select which variant of the color scheme to use. If only the primary key color is supplied and this is not set, it defaults to "TONAL_SPOT". If multiple key colors are supplied, this is ignored, and it will default to "BRAND". |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| colorScheme | No | The generated color scheme. |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the output structure (a map of color role names to hex colors) but does not disclose additional behaviors beyond that.
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 three concise sentences: what it does, when to use it, and what the input/output look like. Every sentence earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich input schema, annotations, and an output schema, the description appropriately covers purpose, usage context, and high-level input/output. It doesn't need to explain optional parameters or return values because the structured data already does. Minor lack of detail about derivation of optional colors is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter fully documented in the input schema. The description only says 'one or more named colors in hex format,' which is less detailed than the schema and adds no new meaning. Baseline 3 is appropriate because the schema does the heavy lifting.
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 generates a Material Design color scheme from key colors, with a specific verb ('Generates') and resource ('color scheme'). It is easily distinguished from sibling tools (fonts/icons) and adds the input/output shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Always use this when you need to create a color scheme for an application,' providing clear when-to-use guidance. There are no alternative tools in the sibling list for this purpose, so no exclusionary guidance is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
icons_instructionsARead-onlyIdempotentInspect
Provides essential and critical instructions on how to use Material Icons and Material Symbols efficiently on Web.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| instructions | No | Instructions on how to use Google Material Icons and Google Symbols efficiently. |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the topic scope but does not disclose what the returned instructions contain, their format, or any usage caveats.
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 wasted words. It conveys the essential purpose and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter instructions tool with a rich annotation set and an output schema, the description is sufficiently complete. It names the exact subject matter and platform, which is enough context for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning because there are no parameters to explain.
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 provides instructions on using Material Icons and Material Symbols on the Web. It uses a specific action ('provides instructions') and resource ('Material Icons and Material Symbols'), distinguishing it from sibling search/describe/generate tools.
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 should be used when the agent needs guidance on using Material Icons/Symbols, but it does not explicitly state when to use it versus alternatives. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_fontsARead-onlyIdempotentInspect
Finds appropriate fonts matching categories and/or languages.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Optional. The sort order for the returned font families. Defaults to POPULARITY_DESCENDING if unspecified. | |
| platform | Yes | Required. The platform in which the font family is going to be used. | |
| languages | No | Optional. Language tags in BCP47 format to filter fonts that support specific scripts (e.g., "en_Latn", "zh_Hans"). | |
| categories | No | Optional. One or more categories to filter font families |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| errorHelp | No | Optional. Contextual help text or error descriptions if the query failed. |
| fontFamilies | No | The names of font families that match the search criteria (e.g., "Roboto", "Open Sans"). |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers safety and side-effect behavior. The description adds little beyond the schema's request message description, and it does not discuss output format, pagination, or filtering behavior beyond stating the main criteria. Since annotations cover the key behavioral aspects, a score of 3 is appropriate for adding minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. It is front-loaded and contains no filler, making it highly efficient for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with a rich schema (100% coverage, enums with descriptions) and an output schema, the description adequately complements the structured data. It covers the core purpose and key filters, but could mention that it returns font families or that it supports more filters beyond categories and languages (e.g., sort order), though the schema handles those. Given the schema's richness, the description is sufficient.
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%: every parameter has a description and enums have extended descriptions. The description mentions 'categories and/or languages' which aligns with two parameters, but it adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.
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 'Finds appropriate fonts matching categories and/or languages' clearly states the tool's purpose (searching fonts) and specifies the main filtering criteria (categories and languages). It is specific enough to distinguish from siblings like 'describe_font' (which describes a single font) and 'search_icons' (which searches icons), though it does not explicitly name alternatives.
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 the tool is for discovering fonts based on filters, but it does not provide explicit guidance on when to use this tool over siblings or when not to use it. The schema's required 'platform' parameter and optional filters imply typical usage for font selection, but no alternative tools or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_iconsARead-onlyIdempotentInspect
Finds appropriate Material Design icons matching keywords that describe their usage, style, or shape.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | Required. A list of semantic keywords or metadata tags that describe the desired icon's visual or functional properties. If possible, specify at least three tags to describe usage, style, and shape. Examples: - For a "save" icon: ["save", "diskette", "document", "storage"] - For a "home" icon: ["home", "house", "building"] If multiple tags are provided, the service returns icons that match any part of the tag list, ordered by relevance (number of matching tags). If no tags are provided, all icons are returned. | |
| iconSet | No | Optional. The icon set to search within (e.g., "Material Symbols", "Material Icons"). If omitted, the default icon set of the environment is used. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| icons | No | The names of icons that match the provided tags, ordered by relevance. |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds no further behavioral context (e.g., ordering, pagination, or output format), but it does not contradict annotations. This meets the baseline for tools with good 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that immediately conveys the tool's function. It is concise with no redundant information, and the key verb and object are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only search operation, the presence of a complete input schema (100% coverage) and an output schema, the description provides sufficient context. The purpose is clear, and the schema fills in parameter details, making the tool complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (tags and iconSet) are thoroughly documented in the schema. The description's mention of 'usage, style, or shape' mildly aligns with the tags parameter but does not add new meaning beyond the rich schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Finds appropriate Material Design icons matching keywords that describe their usage, style, or shape.' It specifies the verb (finds), the resource (Material Design icons), and the matching mechanism (keywords), distinguishing it from sibling tools like search_fonts and generate_color_scheme.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its clear focus on icon search, and the sibling tool names (search_fonts, describe_font) provide context for when to use this tool instead. However, it does not explicitly state 'when not to use' or name alternatives, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Deploy AI user personas to validate user journeys at scale. Find UX friction before real users do.
AI-powered user research for everyone
AI user research via studies, interviews, recruitment, reports, and quantitative surveys.
Run user research from any AI tool. Create studies, recruit participants, query insights.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides design capabilities including requirement analysis, visual token extraction, design generation, and visual auditing.
- AlicenseCqualityDmaintenanceProvides AI-powered tools to apply UX/UI best practices, Nielsen's heuristics, cognitive biases, and Material-UI patterns to React components. Enables automated application of responsive design, Apple design patterns, and complete UX guidelines through natural language commands.7184MIT
- AlicenseNot gradedqualityBmaintenanceDeploys AI user personas to validate user journeys at scale, surfacing UX friction before real users encounter it.1MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4/5.0
Disambiguation5/5
Each tool targets a distinct artifact: fonts, color schemes, icons, and icon instructions. There is no overlap in purpose, making misselection very unlikely.
Naming Consistency4/5
Three tools follow a clear verb_noun pattern (generate_color_scheme, search_fonts, search_icons), while describe_font and icons_instructions deviate slightly but remain predictable and readable.
Tool Count5/5
Five tools is well within the sweet spot for a design-resource server covering fonts, icons, and colors, with no unnecessary bloat.
Completeness4/5
The surface covers core workflows: finding fonts/icons, generating color schemes, and getting usage instructions. Minor gaps exist (e.g., no tool for fetching icon metadata individually), but nothing that blocks typical use.