A real browser for AI agents: screenshots, PDFs, post-JS HTML. 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?
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.
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.
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.
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.
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.
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.
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?
No annotations exist, so the description carries the full burden and largely meets it: it discloses the return content (box model, display/visibility/opacity/position/z-index, colours, viewport check, covering-element detection) and the nature of the computation (post-cascade and layout values). It does not explicitly note error behavior or confirm the operation is non-destructive, though 'inspect' strongly implies read-only. Rich behavioral context for a tool with zero annotation coverage.
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 sentences in a tight structure: the diagnostic question leads, the return inventory follows, and the value proposition closes. The second sentence's list is informative rather than padding. Every sentence earns its place with zero repetition of schema content, and the purpose is front-loaded.
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 tool with no output schema and no annotations, the description compensates well by spelling out exactly what is returned and framing it as live browser-computed data. Minor gaps remain — no explicit handling of invalid selectors, page-load failures, or whether results reflect a freshly loaded page — but these are edge conditions, not core call requirements. The agent has enough to invoke and interpret 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 coverage is 100%, so the baseline is 3: the schema already fully documents all five parameters including defaults, ranges, formats, and examples. The description adds only indirect semantic context (selector targets a live-page element; url implies a loaded page), nothing beyond what the schema provides. No compensation needed, but also no added meaning.
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 concrete diagnostic question ('why isn't this element showing where I expect?') tied to a specific resource (a CSS selector on a live page). It clearly distinguishes itself from siblings like rendered_html and screenshot_url by emphasizing it returns browser-computed layout values, not static markup or images. A single specific verb-context pair that an agent could not confuse with any sibling.
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 closing sentence ('they cannot be derived from reading HTML and CSS') gives implied guidance about when to pick this tool over a markup-reading sibling, but it never names an alternative or states explicit when/when-not conditions. Context is suggested rather than stated, and there are no exclusions or sibling references, leaving the agent to infer the choice.
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?
With no annotations present, the description carries the full behavioral burden and mostly succeeds: it discloses that this uses a real browser and states exactly what diagnostics are captured. Minor gaps remain, such as not clarifying that warnings are only reported when include_warnings is true, and not mentioning potential timeouts or side effects of loading a live page.
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 sentences: the behavior is front-loaded, usage guidance follows, and the unique value closes. There is no filler, no repetition of schema details, and every sentence justifies its place.
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 report contents are enumerated (console, network, HTTP status) even though there is no output schema, and the trigger conditions are clear. It does not describe the exact output format or failure behavior, but for a diagnostic tool the description is sufficient for an agent to decide when to call it and what to expect.
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 coverage is 100%, so the schema already documents url, width, height, and include_warnings with defaults and constraints. The tool description does not add parameter-level detail, but with full schema coverage the baseline of 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 names a specific verb and resource: 'Load a page in a real browser and report what went wrong,' followed by concrete outputs: JS console errors/warnings, failed network requests, and page HTTP status. This differentiates it from siblings like screenshot_url and rendered_html, which focus on visual or DOM output rather than browser 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?
It gives explicit trigger scenarios: 'when a site looks broken, a deployment might have shipped a bug, or a page loads blank.' It also states why the tool is uniquely necessary: 'An agent cannot see a browser's console any other way.' It does not explicitly name alternative tools or exclusion cases, so it stops short of a 5.
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?
With no annotations provided, the description carries the full burden of disclosure. It clearly explains that the tool runs JavaScript and returns the final DOM as HTML text, which is important behavioral context. It does not mention timeouts, failure modes, or resource cost, 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?
Two well-structured sentences with no wasted words. The key differentiator, JavaScript execution and final DOM, is front-loaded, followed by concrete use cases and return type.
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 three-parameter tool with no annotations and no output schema, the description gives enough context about when to use it and what it returns. It could mention limitations or failure behavior, but an agent can correctly select and invoke the tool based on the information provided.
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%, and each parameter already has a useful description in the schema. The main description does not add parameter-level details, so the baseline score of 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?
States a specific verb and resource: fetch a page's HTML after JavaScript has executed. The emphasis on executing JS and returning the final DOM clearly distinguishes it from the sibling tools screenshot_url and url_to_pdf, which produce visual or PDF output rather than HTML text.
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?
Provides explicit usage context: use when a plain HTTP fetch returns an empty shell or loading spinner, especially for single-page apps or client-side rendered sites. It does not explicitly mention when not to use it or name the sibling tools, but the conditions are clear enough.
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?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states the operation is a screenshot with real-browser rendering and returns a PNG image, which is useful. However, it does not disclose potential side effects (e.g., it's a read-only action), rate limits, or failures (e.g., page not loading).
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 sentences, each earning its place: what it does, when to use it, and what it returns. It is front-loaded with the primary action and scoped with use-case examples. No wasted words.
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 is complete for selecting and invoking the tool: it explains behavior, return type, and typical use cases. It lacks explicit error handling or edge cases, but given the straightforward parameter set and no output schema, this is a minor gap.
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% coverage with detailed descriptions for all four parameters (url, width, height, full_page). The description does not add new semantic meaning beyond the schema, but since schema coverage is high, a baseline of 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 uses the specific verb 'Take a screenshot' with a clear resource ('a web page as it actually renders in a real browser, after JavaScript has run'), and unlike siblings (rendered_html, url_to_pdf), it explicitly focuses on visual rendering and returns a PNG. This differentiates it from alternatives without needing to inspect them.
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 provides clear context: 'when you need to see a page rather than read it' and gives concrete use cases (checking a layout, confirming a site is up, capturing what a user would see). It does not explicitly mention when not to use it or alternatives, but the context is strong enough for an agent to decide.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention the output format ('Returns a PDF file') and the browser-print behavior, but it omits potential caveats such as rendering timeouts, JavaScript dependency, or authentication requirements. This is adequate but not rich.
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 concise and well-organized in three sentences: it states the core action, lists usage scenarios, and closes with the return type. Every sentence earns its place with no redundant fluff.
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 straightforward rendering tool, the description covers the main purpose and output, but without annotations or an output schema it lacks detail on failure modes, limitations, or operational requirements. It is minimally adequate but leaves gaps an agent might need when handling edge cases.
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 provides full coverage (100%) for both parameters, including descriptions for url and landscape with defaults. The tool description adds no extra parameter-level detail, which is acceptable given the schema already documents everything. Thus, a baseline score of 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 clearly specifies the action ('Render a web page to PDF') and distinguishes it from sibling tools by emphasizing browser-accurate printing. It also lists concrete use cases (archive, document from rendered report, record), making the tool's purpose unmistakable.
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 provides clear contexts for use (archiving, producing documents, capturing records) and implies a distinction from screenshot_url and rendered_html through the phrase 'as a browser would print it.' However, it does not explicitly state when not to use this tool or name the alternatives, 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.
Claiming 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 or an account that owns the GitHub organization, then choose Claim with GitHub.
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!
Headless browser primitives for AI agents when sites need real JS rendering.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
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 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.
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.
Five tools cover the core browser-rendering use cases without redundancy or bloat. Each tool earns its place in the set.
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.
