Ebook File Check

ebook_check

Read-only

Validates one EPUB (a directly hosted public URL or a file attached in chat) against the EPUB 2/3 specification using a pinned local EPUBCheck 5.4.0 engine run in a no-network sandbox. Each call takes exactly one source: the url parameter or the file attachment, never both. Returns the automated verdict: pass boolean, EPUB version, message counts by severity (fatal/error/warning/usage), findings grouped most-severe-first with EPUBCheck rule id (RSC-005, OPF-014, …), file path and line/column, plus a structural inventory (spine items, media types, remote-resource state), SHA-256 of the exact bytes, and truncation metadata. Use for one-file readiness and diagnosis: 'is this ebook valid', 'does this EPUB have specification problems before upload', 'what is wrong with it'. A pass means only that the bytes satisfied the automated profile; it never renders the book, judges accessibility, or guarantees any store will accept it, and human review of how the book reads and looks is always required. Downloads and validates a live EPUB under a 110-second call deadline; tell the user before the call.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	No	Direct public HTTP(S) URL to the EPUB file bytes, including the protocol, not a ChatGPT file id, local path, cloud-drive share, archive/viewer page, or authenticated URL needing a login. Each call takes either URL sources or attached-file sources, never both STRICT RULE: Ebook check failed: provide either an EPUB URL or an attached EPUB file, not both STRICT RULE: Ebook check failed: provide a public EPUB URL or attach the EPUB file
`file`	No	An EPUB file attached in chat, up to 25 MB, validated from its exact bytes. Provide either this attachment or url, never both.
`maxMessages`	No	Maximum spec findings to return, most severe first (default 200); raise it to see more of a very noisy book, lower it to keep the answer short

Output Schema

TableJSON Schema

Name	Required	Description
`pass`	Yes	True when the EPUB has no fatal or error messages against the automated profile
`bytes`	Yes	Downloaded EPUB size in bytes
`counts`	Yes	Counts of EPUBCheck findings grouped by severity
`sha256`	Yes	SHA-256 hash of the exact validated bytes
`finalUrl`	Yes	URL after redirects, with query string and fragment stripped
`findings`	Yes	Bounded spec findings, most severe first, capped by maxMessages
`fetchedAt`	Yes	ISO timestamp the EPUB was fetched and validated
`inventory`	Yes	Structural inventory reported for the EPUB container
`nonclaims`	Yes	What this automated result does not establish
`redirects`	Yes	Redirect hops followed
`truncation`	Yes	Finding totals and the applied limit on returned findings
`contentType`	No	Content-Type the server returned
`epubVersion`	No	Detected EPUB version, e.g. 2.0.1 or 3.0; omitted when the engine could not detect it
`processingMs`	Yes	Total processing time in milliseconds
`requestedUrl`	Yes	The checked EPUB source: the submitted URL with query and fragment stripped, or the attached file's name
`engineVersion`	Yes	EPUBCheck engine version that produced the verdict
`ruleProfileDate`	Yes	Release date of the pinned EPUBCheck rule profile
`humanReviewItems`	Yes	Checks only a qualified human can perform
`epubVersionDetected`	Yes	Distinguished state: false means the version could not be detected, distinct from a detected-but-invalid version
`humanReviewRequired`	Yes	Always true: automated conformance never covers how the book reads or renders

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already carry readOnlyHint=true, openWorldHint=true, destructiveHint=false, and the description adds substantial context beyond them: pinned engine version, offline sandbox, live download with a 110-second deadline plus an explicit instruction to 'tell the user before the call', and what a pass does not certify. No contradiction with annotations.

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?

Densely written and front-loaded with the core action before any detail. However, the long enumeration of return fields (pass boolean, severity counts, rule ids, structural inventory, SHA-256) is largely redundant given that an output schema exists, per the rubric that description needn't explain return values when one is present.

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 tool with 3 parameters including a nested file object, an output schema, and significant operational constraints (mutual exclusivity, 110-second deadline, sandbox, live download), nothing an agent needs to invoke it correctly is missing — constraints, caveats, and pre-call user notification are all present.

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 baseline is 3. The schema already documents url/file mutual exclusivity ('never both', STRICT RULE text) and maxMessages bounds, so the description's restatement of the one-source rule adds little beyond what the schema provides.

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 and resource — 'Validates one EPUB ... against the EPUB 2/3 specification' — with precise context (EPUBCheck 5.4.0, no-network sandbox). The 'one EPUB' framing and single-source rule clearly distinguish it from the sibling ebook_compare without opening any schema.

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 when-to-use signals with three concrete example intents: 'is this ebook valid', 'does this EPUB have specification problems before upload', 'what is wrong with it'. It also states hard limits — pass 'never renders the book, judges accessibility, or guarantees any store will accept it' — but never names ebook_compare as the alternative routing, so sibling differentiation is implicit rather than explicit.

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

All Ebook File Check tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.