Check PDFs against PDF/UA-1 with veraPDF; see which failures an automatic fix removes; explain rules
Scored across 2 tools
The two tools operate on entirely different inputs: check_pdf_accessibility takes a PDF (url or base64) and returns validation results, while explain_pdfua_rule takes a rule id string and returns an explanation. There is no plausible way to confuse one for the other, and the check tool's description even points to the rule ids the explain tool consumes.
Both names follow a clean verb_noun snake_case pattern (check_pdf_accessibility, explain_pdfua_rule) with the shared domain prefix clearly embedded. No mixing of camelCase, casing, or verb styles.
Two tools is thin by the usual 3-15 guideline, though the server's stated purpose (validate one PDF, explain one rule) is genuinely narrow. It could reasonably have added a rule-listing or fixed-file retrieval tool, so the surface feels under-built rather than elegantly minimal.
The check + explain pair covers the diagnostic loop, but the server advertises a 'measured auto-fix' and explicitly does not return the fixed file, leaving the core remediation workflow as a dead end. Rule enumeration and any way to actually obtain or apply the repaired PDF are missing.
Validate a PDF against PDF/UA-1 with veraPDF and list every failed rule (rule id, description, number of failed checks, link to a plain-language explanation). The automatic fix is then run on the file and validated again, so the result also says which failures the fix removes and whether the file then passes — measured on this file, not estimated. Give either 'url' (a public http(s) address of the PDF, max 10 MB) or 'pdf_base64'. The file is not stored and the fixed file is not returned here.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public http(s) URL of the PDF (max 10 MB). | |
| language | No | Document language the fix sets when the PDF declares none (BCP 47, e.g. en-US, de-DE, fr-FR). Default en-US. | |
| pdf_base64 | No | The PDF file encoded as base64, if it is not online (max 10 MB decoded). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint already declared, the description still adds substantive context: the automatic fix is run and re-validated on this file, results are measured rather than estimated, the file is not stored, and the fixed file is not returned. The 10 MB limit and public-URL constraint are also disclosed, so the agent understands side effects and limits beyond the 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 key behavior — validation plus automatic fix re-check — is front-loaded in the first two sentences, followed by input and storage constraints. Dense but every clause carries information; slightly long but 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, yet the description fully describes what comes back: every failed rule with id, description, count and link, plus which failures the fix removes and whether the file then passes. Input constraints and storage behavior are also covered, leaving nothing an agent needs 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 coverage is 100%, so all three parameters are already documented. The description restates the url/pdf_base64 choice and size cap but adds no new syntax or format detail beyond the schema, so the baseline of 3 applies.
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 ('Validate a PDF against PDF/UA-1 with veraPDF') and enumerates the output shape (rule id, description, failed check count, explanation link). It is clearly distinguishable from the sibling explain_pdfua_rule, which explains rules rather than validating a file.
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 input-selection guidance: 'Give either url ... or pdf_base64', which tells the agent exactly how to invoke it. It does not, however, mention when to prefer the sibling explain_pdfua_rule for rule details, so there is no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a veraPDF PDF/UA-1 rule by id (clause-test, e.g. 7.1-3, 7.3-1, 7.18.5-1, 7.21.4.1-1): what it checks, the veraPDF error message, whether the automatic fix removes it and how to fix it in the authoring tool.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | Yes | Rule id, e.g. 7.1-3 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the shape of the answer, including whether the automatic fix removes the failure and how to remediate in the authoring tool — exactly the facts an agent needs before deciding to call it.
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?
A single sentence, front-loaded with the verb and resource, then a tight colon-list of outputs. Every clause carries information and nothing is repeated from the schema or annotations.
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 one-parameter read-only lookup with no output schema, the description is essentially complete because it enumerates the return content. The only omissions are edge behavior for unknown or malformed rule ids and whether unknown ids error or return a miss.
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 would be 3, but the description adds the id format convention ('clause-test') and several additional worked examples (7.3-1, 7.18.5-1, 7.21.4.1-1) whereas the schema offers only '7.1-3'. That materially improves the chance of a valid id being supplied.
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+resource ('Explain a veraPDF PDF/UA-1 rule by id') and enumerates exactly what the answer contains (what it checks, the error message, auto-fix coverage, authoring-tool remediation). The 'clause-test' format plus four concrete id examples make it unambiguous versus the sibling check_pdf_accessibility, which evaluates a document rather than explaining a rule.
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 content list implies the intended workflow (look up a rule id surfaced by a failing check) but usage is only implied, never stated. It names no explicit trigger, no when-not-to-use, and does not point to check_pdf_accessibility as the alternative for actually running checks.
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.
check_pdf_accessibilityexplain_pdfua_rulePDF accessibility checks (veraPDF PDF/UA-1), auto-fix and Markdown conversion. EU-hosted.
Compliant PDFs (PDF/A-2A + PDF/UA-1) from markdown or a compact DSL - fast, no headless browser.
Validate XRechnung, Peppol BIS 3 and EN 16931 invoices with KoSIT; explain rules; check auto-repair
Run EPUBCheck for EPUB specification errors and compare two exports.
Add one secure layer between your agents and this server.
