Ebook File Check

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

With readOnlyHint=true, openWorldHint=true, and destructiveHint=false already covering the safety profile, the description adds important operational behavior: the engine is pinned to 5.3.0, runs with no network access, validates from exact bytes, and is bounded at 110 seconds. It also clearly states the pass verdict is only an automated profile, not a store guarantee — a meaningful limitation 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 description is front-loaded with the tool's core functionamp;engine, then the input constraint, then output summary, then usage guidance and caveats. It is fairly long but every sentence adds distinct information: validation target, single-source rule, result contents, use cases, pass limitations, and performance expectation. Minor redundancy between the input constraint and schema wording keeps it from a 5.

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?

The description tells the agent what the tool does, what counts as input, what the output contains (pass boolean, messages, RSC IDs, locations, truncation), how long it may take (110s deadline), and what a pass does not mean. Combined with a rich schema and safety annotations, nothing necessary for correct invocation or result interpretation is 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%: url, file, and maxMessages each have type, constraints, and semantic descriptions. The description does not add parameter-level meaning beyond the schema, and the main added constraint (only one of url/file, never both) is already stated in the schema itself. Baseline 3 is appropriate.

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?

The description opens with a specific verb and resource: 'Validates one EPUB ... against the EPUB 2/3 specification' using 'a pinned local EPUBCheck run in a no-network sandbox.' It unambiguously identifies the action, input type, and validation standard, while the one-file/one-source constraint differentiates it from any bulk or multi-file checker.

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 description gives concrete example use cases ('is this ebook valid', 'what is wrong with it') and states the single-source constraint (URL or attached file, never both). It also clarifies that a pass does not guarantee store acceptance—an implicit exclusion of over-reliance. It does not explicitly contrast with the sibling ebook_compare tool, but the one-file framing effectively scopes it.

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

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

Annotations already say read-only/non-destructive; the description goes beyond them by disclosing sequential execution, the shared 110-second hard deadline, the automated-only ranking caveat, the no-winner tie policy, and the different-title warning. This is substantial behavior-context benefit over structured fields.

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?

Front-loads the core function, then adds use cases, caveats, and timing in a logical order. It is fairly long, but the behavioral caveats are consequential enough that most sentences earn their place; a bit of redundancy with the schema could be trimmed.

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 comparison tool with 100% schema coverage and an output schema, the description adds the essential behavioral context: deadline, ordering convention, tie/ranking policy, title-mismatch warning, and human-review need. Nothing critical needed by an agent to invoke correctly appears 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 the schema already documents urls, files, and maxMessages. The description reinforces the baseline-first/revised-second ordering and the 'never both' constraint that are largely already in the schema descriptions, adding no major new parameter meaning.

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 highly specific verb and resource: runs a pinned EPUBCheck 5.3.0 comparison over exactly two EPUB builds and reports regressed/fixed findings. The purpose is distinct from the likely single-build sibling ebook_check by emphasizing two-build comparison and revision-over-revision questions.

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 concrete use cases ('did my re-export get worse', 'which build has fewer problems', revision-over-revision questions) and clear ordering rules (baseline first, revised second). Does not explicitly contrast with ebook_check or state when not to use it, but the two-build framing makes the intended context reasonably clear.

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