Rams

Rams page review

review_url

Review a live public web page by its URL, no code needed. Rams opens the page at desktop (1440px) and phone (390px) widths, measures the rendered page and looks at both screenshots, then returns the top design issues (severity, category, where on the page, and a fix in plain words) with a 0-100 score. Use it when the user names a site or a page: "review rams.ai with Rams", "how does my landing page look?". It takes up to a minute and uses one review credit. Public pages only: no sign-in pages, localhost or private addresses. It returns no code patches. If the user has the code for the page, use quick_review or review_files on those files instead.

Input Schema

Name	Required	Description	Default
`url`	Yes	The page to review, e.g. https://rams.ai or rams.ai/pricing
`focus`	No	Optional: what to put first, e.g. "mobile", "typography", "color"

Output Schema

Name	Required	Description
`host`	Yes	The page that was reviewed (host only)
`score`	Yes	0-100, what a designer sees in the two screenshots; one critical caps it at 59
`scores`	Yes
`summary`	Yes
`findings`	Yes	Every finding, most severe first (the text shows the top 8)
`reviewsUsed`	Yes
`reviewsLimit`	Yes	null = unlimited
`detectedCounts`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "detectedCounts": {
+      "additionalProperties": true,
+      "properties": {
+        "critical": {
+          "type": "number"
+        },
+        "moderate": {
+          "type": "number"
+        },
+        "serious": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "critical",
+        "serious",
+        "moderate"
+      ],
+      "type": "object"
+    },
+    "findings": {
+      "description": "Every finding, most severe first (the text shows the top 8)",
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "category": {
+            "type": "string"
+          },
+          "fix": {
+            "type": "string"
+          },
+          "instances": {
+            "type": "number"
+          },
+          "measured": {
+            "description": "true = measured on the rendered page, false = seen in the screenshot",
+            "type": "boolean"
+          },
+          "message": {
+            "type": "string"
+          },
+          "severity": {
+            "description": "critical, serious or moderate",
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "viewport": {
+            "description": "desktop or phone",
+            "type": "string"
+          },
+          "where": {
+            "description": "The element, when one element owns the finding",
+            "type": "string"
+          }
+        },
+        "required": [
+          "severity",
+          "category",
+          "viewport",
+          "measured",
+          "title",
+          "message",
+          "instances"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "host": {
+      "description": "The page that was reviewed (host only)",
+      "type": "string"
+    },
+    "reviewsLimit": {
+      "description": "null = unlimited",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "reviewsUsed": {
+      "type": "number"
+    },
+    "score": {
+      "description": "0-100, what a designer sees in the two screenshots; one critical caps it at 59",
+      "type": "number"
+    },
+    "scores": {
+      "additionalProperties": true,
+      "properties": {
+        "desktop": {
+          "type": "number"
+        },
+        "phone": {
+          "type": "number"
+        }
+      },
+      "type": "object"
+    },
+    "summary": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "host",
+    "score",
+    "scores",
+    "summary",
+    "detectedCounts",
+    "findings",
+    "reviewsUsed",
+    "reviewsLimit"
+  ],
+  "type": "object"
+}

AddedOct 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) by disclosing the cost and latency model ("takes up to a minute and uses one review credit"), the exact rendering widths, the public-pages-only auth constraint, and the negative guarantee that it returns no code patches. These are exactly the operational facts an agent needs before invoking.

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?

Front-loads the core action before cost, constraints, and the sibling routing rule, and every sentence carries a distinct fact (viewport widths, output shape, timing, credit cost, eligibility limits, alternative tool). The only mild redundancy is "no code needed" vs "returns no code patches," which reinforces rather than wastes.

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?

For a two-parameter open-world tool with an output schema already present, the description still covers latency, credit consumption, viewport behavior, eligibility restrictions, and the fallback tool. An agent can decide whether to call it, what it will cost, and what it will return without further 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 description coverage is 100%, so both parameters are already documented in structured data, and the description adds only indirect meaning (the page must be public, rendered at two widths) without explaining the url format or focus precedence beyond what the schema states. Baseline 3 is appropriate when the schema carries the load.

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 ("Review a live public web page by its URL") plus the exact mechanism (desktop 1440px and phone 390px, screenshot + measurement, severity/category/location/fix, 0-100 score). It also distinguishes itself from the sibling reviewed tools by naming quick_review and review_files as the code-based alternatives.

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?

Explicit when-to-use trigger ("Use it when the user names a site or a page") with quoted user utterances, explicit exclusions (no sign-in pages, localhost or private addresses), and a concrete alternative path (if the user has the code, use quick_review or review_files). Nothing material is left to inference.

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

All Rams tools Inspect

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

Need Help?