Skip to main content
Glama

OnPage.dev

by dev.onpage
OverviewDiscussionsAdmin

Accessibility

accessibility
Read-onlyIdempotent

Accessibility for people and the European Accessibility Act. Pick with mode: wcag = WCAG 2.1 AA checks. Needs url. screen_reader = The page as a screen reader reads it. Needs url.

Input Schema

NameRequiredDescriptionDefault
urlNoFull address of the page, for example https://example.com/pricing.
modeNoDefault wcag.
treeNoOptional: an accessibility snapshot from your own browser (role, name, level, children), for example Puppeteer page.accessibility.snapshot().
detailNobrief = short summary.
memory_keyNosite_memory key, records this call.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedOutput schema / description
      Removed value: -"The result as structured data; fields depend on mode."
  2. Changed2 schema fields changed
    • changedInput schema / properties / detail / description
      Previous value: -"brief returns a short summary, default full."New value: +"brief = short summary."
    • changedInput schema / properties / memory_key / description
      Previous value: -"Optional site_memory key, to record this call in the site memory."New value: +"site_memory key, records this call."
  3. Changed1 schema field changed
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "brief returns a short summary, default full.",
+  "enum": [
+    "full",
+    "brief"
+  ],
+  "type": "string"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / memory_key
      Added value: +{
+  "description": "Optional site_memory key, to record this call in the site memory.",
+  "maxLength": 80,
+  "type": "string"
+}
  5. Added

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds that the tool requires a url and that each mode produces a distinct kind of output, which is useful context but not rich behavioral disclosure (no scope, cost, or failure behavior).

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?

Five short sentences, zero padding, and the core purpose plus the mode-keyed requirements are front-loaded. The telegraphic style ("Needs url.") is efficient, though slightly choppy.

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?

An output schema exists and the input schema is fully documented, so return values and param details needn't be re-explained. The description covers the mode split and the url precondition, which is enough for an agent to call the tool correctly, though it omits guidance on the tree/detail parameters.

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 schema already documents url, mode, tree, detail, and memory_key. The description restates the mode enum values and the url requirement without adding syntax or format detail beyond the schema. Baseline 3 is appropriate.

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?

The description states a concrete capability (accessibility checking) and names its two concrete outputs, WCAG 2.1 AA checks and screen-reader rendering. It doesn't compare itself to siblings like scan_page, but the purpose is unambiguous without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives real selection guidance for the mode parameter (wcag vs screen_reader) and a precondition ("Needs url"). However, it never says when to reach for this tool versus alternatives such as scan_page or technical, so usage is implied rather than framed.

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

All OnPage.dev toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources