Rams is a design reviewer for UI code. The MCP server puts the hosted engine inside a coding agent: the agent passes files to the review_files tool and gets back a 0–100 score with file:line issues and concrete fixes — accessibility, color, typography, spacing, components, UX, motion, craft, and native SwiftUI. Same engine and scoring as the Rams GitHub App. 258 rules, published at rams.ai/rules. Free tier: 30 reviews/month.
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.6/5 across 4 of 4 tools scored.
The four tools are largely distinct: quick_review and review_files both review UI, but are clearly differentiated by depth/return (no score vs score+patch) and cost; usage and verify_fixes are distinct. Slight overlap between quick_review and review_files could cause selection confusion if an agent misreads their purposes, but descriptions are strong.
All names use a snake_case verb_noun pattern (quick_review, review_files, usage, verify_fixes). The verbs 'quick' and 'verify' are adjectival/modifying, but the pattern is consistent and predictable, with only 'usage' being a bare noun rather than verb_noun.
At four tools, the set is tightly scoped for a UI design review server. Each tool addresses a distinct step: quick check, deep review, quota status, and fix verification. No redundancy or bloat; the count is appropriate for the purpose.
The server covers the core review lifecycle: detect issues (quick_review), detailed review with score (review_files), check usage (usage), and verify fixes (verify_fixes). A minor gap is no explicit tool for bulk codebase audits or historical reports, but the primary workflow is complete and no dead ends exist.
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 discloses behavior beyond annotations: latency (~10 seconds), cost (five checks per credit), what is returned (issues with severity, category, file:line), what is not returned (no score, no ready-made patch), and the expectation that the user fixes issues themselves. These details are not present in the annotations, which only provide abstract hints, so they add meaningful behavioral context.
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 dense but every sentence earns its place: speed, cost, when to use, when not to use, what it returns, how to use it. It is front-loaded with the core purpose and immediately gives actionable summary, and no filler or redundant restating of the tool's name.
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 fully describes the return values and expected handling, including issue format, latency, cost, and the follow-up action of fixing issues in open files. It also references the alternative tool for richer reviews and notes permission to use it freely, making the context complete for an agent.
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 covers parameter descriptions 100%, including the file content and path. The description adds semantic intent by emphasizing these are the 'UI files you just changed', which clarifies the tool's target domain beyond the schema's generic 'file path' wording. It does not go deeper into context usage, but the schema already provides sufficient details.
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 identifies the tool as a fast design check over UI files and distinguishes it from the alternative review_files by specifying this one returns no score and no patch. It states a specific verb ('check'), a resource ('UI files you just changed'), and the key output (issues with severity, category, file:line).
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?
Explicit guidance is given on when to use this tool constantly: after writing/editing a component, before committing, and whenever you want to know if your code is sound. It also states when to avoid it and use review_files instead (when a score, patch, or quotable review is needed), and clarifies that asking the user is not required.
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?
The description discloses important behaviors beyond the annotations: the 0-100 score with critical caps (59/49/39), the output structure (issues with severity, category, file:line, fixes), and the consumption of the calling agent's context and model allowance. It also states that normal-case reviews are cheap. The annotations are all false and provide no behavioral hints, so the description carries the burden and does so well. It doesn't explicitly address the readOnlyHint=false, leaving a slight ambiguity about potential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, leading with the core purpose, then the scoring output, then usage guidance. Every sentence carries useful information, but it is longer than strictly necessary. It also clearly front-loads the most critical facts an agent needs for selection.
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 complex tool that already has an output schema (not shown here), the description covers the essential contextual information: when to use, when to ask for permission, cost implications, file scope, and the meaning of the output score. There is nothing an agent needs in order to decide whether to call this tool that 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 (files and context) with 100% coverage, so the baseline is 3. The description adds value by specifying supported file types (React, Vue, Svelte, CSS) and clarifying that 'handful of files' is the normal case, which informs how the agent should populate the 'files' parameter. It doesn't delve into the 'context' parameter, but the schema covers that.
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 'Run a Rams design review over UI files' and lists supported types (React, Vue, Svelte, CSS). This is a specific verb and resource, distinctly different from sibling tools like quick_review or usage. An agent can immediately understand what the tool does and when it applies.
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 provides explicit usage guidance: 'Call it whenever UI code has been written or changed' and gives specific scenarios (before committing, when asked about design, after editing). It also defines when to ask the user: 'Only a whole-codebase audit... is worth checking with the user'. It mentions cost and file-count norms. However, it does not explicitly name alternatives, so it stops short of a 5.
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?
Annotations already declare readOnly/idiempotent/non-destructive, and the description adds valuable behavioral context: rolling 30-day window, quota shared between GitHub App and MCP, and the fact that calling it does not consume a review. This goes well beyond the annotations and informs agent-side decision-making.
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 deliver the essential information with the main purpose front-loaded. The second sentence adds two useful behavioral details without bloat.
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 check with no output schema, the description fully covers what an agent needs: the metric, the time window, the shared nature, and the non-consumption guarantee. Nothing important 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 tool has zero parameters, so there is nothing for the description to explain at the parameter level. The description still clarifies what the quota represents and its scope, which is appropriate for a parameterless tool.
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 states a specific verb ('Check') and a specific resource ('how many Rams reviews this workspace has used and has left'). It clearly differentiates this from the sibling review-execution tools by framing it as a quota query rather than an 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?
The description implies when to use this tool: to inspect the shared rolling 30-day quota before or while performing reviews. It explicitly notes 'Free to call — does not consume a review,' which helps an agent choose this over review tools. It does not explicitly name alternatives or say 'use this instead of X,' but the context is clear.
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?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context by noting it does not consume review quota and that it returns per-finding status. This goes beyond what annotations provide, though it doesn't detail any edge cases or limitations beyond the schema's max items.
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 two sentences: the first states the purpose and output, the second gives usage guidance and cost/impact. It is front-loaded and every sentence earns its place with zero redundancy.
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 an output schema present and both parameters documented, the description covers the tool's purpose, usage timing, and key behavioral trait (no quota). It is complete for a simple verification tool with clear prerequisites.
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?
Both parameters are fully described in the schema (coverage 100%), so the description adds little extra meaning. It clarifies that 'issues' come from review_files, which is a useful hint, but that is inferable from the tool's context. The baseline of 3 is appropriate when schema does the heavy lifting.
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 states a specific verb ('Re-check') and resource ('previous review_files findings against updated file contents'), and clearly distinguishes it from the siblings by contrasting with a 'full re-review'. It also indicates the output ('Returns fixed vs still-present per finding'), making the purpose unmistakable.
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 after applying fixes', providing a clear when-to-use condition. It also frames the tool as 'cheaper and faster than a full re-review' and notes it 'does NOT consume review quota', which implies when it is preferred. However, it does not explicitly state when not to use it (e.g., for initial reviews), so it falls short of a 5.
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!
