Skip to main content
Glama

Conformance report

generate_conformance_report
Read-only

Pro. Fetch up to 10 public pages, run the static accessibility audit on each, and return a draft Accessibility Conformance Report in the shape of the ITI VPAT 2.5 WCAG edition: a report header (product, version, date, evaluation methods, contact, notes), then a table of every WCAG 2.2 Level A and AA success criterion (55, including 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 and 3.3.8; 4.1.1 Parsing is omitted because it is obsolete in 2.2). Each row has a Conformance Level of exactly Supports, Partially Supports, Does Not Support, Not Applicable or Not Evaluated, plus remarks. Rows are marked Does Not Support or Partially Supports only where the audit found a real issue, citing the page and the count. Rows that do not apply (no media, no forms, no drag or gesture code) are Not Applicable and state what was searched. Rows only a person can judge (keyboard use, focus order, captions quality, images of text) are Not Evaluated with a two-step test. Supports is used where the HTML, stylesheets and same-site scripts show no failure, and the remark states what was and was not checked. The report carries a disclaimer that it is a draft from automated checks and not a legal conformance claim, and a Manual testing still needed section. Pass urls (array, up to 10) or one url; productName, version, vendor, contactEmail and evaluator are optional header fields. Returns an object with report (markdown), criteria ([{criterion, name, level, remarks}]), pages and counts. Do not present the output to a customer as a finished VPAT.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "generate_conformance_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoA single public page URL, instead of urls
urlsNoUp to 10 public page URLs that represent the product (home, a form, a content page, sign-in)
vendorNoCompany that makes the product
versionNoProduct version or release date
evaluatorNoPerson or team who ran the evaluation
productNameNoProduct name for the report header
contactEmailNoContact for accessibility questions

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Well beyond the annotations: it discloses the exact rating vocabulary and the decision rule for each level (Does Not Support only where a real issue was found with page and count; Not Evaluated with a two-step test for human-judgement criteria; N/A states what was searched). It also discloses the disclaimer, the 'Manual testing still needed' section, and the return-object keys, so the agent knows the shape and limits of the output before calling.

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?

Dense but front-loaded: the verb-and-deliverable appears in the first sentence, then detail follows. It is verbose in places (enumerating specific WCAG criteria numbers, the 4.1.1 Parsing aside) and opens with an unexplained 'Pro.' artifact, but nearly every clause carries behavioural information an agent could not infer.

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?

For a complex, open-world tool with no output schema, the description fully compensates: it enumerates the return keys (`report`, `criteria`, `pages`, `counts`), explains the rating semantics, and warns about the legal-weight limitation. Nothing material is left missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 description adds meaning by framing productName, version, vendor, contactEmail and evaluator as 'optional header fields' for the report, and by clarifying that `urls` should represent the product (home, form, content page, sign-in). That is real added semantics over bare schema descriptions.

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 chain and deliverable: fetch up to 10 public pages, run the static accessibility audit, return a draft VPAT 2.5 WCAG-edition conformance report. This is clearly distinguishable from siblings like audit_page_accessibility or audit_site_accessibility, which audit but do not produce a VPAT-shaped artifact.

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 explicit invocation guidance ('Pass `urls` (array, up to 10) or one `url`') and an explicit constraint on the output ('Do not present the output to a customer as a finished VPAT'). It does not name alternative siblings or state when-not-to use it (e.g. single-page auditing vs. full report generation), 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources