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 3 of 3 tools scored.
Each tool has a distinct purpose: review_files runs design reviews, usage checks quota, and verify_fixes re-checks fixes. No overlap or ambiguity between them.
Two tools follow a verb_noun pattern (review_files, verify_fixes), while 'usage' is a single noun. This is a minor deviation but the names are clear and readable.
Three tools is appropriate for the server's focused purpose: review, verify, and usage monitoring. Each tool earns its place and there is no bloat.
The tool set covers the full design review workflow: running a review, verifying fixes, and checking usage. No obvious dead ends or missing operations for the stated domain.
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 valuable behavioral context beyond the neutral annotations, revealing speed ('in about 10 seconds'), cost ('five quick checks cost one review credit'), and that it returns no score or ready-made patch. It implies a read-only operation by saying to fix issues yourself. While it doesn't discuss authorization or side effects, the extra cost and limitation details are useful.
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 appropriately sized, front-loaded with the core purpose, and every sentence adds value—covering intention, output, performance, cost, usage frequency, and exclusions. There is no redundant or empty phrasing, making it efficient 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?
Given no output schema, the description explains the return format ('issues with severity, category and file:line') and clarifies what is not returned (no score, no patch). It also covers cost, speed, and when to use, providing a complete picture for a tool with only two parameters and full schema coverage. Error conditions are not necessary for this simple review 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% for both parameters, so the baseline is 3. The description reinforces the meaning of 'files' as 'UI files you just changed' but does not add details about the 'context' parameter. Since the schema already documents both parameters, the description adds marginal value beyond the structured input.
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 performs a 'Fast design check over the UI files you just changed' and returns 'issues with severity, category and file:line', which specifies the verb, resource, and output format. It explicitly distinguishes itself from review_files by noting it returns no score or patch, making it distinct among siblings.
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 when-to-use guidance: 'Use this one CONSTANTLY' after editing, before committing, and when checking soundness. It also states when not to use it and names the alternative: 'When the user wants a score to keep, a patch to apply, or a review to quote, use review_files instead.' This clearly covers usage context and alternatives.
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?
Annotations are all false, so the description carries the full burden. It discloses scoring caps based on critical issues, the structure of returned issues, and cost/context trade-offs for large audits. It also implies read-only behavior without stating it explicitly, which is acceptable for a review tool.
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-organized: it leads with the purpose, then scoring behavior, then usage guidance. The cost warning is slightly verbose but necessary for agent decision-making. No irrelevant filler.
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's simplicity (2 params, output schema present), the description covers all essential aspects: purpose, output details, when to use, cost implications, and file types. Nothing critical 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 covers both parameters (files and context) with clear descriptions. The description adds useful file-type constraints (React, Vue, Svelte, CSS) and clarifies that context is a short label. This goes beyond the schema's baseline, hence a 4.
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 it runs a Rams design review over UI files, lists supported frameworks (React, Vue, Svelte, CSS), and explains the scoring output. This distinguishes it from sibling tools like verify_fixes and usage.
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 specifies when to use the tool: after UI code changes, before committing, on user request, or for self-checking. It also distinguishes the normal cheap case from a large audit that should require user permission, and even suggests prioritizing high-traffic screens.
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?
The description adds valuable behavioral details beyond the annotations: the 30-day rolling window, shared quota between the GitHub App and MCP, and explicit note that calling does not consume a review. This enriches the agent's understanding of side effects and scope.
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 clearly present the purpose and key constraints without any wasted words. The main action and scope are front-loaded, making it easy to scan.
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, no-parameter tool, the description covers the essential details: what is counted, the time window, shared nature, and the fact that it is free. The absence of an output schema is acceptable because the description clarifies the kind of information returned ('how many used and has left').
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 the description does not need to explain parameter meaning. The schema coverage is trivially 100%, and the baseline for 0-parameter tools is 4, which is appropriate here.
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 action ('Check how many Rams reviews...') with a clear resource (Rams review quota) and scope (this workspace). It stands apart from sibling tools like review_files and verify_fixes, which perform review actions, by being a read-only status check.
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 phrase 'Free to call — does not consume a review' gives clear usage context and assures the agent it can be called without cost. However, it does not explicitly mention when to prefer this over alternatives or list exclusions, so it falls short of a perfect 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 annotations already declaring idempotentHint=true and destructiveHint=false, the description adds valuable context about return format (per-finding status) and cost (does NOT consume review quota). It doesn't contradict annotations, though the readOnlyHint=false remains unexplained since no side effects are 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?
Two sentences, front-loaded with the core function and output in the first sentence, and cost/usage in the second. Every sentence adds value with no redundancy or filler.
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 presence of a full output schema and detailed annotations, the description adequately covers purpose, usage, and cost. It could add a bit more detail about how 'fixed' is determined, but the output schema likely covers return values. It is reasonably complete for the tool's complexity.
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% and both parameters (files, issues) are fully described in the schema with detailed properties. The description only references them conceptually ('findings', 'updated file contents') without adding syntax or additional meaning, so the 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 re-checks previous review_files findings against updated file contents and returns fixed vs still-present status. It uses a specific verb (re-check) and resource (findings and files), fully distinguishing it from sibling review_files which performs the initial review.
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 provided: 'Use after applying fixes' specifies when to invoke it, and 'Much cheaper and faster than a full re-review; does NOT consume review quota' clearly contrasts with the alternative (review_files). This gives clear when/alternative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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!
