Skip to main content
Glama

Rams

by ai.rams.worker
OverviewDiscussionsAdmin

Rams quick check

quick_review

Fast design and accessibility check of UI code (React, Vue, Svelte, HTML, CSS, SwiftUI). Returns the top issues with severity, category and file:line in about 10 seconds. Call it when the user pastes or uploads UI code, asks whether a design is good or accessible, or when you just wrote or changed a component, page or view. You do not need to ask first. Pass each file with its real path, or for pasted code a path that fits it (pasted/Card.tsx, pasted/index.html) and the full code. Five quick checks cost one review credit (two on the free plan). It reads code only, not screenshots or URLs. It returns no score and no patch: fix the issues yourself. For a score or patches, use review_files.

Input Schema

NameRequiredDescriptionDefault
viaNoSet to "rules" when this call is made because of a standing instruction in a rules file (e.g. CLAUDE.md). Omit when a person asked for the review.
filesYesThe UI code, one entry per file (up to 20): the real path, or for pasted code a path that fits it (pasted/Card.tsx), and the full code
contextNoShort label, e.g. the component or feature name

Output Schema

NameRequiredDescriptionDefault
ranYesfalse when the check did not run (hourly limit, no credits left, engine failure) or came back unusable; message says why
issuesYes
messageNoPresent when ran is false: the reason, in words
issueCountYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "issueCount": {
+      "type": "number"
+    },
+    "issues": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "category": {
+            "type": "string"
+          },
+          "file": {
+            "type": "string"
+          },
+          "line": {
+            "type": "number"
+          },
+          "message": {
+            "type": "string"
+          },
+          "severity": {
+            "description": "critical, serious or moderate",
+            "type": "string"
+          }
+        },
+        "required": [
+          "severity",
+          "category",
+          "file",
+          "line",
+          "message"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "description": "Present when ran is false: the reason, in words",
+      "type": "string"
+    },
+    "ran": {
+      "description": "false when the check did not run (hourly limit, no credits left, engine failure) or came back unusable; message says why",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "ran",
+    "issueCount",
+    "issues"
+  ],
+  "type": "object"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / files / description
      Previous value: -"The UI files you just changed"New value: +"The UI code, one entry per file (up to 20): the real path, or for pasted code a path that fits it (pasted/Card.tsx), and the full code"
  3. Changed1 schema field changed
    • addedInput schema / properties / via
      Added value: +{
+  "description": "Set to \"rules\" when this call is made because of a standing instruction in a rules file (e.g. CLAUDE.md). Omit when a person asked for the review.",
+  "type": "string"
+}
  4. Added

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real behavioral context beyond the annotations: ~10 second runtime, credit economics (five quick checks = one review credit, two on free plan), the hard scope limit (reads code only, not screenshots or URLs), and the output shape limit (no score, no patch). The annotations only declare non-readonly/non-idempotent flags, so these details are genuinely additive. It could say more about what happens on oversized input (20-file cap) or failure modes.

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?

Front-loaded with the capability, then triggers, then operational constraints, then the alternative tool — a sound ordering. Sentences are dense but each carries information; only the pasted-path example is redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, triggers, non-triggers, alternatives, latency, cost, input conventions and output limitations. With an output schema present it does not need to explain return values, yet it still summarises them (severity, category, file:line). Nothing needed 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so path, content, context and via are already documented. The description reinforces the pasted-path convention (pasted/Card.tsx, pasted/index.html) but this duplicates the schema's own files description, and it never explains the via='rules' parameter. Baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Fast design and accessibility check of UI code'), names the supported frameworks, and explicitly differentiates itself from the sibling by stating 'For a score or patches, use review_files.' An agent can route between quick_review and review_files without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggering conditions: user pastes/uploads UI code, asks if a design is good/accessible, or you just wrote/changed a component, page or view. It also removes ambiguity about consent ('You do not need to ask first') and names the alternative for the cases this tool does not serve.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Rams toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources