Skip to main content
Glama

How one website is doing overall

site_overview
Read-only

Start here for any accessibility, a11y, WCAG or ADA question about one website whose current state you do not already know — 'how are we doing', 'is this working', 'are we covered', 'should we worry'. It is the cheapest way to learn what has been measured and how much of the site that covers, which every later tool choice depends on. The whole current position for one website in a single call: plan and whether a trial or failed payment is about to change it, the headline accessibility score and when it was measured, how many pages are being checked automatically against how many the plan includes, this month's visitor count against the plan's allowance, whether an accessibility statement is published, whether the widget is switched on, and whether anything is currently stopping scans from running. "coverage" says how much of the site the score describes: monitored pages, the plan's page allowance, and what the last crawl found against what it scanned — a score measured over one page of a site with 82 discovered pages is a fact about those pages, and the unscanned ones are neither passing nor failing. Then use the finding-level tools for detail. Do not use it to list problems: it reports counts, never individual violations. Read-only: costs one read and loads no page, so it is cheap and safe to call first. It reports what is on record: a site that has never been scanned returns no score rather than a good one, and a missing number never means a clean result. Where the score is missing for a reason other than that — a crawl is running and it is withheld until the crawl finishes, or the plan does not include scan data — scoreNote says so, so a null score is never read as "never scanned". It works on every plan, including Free: where the plan does not include scan data the score, the scan and the coverage come back null with scoreNote explaining which kind of missing that is, and the plan, widget state, page allowance and visitor counts are still reported in full.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
websiteYesThe website domain as registered in Inclusify, e.g. "example.com".

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/destructive annotations, the description adds substantial behavioral context: it costs one read, loads no page, reports only what is on record, explains that an unscanned site returns no score rather than a good one, and clarifies that a null score is never equivalent to 'never scanned' because scoreNote explains the reason. This is rich, non-redundant disclosure.

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?

The description is fairly long but front-loads the core purpose and usage guidance, then organizes caveats and plan-specific behavior logically. Some redundancy exists around the Free plan/no-scan-data case, but the length is mostly justified by the need to explain nuanced missing-score semantics and coverage meaning.

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?

Given there is no output schema, the description carries the burden of explaining return values and does so thoroughly: plan, score and timestamp, page counts, visitor counts, statement status, widget state, scan blockers, coverage meaning, and null-handling semantics across plans. An agent has enough information to correctly invoke and interpret the tool.

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% and the sole parameter 'website' is already documented as 'The website domain as registered in Inclusify, e.g. "example.com"'. The tool description does not add further meaning about the parameter itself, so the high-coverage baseline of 3 applies.

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?

The description states a specific verb and resource: it is the starting point for accessibility/a11y/WCAG/ADA questions about one website and gives an overall current-position summary. It clearly differentiates itself from finding-level and detail tools by saying it reports counts and never individual violations.

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

Usage Guidelines5/5

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

It explicitly says 'Start here' for any website whose current state is unknown, calls itself the cheapest way to learn what has been measured, and directs the agent to 'use the finding-level tools for detail' and to avoid using it to list problems. This is strong when-to-use and when-not-to-use guidance.

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.

TDQS

A4.3/5.0
Disambiguation4/5

The descriptions do exceptional cross-referencing work, explicitly separating near-neighbor pairs (add_website vs add_domain, list_alt_findings vs check_page_alt_text, plan_options vs billing_link, widget_status vs widget_usage). A few clusters remain that an agent could confuse without reading carefully, notably site_overview vs compliance_status (both report statement existence and scan-record state) and crawl_summary vs list_monitored_pages vs site_overview (all touch coverage numbers). Overall, distinct purposes are clearly delineated despite the large surface.

Naming Consistency4/5

All names are lowercase snake_case with strong family patterns: list_* (5 tools), add_* (3), set_* (7), plus org_* and *_history pairs. The main inconsistency is the mix of verb-led names (list_violations, set_slack_channel, start_crawl) with noun-led read names (site_overview, compliance_status, widget_usage, next_steps), but the noun-led names follow a coherent 'what it returns' vocabulary (status, summary, history, overview, rollup). Minor deviations rather than chaos.

Tool Count3/5

36 tools is heavy and sits above the 25-tool threshold where agent navigation starts to degrade, but the server covers a genuinely broad domain: website lifecycle, monitoring, four finding types, four live-audit tools, seven config setters, org rollups, billing, and CI. Most tools earn their place and none are duplicates, but several could plausibly be merged (set_slack_channel/set_slack_events/set_monitoring_settings into one notifications tool; list_violations/list_alt_findings/list_content_findings with a filter). The count is on the edge of unwieldy for an agent's tool-selection step.

Completeness3/5

The read/audit/analysis side is rich and well-covered: findings, history, live checks, org rollups, coverage, and validation all have tools. However, the write side is one-directional: add_monitored_pages is explicitly add-only, and there is no remove_website, remove_domain, or remove_monitored_pages, so teardown and 'stop monitoring this page' requests hit dead ends that the descriptions acknowledge belong to the panel. Statement content writing and widget installation are also panel/browser-only by design, which is documented but still leaves those operations outside the agent's reach.