Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The absolute URL to audit, including https:// | |
| standard | No | Which 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_violations | No | Maximum violation types to report in detail. 1-50. Defaults to 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains a nontrivial behavioral trait: because it runs in a real browser, layout-dependent rules like colour-contrast actually fire, while static HTML audits silently skip them. This goes beyond the readOnlyHint annotation and meaningfully informs expectations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences: what it does, why it is unique, and when to use it. The standard parameter description also earns its length by preventing a common misuse (treating WCAG AA zero violations as full accessibility). No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a 3-parameter schema, full schema coverage, and readOnly/openWorld annotations, the description covers the essential invocation details and expected output ('violations with the elements responsible'). The absence of an output schema is mitigated by this explicit outcome statement, and no critical guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds extra semantic value by explaining why the rendered-browser context matters and clarifying that the 'standard' parameter is a narrow filter that excludes best-practice checks. This pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Run a WCAG accessibility audit'), a specific resource ('a page'), the engine (axe-core), and the output ('violations with the elements responsible'). The mention of a real rendered browser distinguishes it clearly from sibling tools like rendered_html or screenshot_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to check a page meets WCAG before shipping.' It also provides parameter-level guidance, such as using 'all' when asking 'is this page accessible?' rather than 'does it meet WCAG AA?'. This gives an agent strong direction on when and how to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer 'why isn't this element showing where I expect?' for a CSS selector on a live page. Returns the resolved box model, computed display/visibility/opacity/position/z-index, colours, whether the element is inside the viewport, and — crucially — whether another element is covering it. These are the values a browser computes after the full cascade and layout; they cannot be derived from reading HTML and CSS.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The absolute URL to load, including https:// | |
| width | No | Viewport width in pixels. 320-2560. Defaults to 1280. | |
| height | No | Viewport height in pixels. 240-2000. Defaults to 800. | |
| selector | Yes | CSS selector for the element to inspect, for example '.buy-button' or '#header nav a' | |
| max_matches | No | How many matching elements to report. 1-10. Defaults to 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already declaring non-destructiveness, the description adds substantial behavioral context: it actually runs a browser, applies the full cascade and layout, and computes visibility-related values including overlapping elements. This goes well beyond the annotations and explains why the tool exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences carry a clear purpose and a detailed list of outputs. Nothing is wasted, and the most important use case is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's output and why it is useful, and the schema covers parameters. It does not describe edge cases like selector-not-found or page-load failures, but for an inspection tool with this level of schema coverage it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents url, width, height, selector, and max_matches. The description does not add new parameter-level semantics beyond framing selector inspection and live-page context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific diagnostic question and names the exact resource (a CSS selector on a live page). It lists concrete computed outputs such as box model, display/visibility/opacity, and occlusion, clearly distinguishing inspection of rendered results from static source reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The question framing gives clear guidance on when to use this tool: when an element is not appearing where expected. It does not explicitly name sibling tools as alternatives, but it implies the right context by emphasizing computed browser values that cannot be derived from HTML/CSS alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a page in a real browser and report what went wrong: JavaScript console errors and warnings, network requests that failed, and the HTTP status of the page itself. Use this when a site looks broken, a deployment might have shipped a bug, or a page loads blank and you need to know why. An agent cannot see a browser's console any other way.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The absolute URL to load, including https:// | |
| width | No | Viewport width in pixels. 320-2560. Defaults to 1280. | |
| height | No | Viewport height in pixels. 240-2000. Defaults to 800. | |
| include_warnings | No | Include console warnings and info messages, not just errors. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and open-world behavior. The description adds that it runs a real browser and reports specific diagnostic categories, which is useful context. It could disclose more about timeouts, auth-dependent pages, or result format, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and front-loaded: what it does, when to use it, and why it is uniquely valuable. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description enumerates the report contents well enough for an agent to know what will be returned. Missing details like response format, timeouts, or page-load edge cases are minor given the tool's clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters with defaults and ranges. The description adds no param-specific meaning beyond mentioning console warnings, which is slightly ambiguous since include_warnings defaults to false, but the schema resolves this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: load a page in a real browser and report console errors/warnings, failed network requests, and HTTP status. It clearly distinguishes this tool from siblings like screenshot_url or rendered_html by focusing on failure diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit use cases: a site looks broken, a deployment may have shipped a bug, or a page loads blank. It does not name sibling tools or provide when-not-to-use guidance, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a page's HTML after JavaScript has executed. Use this when a plain HTTP fetch returns an empty shell or a loading spinner — single-page apps, sites that build their content client-side, or anything behind a framework. Returns the final DOM as HTML text.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The absolute URL to load, including https:// | |
| wait_for | No | Optional CSS selector to wait for before capturing, for pages that load content late. | |
| max_chars | No | Truncate the returned HTML to this many characters. Defaults to 100000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
ReadOnlyHint and openWorldHint already signal that this is a safe, externally-bound read operation. The description adds meaningful behavioral context beyond annotations: it executes JavaScript, waits for rendering, and returns the final DOM as HTML text. This helps the agent understand that it is a browser-like operation, not a simple HTTP fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler. It front-loads the core purpose, immediately gives practical usage guidance, and closes with the output format. Every sentence serves a distinct, useful purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only fetch tool with a fully documented parameter schema, the description covers the essential context: what the tool does, when to use it, and what it returns. With readOnlyHint and openWorldHint present, plus rich schema descriptions for all parameters, nothing critical is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (url, wait_for, max_chars) are fully documented in the schema. The description does not add extra parameter-level detail, but it does provide useful context in the form of 'after JavaScript has executed' that implies why wait_for might be relevant. This meets the baseline for schema-heavy coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and a clear resource ('a page's HTML after JavaScript has executed'), and distinguishes this from a plain HTTP fetch. It also states the output ('final DOM as HTML text'), making the tool's purpose unmistakable and distinct from sibling tools like screenshot_url or inspect_element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: when a plain HTTP fetch returns an empty shell or loading spinner, such as with SPAs or client-side rendered sites. It clearly identifies the alternative scenario, though it does not explicitly name sibling tools or state when not to use this tool in favor of them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of a web page as it actually renders in a real browser, after JavaScript has run. Use this when you need to see a page rather than read it — checking a layout, confirming a site is up and looks right, or capturing what a user would actually see. Returns a PNG image.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The absolute URL to capture, including https:// | |
| width | No | Viewport width in pixels. 320-2560. Defaults to 1280. | |
| height | No | Viewport height in pixels. 240-2000. Defaults to 800. | |
| full_page | No | Capture the entire scrollable page rather than just the viewport. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnly, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it captures the page as a real browser renders it after JavaScript execution, and it states the return format is a PNG image. This gives the agent important expectations about fidelity and output without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, then usage guidance, then return type. Every sentence earns its place and there is no redundant filler. It is concise without sacrificing the key differentiating information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the readOnly annotation and fully documented schema, gives an agent enough to select and invoke the tool correctly. It covers output type, rendering behavior, and common use cases. A small gap is the lack of constraints about external resource loading or timeouts, but these are not critical for the tool's primary purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully documented in the input schema with descriptions, ranges, and defaults, so the schema carries the semantic load. The description itself adds no new parameter-specific meaning. Per the baseline for high schema coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Take a screenshot of a web page' as it renders after JavaScript runs. This clearly differentiates it from reading HTML or extracting text, and the PNG return type distinguishes it from PDF-focused siblings. The purpose is immediately evident and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: checking a layout, confirming a site is up and looks right, or capturing what a user would actually see. It frames the tool as for 'seeing a page rather than reading it,' which provides clear context. It does not explicitly name when-not-to-use alternatives, but the guidance is strong enough to route an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a web page to PDF exactly as a browser would print it. Use this to archive a page, produce a document from a rendered report, or capture something for a record. Returns a PDF file.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The absolute URL to render, including https:// | |
| landscape | No | Landscape orientation. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context beyond the annotations by stating that rendering matches browser print behavior and that the result is a PDF file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences deliver the function, use cases, and output type without wasted words. The core behavior is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter, read-only tool with fully described parameters and clear annotations, the description is complete enough. It gives the agent the purpose, output type, and appropriate use cases, and no critical missing information is apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: the url parameter is explained and landscape has a clear default and description. The tool description does not add parameter-level meaning beyond the schema, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific: it names the verb 'render', the resource 'web page', and the output 'PDF', and clarifies that it behaves exactly as a browser would when printing. This clearly differentiates it from sibling tools like screenshot_url or rendered_html, which produce different output formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: archiving a page, producing a document from a rendered report, or capturing something for a record. It does not explicitly contrast this tool with alternatives like screenshot_url, but the stated contexts are clear enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
accessibility_auditinspect_elementpage_diagnosticsrendered_htmlscreenshot_urlurl_to_pdfClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Browser-based QA for AI-built software. Test pages with real browsers via agents.
Headless browser primitives for AI agents when sites need real JS rendering.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct concern: accessibility violations, computed layout, console/network errors, post-JS HTML, screenshots, and PDF output. There is no realistic overlap where an agent would be unsure which tool to call.
All names are lowercase snake_case and readable, but the pattern is mixed: inspect_element and screenshot_url are imperative, while accessibility_audit, page_diagnostics, rendered_html, and url_to_pdf are noun-like or descriptive phrases. A uniform verb_noun style would make the set more predictable.
Six tools is a well-scoped count for a render/inspection server. Each tool covers a meaningful, non-redundant capability without bloating the surface.
The set covers the core rendered-page workflows: getting content, seeing it, printing it, auditing accessibility, inspecting layout, and diagnosing errors. A minor gap is the lack of interaction or script execution tools, but for the stated rendering/diagnostics purpose the coverage is strong.
