Provides semantic class names for Bootstrap 5, enabling AI to generate concise, SSR-safe HTML components with minimal class strings, and supports custom patterns and minification.
Generates semantic class names for Tailwind CSS, reducing token usage by replacing long utility class strings with short, readable names like btn-primary or card, with SSR safety awareness and optional minification.
Supports UnoCSS by offering pre-defined semantic class names and patterns, allowing AI to produce compact, readable code that is SSR-safe and can be minified for maximum token savings.
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., "@classmcp get btn-primary class for tailwind"
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.
Multi-Framework MCP Server for AI-Optimized CSS Generation
Stop wasting tokens on long utility class strings. Let AI generate code with semantic class names like btn-primary and card - with full SSR safety awareness and optional minification.
Supports Tailwind CSS, Bootstrap 5, UnoCSS, and Tachyons.
When AI generates utility-first CSS code, it creates verbose class strings:
<button class="inline-flex items-center justify-center px-4 py-2 bg-blue-600 text-white text-sm font-medium rounded-lg hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-offset-2 transition-colors">
Click me
</button>This wastes:
AI tokens - longer context = higher costs
Your time - harder to read and debug
Bundle size - repeated patterns bloat HTML
SSR safety - easy to accidentally use client-only patterns
Related MCP server: tailwindcss-mcp-server
classmcp provides semantic class names to AI assistants:
<!-- Semantic -->
<button class="btn-primary">Click me</button>
<!-- Or ultra-minified for maximum savings -->
<button class="a">Click me</button>The AI queries available patterns, uses short names, and you get clean, readable code that's SSR-safe.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"classmcp": {
"command": "npx",
"args": ["classmcp"]
}
}
}npx classmcpSwitch between CSS frameworks instantly:
set_framework: "tailwind" # Default
set_framework: "bootstrap" # Bootstrap 5
set_framework: "unocss" # UnoCSS
set_framework: "tachyons" # TachyonsEvery pattern is marked for server-side rendering compatibility:
get_ssr_info: "modal-overlay"
→ Status: ⚠️ Requires Client JS
→ Warning: Modal visibility controlled by JS
→ Recommendations: Use useEffect to add client-only classesFilter for SSR-safe patterns only:
list_classes: { ssrSafeOnly: true }Generate ultra-short class names for maximum token savings:
get_class: { name: "btn-primary", minified: true }
→ Class: "a" (saves 11 chars per usage)Define your own semantic class names by creating a .classmcp.json file in your project root:
Simple format:
{
"customPatterns": [
{ "id": "brand-btn", "classes": "px-4 py-2 bg-brand-600 text-white rounded-lg font-semibold" },
{ "id": "pricing-card", "classes": "p-8 border-2 border-gray-100 rounded-2xl shadow-xl" }
]
}With states and metadata:
{
"customPatterns": [
{
"id": "brand-btn",
"category": "buttons",
"description": "Brand-colored primary button",
"classes": {
"base": "px-4 py-2 bg-brand-600 text-white rounded-lg font-semibold",
"hover": "hover:bg-brand-700 hover:shadow-md",
"focus": "focus:ring-2 focus:ring-brand-300"
}
}
],
"overrideBuiltins": false,
"defaultFramework": "tailwind"
}Config options:
Option | Description |
| Array of custom pattern definitions |
| If |
| Default framework to use (tailwind, bootstrap, unocss, tachyons) |
Pattern options:
Field | Required | Description |
| Yes | Unique identifier (e.g., "brand-btn") |
| Yes | CSS classes (string or state object with base/hover/focus/active/disabled) |
| No | Category for organization (defaults to "custom") |
| No | Human-readable name (defaults to id) |
| No | Description of when to use |
| No | Limit to specific frameworks (e.g., ["tailwind"]) |
| No | Whether pattern is SSR-safe |
Alternative config locations:
.classmcp.json (recommended)
classmcp.config.json
package.json under "classmcp" key
After modifying your config, use the reload_config tool to apply changes without restarting.
Tool | Description |
| Set CSS framework (tailwind, bootstrap, unocss, tachyons) |
| Get utility classes for a semantic name |
| List available classes (filter by category, SSR-safe) |
| Search for classes by name or description |
| Generate CSS file with all class definitions |
| Get complete HTML component examples |
| Check SSR/hydration safety for a pattern |
| List all available frameworks with statistics |
| Reload custom patterns from config file |
| List all user-defined custom patterns |
buttons - btn-primary, btn-secondary, btn-danger, btn-ghost, btn-outline
cards - card, card-bordered, card-header, card-body, card-footer
forms - input, input-error, label, select, checkbox, textarea, toggle
badges - badge-primary, badge-success, badge-warning, badge-danger
alerts - alert-info, alert-success, alert-warning, alert-error
avatars - avatar-sm, avatar-md, avatar-lg
layout - container, flex-center, flex-between, stack, row, grid-2, grid-3
typography - heading-xl, heading-lg, heading-md, text-body, text-muted
navigation - nav, nav-link, nav-link-active
modals - modal, modal-overlay, modal-header, modal-body, modal-footer
tables - table, table-header, th, td, tr-hover
lists - list, list-item, list-item-hover
loading - spinner, skeleton, skeleton-text, skeleton-avatar
dividers - divider, divider-vertical
Ask Claude:
"Create a card with a user profile, showing avatar, name, email, and action buttons"
Claude will use classmcp to generate:
<div class="card">
<div class="flex-start space-x-4">
<div class="avatar-lg">JD</div>
<div class="stack">
<h3 class="heading-sm">John Doe</h3>
<p class="text-muted">john@example.com</p>
</div>
</div>
<div class="card-footer">
<button class="btn-primary">Message</button>
<button class="btn-secondary">Profile</button>
</div>
</div>Generate the CSS:
# Ask Claude to use the generate_css tool, or:
npx classmcp generate-css > src/classmcp.cssImport in your CSS:
Tailwind:
@import "tailwindcss";
@import "./classmcp.css";Bootstrap:
@import "bootstrap/dist/css/bootstrap.min.css";
@import "./classmcp.css";Component | Without classmcp | With classmcp | Minified | Savings |
Button | 180 chars | 12 chars | 1 char | 99% |
Card | 85 chars | 5 chars | 1 char | 99% |
Input | 145 chars | 6 chars | 1 char | 99% |
Modal | 200+ chars | 12 chars | 1 char | 99% |
Over a full page with 50+ components, this adds up to thousands of tokens saved.
All button variants (hover/focus are CSS pseudo-classes)
All card patterns
Form inputs (base styling)
Typography patterns
Layout utilities
Badges, alerts
modal-overlay - visibility needs JS
toggle - checked state
spinner - animation timing
alert-dismissible - close button
Use ssrSafeOnly: true or check with get_ssr_info when building Next.js/Nuxt/Remix apps.
Framework | Patterns | SSR-Safe | Categories |
Tailwind CSS | 70+ | 65+ | 14 |
Bootstrap 5 | 70+ | 65+ | 14 |
UnoCSS | 70+ | 65+ | 14 |
Tachyons | 70+ | 65+ | 14 |
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Claude │────▶│ classmcp │────▶│ Your Code │
│ │ │ (MCP) │ │ │
│ "Make a │ │ │ │ <button │
│ button" │ │ get_class │ │ class= │
│ │◀────│ btn-primary │ │ "btn- │
│ │ │ (SSR-safe) │ │ primary"> │
└─────────────┘ └─────────────┘ └─────────────┘AI asks classmcp for available classes
classmcp returns semantic names + SSR safety info
AI generates code using short class names
You add the generated CSS to your project
Your CSS framework compiles it
classmcp = AI layer (development time) - helps AI generate clean code
classpresso = Build layer (build time) - optimizes existing code
They're complementary:
Use classmcp when writing new code with AI
Use classpresso to optimize existing/legacy code
MIT
Generate CSS that defines all semantic classes. Add this to your project's CSS file to use the semantic class names.
| Name | Required | Description | Default |
|---|---|---|---|
| categories | No | Only generate CSS for specific categories (optional) | |
| minified | No | Generate minified class names (a, b, c...) for maximum file size reduction | |
| includeStates | No | Include hover/focus/active state variants (default: true) |
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. It lacks detail on behavior: output format, side effects, or prerequisites. The description only mentions generating CSS without elaboration.
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?
Two sentences, front-loaded with the action, no wasted words. It is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain what the generated CSS looks like or how to use it. It mentions adding to a CSS file but lacks context on format or configuration, making it incomplete for a generative tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The tool description adds no extra meaning beyond the schema, 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 the tool generates CSS defining all semantic classes, and it is distinct from siblings like get_class or list_classes which retrieve or list classes.
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 gives a usage hint ('Add this to your project's CSS file') but no explicit guidance on when to use this vs alternatives, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full utility classes for a semantic class name. Returns the CSS classes you should use in your HTML. Supports SSR-safe filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The semantic class name (e.g., 'btn-primary', 'card', 'input') | |
| minified | No | Return a minified single-character class name for maximum token savings (default: false) | |
| ssrSafe | No | Only return SSR-safe classes that won't cause hydration mismatches (default: false) | |
| includeStates | No | Include hover/focus/active state variants in the output (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions SSR-safe filtering but does not state that the operation is read-only or side-effect-free. An agent cannot infer safety or impact from the description alone.
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?
Two concise sentences that front-load the core purpose and add a notable feature. Every word earns its place with no fluff.
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?
Despite having 4 parameters and no output schema, the description does not specify the return format (e.g., array, string). The agent would need to infer structure. For a complete specification, details on output should be included.
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 has 100% description coverage, so the schema already documents all four parameters. The description adds no extra meaning beyond referencing 'SSR-safe filtering', which aligns with the ssrSafe parameter. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets the full utility classes for a semantic class name, specifying the output (CSS classes for HTML) and a key feature (SSR-safe filtering). This is distinct from sibling tools like list_classes or search_classes.
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 vs alternatives such as list_classes or search_classes. The description does not mention prerequisites or common use cases, 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.
Get a complete HTML component example using semantic classes. Great for seeing how classes work together.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Component type to generate | |
| minified | No | Use minified class names in the example |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states it returns a complete HTML component example, but does not disclose idempotency, side effects, rate limits, or return format beyond 'HTML component example'.
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?
Two concise sentences with no unnecessary information. However, the first sentence could be more informative about the return format.
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?
No output schema is provided, so the description should explain the return format more thoroughly. It only says 'complete HTML component example' but does not specify whether it's a string, object, or includes styling.
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%, so baseline is 3. The description adds no extra context about parameters (e.g., what each component type represents or when to use minified).
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 gets a complete HTML component example using semantic classes, which is specific and distinct from sibling tools like get_class (single class) or list_classes (list of classes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for seeing how classes work together, but does not explicitly state when to use this tool versus alternatives like get_class or list_classes, nor does it provide 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.
Get SSR/hydration safety information for a class pattern. Use this when building SSR/Next.js/Nuxt/Remix applications to avoid hydration mismatches.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The class name to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it 'gets' info but does not describe the output format or behavior (e.g., returns boolean, string, recommendations). Lacks full transparency.
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?
Two sentences, to the point, front-loaded with purpose and context. No unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description covers purpose and usage well. Minor gap: does not describe the return value, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. Description adds no extra meaning beyond the schema's 'The class name to check'.
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 tool retrieves SSR/hydration safety info for a class pattern, distinguishing it from sibling tools like get_class or get_component by focusing on SSR safety.
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?
Explicitly recommends use when building SSR applications with Next.js/Nuxt/Remix to avoid hydration mismatches, but does not mention when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available semantic class names, optionally filtered by category. Use this to discover available patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category: buttons, cards, forms, badges, alerts, avatars, layout, typography, navigation, modals, tables, lists, loading, dividers | |
| ssrSafeOnly | No | Only show SSR-safe classes (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It indicates a read operation (list) but does not detail side effects, authentication needs, or output format. Given the lack of annotations, the description is adequate but not exhaustive.
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?
Two sentences, front-loaded with the action ('List all available semantic class names'), and no wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 optional parameters and no output schema, the description covers the purpose and usage hint. It could benefit from specifying the output format (e.g., just names or objects), but it is mostly complete for a simple listing.
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%, so the input schema already documents parameters well. The description merely echoes the optional filter capability without adding new semantic meaning beyond what the schema provides.
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 lists all available semantic class names, optionally filtered by category. This distinguishes it from siblings like 'search_classes' (searching) and 'get_class' (single class details), providing a specific verb and resource.
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 suggests using the tool to 'discover available patterns,' giving a clear usage context. However, it does not explicitly mention when not to use it (e.g., for detailed info on a single class, use 'get_class'), leaving some ambiguity against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all custom (user-defined) patterns loaded from your config file.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | No | Filter by framework (optional, defaults to current framework) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It accurately describes a read operation without side effects, but does not explicitly state read-only nature or discuss any behavioral nuances. Adequate but minimal.
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 verb and resource. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description plus schema cover the essentials. It does not explain what a 'pattern' is, but that may be inferred from context. Output schema is absent, but not required for completeness here.
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 parameter 'framework', so the description does not need to add meaning. It provides no extra detail beyond the schema, consistent with baseline score 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists custom (user-defined) patterns from config, distinguishing it from sibling tools like list_classes (system classes) and list_frameworks.
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 vs alternatives, nor any prerequisites or context cues. The description does not help the agent decide between list_custom_patterns and other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available CSS frameworks and their statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It states the operation (list) and mentions statistics, but does not clarify what statistics include, whether auth is required, or if results are paginated. It is adequate for a simple read-only list but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It directly conveys the purpose and key output characteristic (statistics) without unnecessary details.
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 has no parameters and no output schema, the description is somewhat complete. However, it fails to explain what 'statistics' means, missing an opportunity to clarify return structure. It is sufficient for a basic list but leaves ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description adds value over the schema by specifying that the tool returns not just a list of names but also 'statistics,' which implies additional data beyond basic identification.
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 lists all available CSS frameworks and their statistics, with a specific verb and resource. It distinguishes itself from siblings like generate_css and get_class by focusing on listing available frameworks rather than generating or retrieving specific items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as search_classes or get_component. There is no mention of prerequisites, context, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload custom patterns from the config file (.classmcp.json). Use this after modifying your config file.
| 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 cover behavioral traits. It only states the action without detailing side effects, error handling (e.g., missing file), or safety considerations, leaving significant gaps.
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 extremely concise: two short sentences with no redundant words. Every word adds value, clearly stating the action and usage hint.
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 zero parameters and no output schema, the description should explain the reload behavior, but it omits details like whether patterns are replaced or merged, or what happens on errors. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is trivially 100%. The description adds no parameter information because there are none, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (reload) and the resource (custom patterns from .classmcp.json), with no ambiguity. It distinguishes the tool from siblings by being the only reload tool.
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 explicitly says 'Use this after modifying your config file', providing clear context for when to invoke the tool. It does not mention alternatives or exclusions, but the usage is straightforward given the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for classes by name, description, or category. Use when you're not sure of the exact class name.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (matches against name, description, and category) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks details on side effects, return format, or whether the operation is read-only. The minimal description does not compensate for missing annotations.
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?
Two sentences, no redundancy. Efficient and front-loaded with purpose and usage hint.
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?
Adequate for a simple search tool with one parameter. However, lacks details about output (e.g., returns list of classes), pagination, or errors. Given no output schema, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter with a clear description. The tool description adds usage context (fuzzy search), slightly enhancing parameter understanding.
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?
Clearly states the tool searches for classes by name, description, or category. Differentiates from siblings like 'get_class' (exact match) and 'list_classes' (listing all).
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?
Explicitly advises using this tool when the exact class name is unknown, implicitly steering away from 'get_class' for exact lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the CSS framework to use for all subsequent operations. Choose based on your project's CSS framework. DEFAULT: tailwind
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes | The CSS framework to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States the framework persists for 'all subsequent operations' but lacks detail on scope (session vs global) or side effects. Default value is mentioned.
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: one sentence plus a brief note about the default. No wasted 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?
For a single-parameter tool with full schema coverage and no output schema, the description is mostly complete. Could be more explicit about persistence scope, but sufficient for its simplicity.
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 covers 100% with enum and description. Description adds the default value ('DEFAULT: tailwind'), which provides useful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sets the CSS framework for all subsequent operations. Distinguishes from sibling tools like get_class and generate_css by indicating it's a configuration action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use ('Choose based on your project's CSS framework') and specifies the default value. No explicit when-not to use, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.1.0generate_cssget_classget_componentget_ssr_infolist_classeslist_custom_patternslist_frameworksreload_configsearch_classesset_frameworkEach tool has a clearly distinct purpose: generating CSS, retrieving class details, getting component examples, SSR info, listing classes, custom patterns, frameworks, configuration reload, searching, and framework setting. No overlap or ambiguity.
All tool names follow a consistent verb_noun snake_case pattern (e.g., generate_css, list_classes, set_framework). No mixing of conventions or vague verbs.
10 tools is well-scoped for a CSS utility server, covering all necessary operations without overloading or underprovisioning.
The tool surface covers generation, discovery, configuration, framework selection, and SSR compatibility. No obvious gaps for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheDecipherist/classmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
