Skip to main content
Glama

verify_complete

Discharge the release contract before shipping. Checks 11 requirements against your finished markup — reduced-motion strategy, viewport, visible focus, 44px touch targets, alt text, form labels, no debug spew, no placeholder copy, the recorded manifest version, that every pattern you claim resolves, and that no heavy runtime downloads on the reduced-motion path — and returns each failure with the exact fix. Then returns the 7 browser-only passes (desktop/mobile render, alignment, visual critique, fast-scroll lifecycle, accessibility audit, cold route) as OUTSTANDING with the command that discharges each. Those are never marked pass: this tool does not run a browser and does not pretend to. FREE, no key required.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "html": "<html>"
    },
    "name": "verify_complete"
  }
}

Input Schema

NameRequiredDescriptionDefault
htmlYesthe finished page's full HTML
slugsNooptional — every pattern slug/number the page uses. Defaults to any data-mm-pattern attributes found in the markup; each is checked against the live catalogue so a typo or a renamed slug is caught here rather than as a 404 in the customer's build.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does well: FREE, no key required, static-only, and it explicitly refuses to mark browser passes as pass. However it does not state whether it mutates anything, what the response shape looks like structurally beyond 'failures plus outstanding', or whether results are deterministic across reruns.

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 gating purpose, then the check inventory, then the outstanding-pass disclosure, then pricing. The 11-requirement run-on is dense but each clause is informative; only mild trimming would be possible without losing expectation-setting detail.

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?

No output schema exists, and the description compensates fully by explaining that failures come back with the exact fix and browser-only passes come back OUTSTANDING with the discharging command. For a two-parameter, non-destructive verification gate, nothing an agent needs to call or interpret it 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 coverage is already 100%, including the fallback behavior for slugs (defaults to data-mm-pattern attributes) and the live-catalogue validation. The description adds the intent ('every pattern you claim resolves', 'recorded manifest version') but nothing about syntax or format beyond the schema, so baseline 3 applies.

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

Purpose4/5

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

States a concrete verb and resource: discharge the release contract by checking 11 named requirements against finished markup. It also draws a clear boundary against browser-running tools by declaring the 7 browser-only passes are returned as OUTSTANDING rather than verified, though it never names a specific sibling tool.

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?

The triggering condition is explicit — run on finished markup before shipping. The boundary ('does not run a browser') implies that render/accessibility checks belong to a different tool, but no sibling is named and there is no explicit when-not-to-use statement pointing the agent at audit_page or critique_page.

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.

Resources