Skip to main content
Glama

Rams review quota

usage
Read-onlyIdempotent

Check 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation3/5

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.

Naming Consistency3/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources