Design review for UI code: 291 rules, scored 0-100 with fixes and git-applyable patches.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 4 of 4 tools scored.
The primary overlap is between quick_review and review_files, both triggered on the same UI-change events; they differ mainly in depth and cost, which could confuse an agent. usage and verify_fixes are clearly distinct. The detailed descriptions mitigate but don't eliminate the ambiguity.
All names use snake_case, but surface structure varies: quick_review is adjective_noun, review_files and verify_fixes are verb_noun, and usage is a bare noun. The inconsistent verb placement (quick_review vs review_files) adds to confusion. Still readable and not chaotic.
Four tools is an appropriate footprint for a design-review MCP server. Each serves a clear slot in the workflow—quick check, full review, quota lookup, and fix verification—without bloat.
The core design-review loop (review, fix, verify, check usage) is well covered. Minor gaps like listing past reviews or configuring rules would be nice but aren't essential to the primary purpose. The server achieves its stated goal with minimal dead ends.
quick_reviewRams quick checkAInspectFast design check over the UI files you just changed. Returns issues with severity, category and file:line, in about 10 seconds. Cheap: five quick checks cost one review credit, so a whole editing session spends a fraction of one review. Use this one CONSTANTLY: after writing or editing a component, before committing, whenever you want to know if what you just wrote is sound. You do not need to ask the user first. It returns no score and no ready-made patch: fix the issues yourself in the files you already have open. When the user wants a score to keep, a patch to apply, or a review to quote, use review_files instead.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | The UI files you just changed | |
| context | No | Short label, e.g. the component or feature name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond annotations: speed (~10 seconds), cost (one review credit per five checks), absence of score/patch, and that the agent must fix issues itself. It does not explicitly state whether the tool modifies files, but the guidance to fix things in already-open files implies no patch is returned. No contradictions with 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?
The description is front-loaded with purpose and return value, then covers cost, usage frequency, permissions, limitations, and alternatives. It is somewhat wordy, but each sentence adds decision-relevant information for an agent.
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?
With no output schema, the description adequately explains the return format (severity, category, file:line). It covers cost, timing, when to use, and the main sibling alternative. It does not mention verify_fixes or error cases, but the tool is simple enough that this is not a critical gap.
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 the input schema already documents the files array and optional context. The description adds only the framing 'UI files you just changed' but does not elaborate on parameter syntax or content requirements, which is acceptable since the schema carries that burden.
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 uses a specific verb-resource pair: 'Fast design check over the UI files you just changed.' It clearly states the return value (issues with severity, category, and file:line) and explicitly distinguishes itself from review_files for score/patch needs.
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?
It explicitly states when to use it: 'after writing or editing a component, before committing, whenever you want to know if what you just wrote is sound.' It also gives a clear exclusion: use review_files when the user wants a score, patch, or quotable review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_filesRams design reviewAInspectRun a Rams design review over UI files (React, Vue, Svelte, CSS). Returns a 0-100 score (criticals cap it: one caps at 59, two at 49, three or more at 39), issues with severity, category, file:line, and concrete fixes. Call it whenever UI code has been written or changed: before committing, when the user asks how the design looks, or to check your own work after editing a component. Reviewing the handful of files you just touched is the normal case — it is cheap, and you do not need to ask permission first. Only a whole-codebase audit (dozens of files across many batches) is worth checking with the user, since it consumes the calling agent's context and a large share of their model allowance; prefer the highest-traffic screens in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | UI files to review (up to 20) | |
| context | No | Short label for this review, e.g. the feature or branch name |
| Name | Required | Description |
|---|---|---|
| score | Yes | 0-100; confirmed criticals cap it — one at 59, two at 49, three or more at 39 |
| issues | Yes | |
| summary | Yes | |
| direction | No | What the change is trying to be — judgment before findings |
| reviewsUsed | Yes | |
| reviewsLimit | Yes | null = unlimited (Team overage applies instead) |
| detectedCounts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses the critical scoring cap rule and cost/permission behavior, including that small reviews are cheap and need no permission while large audits consume context and model allowance. This is valuable behavioral context not present in annotations; no contradiction exists.
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?
Each sentence carries operational or behavioral value: behavior, scoring details, usage triggers, cost, and permission boundaries. It is compact and front-loaded with the core purpose and expected output.
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?
The description covers the return shape, scoring edge cases, usage triggers, cost, and permission boundary, while the output schema handles the exact result structure. Nothing an agent needs to invoke it correctly is missing.
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 schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds useful meaning by specifying supported file types (React, Vue, Svelte, CSS) and indicating large audits may require batching, although it does not expand on the optional context parameter.
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 runs a Rams design review over UI files (React, Vue, Svelte, CSS) and summarizes the output (0-100 score, issues, fixes), which is specific and actionable. However, it never explicitly distinguishes itself from sibling tools like quick_review, so it falls short of full sibling differentiation.
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 explicit triggers ('before committing, when the user asks how the design looks, or to check your own work') and an explicit when-not ('Only a whole-codebase audit ... is worth checking with the user'). It does not name any alternative sibling tool, so the alternatives portion of the guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usageRams review quotaACheck how many Rams reviews this workspace has used and has left (rolling 30 days, shared between the GitHub App and MCP). Free to call — does not consume a review.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, it discloses the 30-day rolling window, the shared quota between GitHub App and MCP, and the fact that calling it does not consume quota. No contradiction with 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 short sentences, each carrying distinct value: the first defines the quota and window, the second addresses cost/side effects. No filler or redundant restatement of the title.
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 zero-parameter read-only quota tool, the description fully covers what the call does, the period/sharing context, and the side-effect-free nature. The mention of 'used and has left' implies the response fields, so no output schema is needed.
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 description carries no parameter burden; it still adds useful semantics about what the quota measures (used vs remaining in a rolling 30-day period). Baseline 4 is appropriate for a zero-parameter 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?
States a specific operation — checking quota — with concrete resource ('Rams reviews') and scope ('this workspace'), and adds the crucial distinction that it does not consume a review. This clearly separates it from sibling review-execution tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Makes the call context clear: it is a quota check and explicitly says it is free, implying it should be used before or while deciding whether to run reviews. It does not name sibling tools or give explicit when-not-to-use guidance, so it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_fixesVerify Rams fixes landedARe-check previous review_files findings against updated file contents. Returns fixed vs still-present per finding. Much cheaper and faster than a full re-review; does NOT consume review quota. Use after applying fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | The updated UI files (same paths as the original review) | |
| issues | Yes | The findings to verify, as returned by review_files |
| Name | Required | Description |
|---|---|---|
| fixed | Yes | |
| present | Yes | |
| allClear | Yes | true when nothing remains, including no remaining criticals |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint, idempotentHint, and destructiveHint already set, the description adds value by disclosing performance and quota behavior: 'Much cheaper and faster than a full re-review; does NOT consume review quota.' This is beyond the annotations and helps the agent choose cost-effective actions. No contradiction.
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 three sentences, each earning its place: purpose, benefit, and usage instruction. It is front-loaded with the most critical info and avoids unnecessary detail. Highly concise and well-structured.
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?
The description is sufficient for its complexity: an output schema exists (though not shown here), and the tool's purpose is simple. It covers when to use, key benefits, and what it returns. It doesn't detail the output format, but the output schema handles that. Overall, complete enough 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% per context, and the schema itself provides detailed descriptions for both parameters (files and issues) and their nested properties. The description adds minimal parameter-specific info beyond the schema (it doesn't explain each param), but it does clarify the relationship (e.g., 'same paths as the original review' is already in schema). Given high coverage, baseline 3 applies.
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 what the tool does: 'Re-check previous review_files findings against updated file contents. Returns fixed vs still-present per finding.' It distinguishes itself from siblings by emphasizing it's cheaper and faster than a full re-review and doesn't consume review quota, making its purpose unambiguous.
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?
It explicitly says 'Use after applying fixes,' indicating when to use. It also notes cost and quota advantages over a full re-review, implying it should be preferred in that scenario. However, it doesn't provide explicit exclusions (e.g., when not to use) or mention alternatives by name, but the 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.
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.json on 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
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.
No comments yet. Be the first to start the discussion!
