HeroUI Migration MCP

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each tool has a clearly distinct purpose within the HeroUI migration domain: analyze_file focuses on code analysis, audit_tailwind targets configuration files, compare_component handles component comparisons, corpus_status checks documentation artifacts, rewrite_file performs code migrations, and scan_project scans directories. There is no overlap or ambiguity in their functions.
Naming Consistency4/5
The tool names follow a consistent verb_noun pattern (e.g., analyze_file, audit_tailwind, compare_component) with clear, descriptive verbs. The only minor deviation is 'corpus_status', which uses a noun_verb structure, but overall the naming is highly predictable and readable.
Tool Count5/5
With 6 tools, the server is well-scoped for its purpose of HeroUI migration. Each tool serves a specific role in the migration workflow, from scanning and analysis to comparison and rewriting, making the count appropriate and efficient for the domain.
Completeness4/5
The tool set covers key aspects of a migration workflow: scanning (scan_project), analysis (analyze_file, audit_tailwind), comparison (compare_component), documentation checks (corpus_status), and rewriting (rewrite_file). A minor gap might be tools for handling edge cases or rollback operations, but the core migration process is well-covered.
Average 3.1/5 across 6 of 6 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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
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 provided, the description carries full burden but omits critical safety information: whether the operation is destructive, if it requires specific file permissions, or what 'heuristic' implies regarding reliability. While it mentions returning 'rewritten source plus diagnostics,' it doesn't explain error conditions or side effects.
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?
Single sentence with minimal waste. Front-loaded with the action (apply migrations) followed by return value. 'Heuristic migrations' is slightly opaque but the structure is efficient.
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 zero annotation coverage, 0% schema descriptions, no output schema, and a mutation-oriented operation (rewrite), the description is insufficient. It lacks input constraints, error handling details, and behavioral guarantees needed for a code transformation 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 coverage is 0% (no descriptions in schema), yet the description fails to compensate by defining the 'code' parameter. It doesn't specify expected format, language constraints, or whether this accepts file paths, raw strings, or specific syntax.
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 uses specific verbs (apply, return) and identifies the resource (code/source). However, 'heuristic migrations' remains somewhat jargon-heavy and doesn't clearly differentiate from sibling tools like analyze_file or compare_component which might also process code.
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 provided on when to use this tool versus siblings like analyze_file or compare_component. No mention of prerequisites or conditions where rewriting is preferable to other code analysis tools.
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 provided, so description carries full disclosure burden. While 'return detailed findings' implies read-only behavior, it fails to explicitly confirm safety, side effects, output format, or what constitutes 'legacy' patterns.
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?
Single efficient sentence (12 words) that front-loads the action and target. No redundant or wasteful text.
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?
For a 2-parameter analysis tool with no output schema, the description adequately covers the analysis scope but leaves critical gaps regarding the optional filename parameter and return value structure. Minimum viable but incomplete.
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 coverage is 0% with no parameter descriptions. Description mentions analyzing 'code' which maps to the required parameter, but offers no explanation for the optional 'filename' parameter (its purpose, format, or when to include it). Inadequate compensation for schema gaps.
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?
States specific verb ('Analyze') and target resource ('code'), listing concrete analysis targets (legacy imports, components, props, hooks, Tailwind patterns). Implicitly distinguishes from sibling 'audit_tailwind' by breadth of analysis, though explicit comparison is absent.
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?
Provides no explicit guidance on when to use this tool versus siblings like 'scan_project' (multi-file) or 'audit_tailwind' (narrow scope). No prerequisites or exclusions mentioned.
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 carries the full burden. While 'analyze' implies a read-only operation, the description does not disclose auth requirements, side effects, rate limits, or what the analysis output format/structure looks like.
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?
Single sentence that is front-loaded and efficiently structured. Every word earns its place—no redundancy or boilerplate.
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?
Adequate for a single-parameter tool but incomplete given the lack of annotations and output schema. The description covers the core purpose but omits expected return values, error conditions, or behavioral constraints that would help an agent invoke the tool effectively.
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 0%, requiring the description to compensate. It partially compensates by implying the 'code' parameter should contain Tailwind configuration content, but does not explicitly document the parameter semantics, format requirements, or validation rules.
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?
Specific verb (analyze), resource (Tailwind configuration file), and scope (legacy HeroUI patterns) are clearly stated. However, it does not explicitly differentiate from the sibling 'analyze_file' tool, which is more generic.
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 explicit guidance on when to use this tool versus 'analyze_file' or other siblings. No mention of prerequisites or when not to use it. Usage is only implied by the specific domain mentioned.
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 full burden. It successfully discloses the alias lookup behavior, but fails to mention safety characteristics (read-only vs destructive), return format, or error behavior when components are missing.
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?
Single sentence efficiently packages the core functionality without repetition. Front-loaded with the action ('Show'), and every phrase earns its place by conveying unique operational scope (v2/v3, alias lookup).
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?
For a single-parameter tool, the description covers the primary function adequately, but lacks output specification (no output schema exists) and assumes domain knowledge of what v2 and v3 represent without clarifying the comparison context.
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 has 0% description coverage for the single 'component' parameter. The description implies the parameter accepts aliases via 'with alias lookup', adding some semantic meaning, but does not fully compensate for the lack of schema documentation (no format examples, constraints, or clear statement that component can be an alias).
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 identifies the resource (component) and action (show presence/status between v2 and v3), plus distinguishes from siblings via version-specific comparison and alias lookup capabilities that no other tools mention.
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 explicit guidance on when to use versus alternatives, nor prerequisites for the v2/v3 comparison context. The alias lookup feature implies usage when exact component names are unknown, but this is not explicitly stated.
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 carries full burden due to missing annotations. It discloses the recursive traversal behavior but omits critical safety information (read-only vs. destructive), output format/structure, and performance characteristics for large directories. It does not contradict any annotations.
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?
Single sentence with zero waste. 'Recursively' modifies the action, 'legacy HeroUI/NextUI components' specifies the target pattern, and 'directory' indicates the input scope. Perfectly front-loaded and appropriately sized.
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?
Given zero schema descriptions, missing annotations, and no output schema, the description is minimally adequate but incomplete. It fails to describe what the tool returns (file list? count? locations?) or how results are structured, which is essential information for an agent to use the output effectively.
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?
With 0% schema coverage, the description must compensate. It mentions 'scans a directory' which semantically maps to the 'directory' parameter, but provides no explicit parameter documentation, path format guidance (absolute vs. relative), or examples. Baseline assistance provided.
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 provides a specific verb ('recursively scans'), resource ('directory'), and scope ('files using legacy HeroUI/NextUI components'). The term 'legacy' and title's 'HeroUI v2' context effectively distinguish this as a migration detection tool versus siblings like analyze_file or rewrite_file, though it doesn't explicitly state these distinctions.
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 lacks explicit guidance on when to use this tool versus alternatives. While 'recursively scans a directory' implicitly contrasts with analyze_file (likely single-file), there are no explicit when/when-not statements or prerequisites mentioned.
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 full disclosure burden. It indicates the read-only nature through 'checks' and mentions inspecting 'presence and metadata,' which hints at the return structure. However, it omits details about return format, caching behavior, or performance characteristics expected of a status endpoint.
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?
Single efficient sentence with zero redundancy. Information density is high with no filler words, and the scope (presence + metadata) is clearly stated upfront.
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?
Adequate for a zero-parameter tool but incomplete regarding output contract. Since no output schema exists, the description should ideally specify the return structure (e.g., object with exists boolean and metadata fields) rather than just saying it 'checks' these things.
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?
Input schema contains zero parameters. Per scoring rules, 0 parameters establishes a baseline score of 4. The description does not need to compensate for missing parameter documentation.
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?
Provides specific verb 'checks' and clear resource 'generated documentation artifacts' (defining the 'corpus'). However, it does not explicitly differentiate from sibling tools like scan_project or analyze_file that might also inspect project state.
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?
Contains no guidance on when to invoke this tool versus alternatives (e.g., when to check corpus status versus scanning the project or analyzing specific files). No prerequisites or contextual triggers are mentioned.
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:

[![heroui-migration-mcp MCP server](https://glama.ai/mcp/servers/sctg-development/heroui-migration-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sctg-development/heroui-migration-mcp)

Score Badge

Copy to your README.md:

[![heroui-migration-mcp MCP server](https://glama.ai/mcp/servers/sctg-development/heroui-migration-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sctg-development/heroui-migration-mcp)

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/sctg-development/heroui-migration-mcp'

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