Skip to main content
Glama

render-mcp

by io.github.RodRomer

accessibility_audit

Run a WCAG accessibility audit on a page using axe-core in a real browser, and report the violations with the elements responsible. Because it runs against a genuinely rendered page, colour-contrast and other rules that depend on layout and computed colour actually fire — these are silently skipped by audits that parse HTML without a layout engine. Use this to check a page meets WCAG before shipping.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe absolute URL to audit, including https://
standardNoWhich ruleset to run. 'wcag2aa' is the usual legal benchmark but is a narrow filter — it excludes best-practice checks such as landmarks and heading order, so a page can return zero violations and still have real problems. Use 'all' when the question is "is this page accessible?" rather than "does it meet WCAG AA?". Defaults to wcag2aa.wcag2aa
max_violationsNoMaximum violation types to report in detail. 1-50. Defaults to 20.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and it does disclose key behavior: it really renders the page, uses axe-core, and reports responsible elements, and it contrasts with layout-less audits. It does not mention operational side effects like network loads, browser overhead, or auth context, but the core behavioral trait likely to affect results is stated clearly.

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?

Three sentences, front-loaded with the main action, then the key rationale, then the use case. No filler or repetition of schema contents.

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

Completeness4/5

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

Given no output schema and no annotations, the description communicates the return shape (violations plus responsible elements) and the main differentiator. It could add constraints like URL reachability or page-load limits, but the information needed to select and invoke the tool is substantially present.

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 the baseline is 3 and the description need not repeat parameter details. The description adds no extra parameter-level semantics beyond the schema, and the schema already documents url, standard, and max_violations.

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 ('Run'), resource ('a page'), method ('axe-core in a real browser'), output (violations with elements), and standard (WCAG). It also positions itself against non-rendering audit alternatives, making it easily distinguishable from page diagnostics/screenshot siblings.

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?

Gives an explicit trigger ('check a page meets WCAG before shipping') and explains why the live-rendering approach is needed for color-contrast/layout rules. It does not name specific sibling tools or state when NOT to use it, so it falls just short of full guidance.

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

All render-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct output or purpose: audit, diagnostics, rendered HTML, screenshot, and PDF. Even the two diagnostic tools are clearly separated by what they check, so an agent is unlikely to confuse them.

Naming Consistency4/5

All names use snake_case and are descriptive, but they do not follow a single regular pattern: most are noun phrases, while url_to_pdf uses a different structure. The inconsistency is minor and does not hurt readability.

Tool Count5/5

Five tools cover the core browser-rendering use cases without redundancy or bloat. Each tool earns its place in the set.

Completeness5/5

The set covers the obvious needs of a render-focused server: accessibility checking, failure diagnostics, post-JavaScript HTML, visual capture, and PDF output. There are no glaring dead ends for typical page-inspection workflows.

Resources