EasyAccessPDF

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

Annotations indicate read-only, open-world, idempotent. Description adds cost transparency ('Included with membership — no credits charged') and specifies return fields (pages, grade, issue list, tag coverage). Contradicts no 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?

Two sentences: first states purpose and standards, second covers cost and outputs, third input. Front-loaded, no fluff.

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 compliance checker with one parameter and output schema implied, description covers input format, cost, and output summary. Missing detail on error handling, but output schema likely covers it.

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% and provides constraint (max 50MB). Description repeats 'publicly accessible URL' without adding new meaning beyond schema. Baseline 3 for high coverage.

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?

Description clearly states it checks a PDF for accessibility compliance (PDF/UA-1, ISO 14289-1) using veraPDF. Distinguishes from sibling tools like eap_fix_pdf (fix) and eap_convert_to_markdown (convert).

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?

Implies usage for checking compliance before fixing, but no explicit when-to-use or alternatives guidance. Mentions input requirement (public URL) and cost (included, no credits), but lacks context for when not to use.

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 provide readOnlyHint, openWorldHint, and idempotentHint. The description adds context: conversion is 'clean Markdown', requires a public URL, and lists supported formats. It also clarifies the membership/credits model. No contradictions 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence plus a format list, front-loaded with the action. Every element adds value: tool purpose, cost info, formats, and input requirement. No fluff.

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?

Given the simple tool (one parameter, full schema coverage, output schema present), the description covers purpose, formats, cost, and URL requirement. Could potentially mention that output is a Markdown string, but the output schema likely covers that. Nearly complete.

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% with one parameter 'url' described as 'Publicly accessible URL of the document (max 50MB)'. The description reiterates this, adding no new semantic detail. 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?

Description clearly specifies the verb 'Convert' and resource 'document to clean Markdown'. It lists all supported formats (PDF, Word, etc.), making the tool's scope explicit. The sibling tools are PDF-specific, so this tool is properly distinguished as a multi-format converter.

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 states when to use (convert documents to markdown), notes it's included with membership and uses no credits. It also specifies the prerequisite: a publicly accessible URL. While no explicit 'when not to use' is given, the context is clear enough for an agent to select appropriately.

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?

Adds value beyond annotations: reveals membership inclusion, no credit cost, and that annotated-pdf returns a 24-hour download URL. Annotations already provide readOnlyHint, openWorldHint, idempotentHint; description complements with operational context.

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?

Three concise sentences, no fluff. Purpose and key details are front-loaded. Every sentence earns its place.

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?

Given the tool's simplicity (2 params with 100% schema coverage, output schema exists), the description covers purpose, formats, membership benefit, URL accessibility, and max size. No gaps remain for an agent to understand and invoke correctly.

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% with descriptions for both parameters. Description enriches meaning by explaining each format's output (e.g., 'structured document tree' for json, 'plain text' for text, 'layout visualization with labeled structure boxes' for annotated-pdf). This adds clarity beyond the schema's brief labels.

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?

Description clearly states 'Export a PDF to another format' with specific verb and resource. Lists all four formats (json, html, text, annotated-pdf) with brief explanations. Distinguishes from sibling tools like eap_convert_to_markdown and eap_check_pdf by focusing on export/conversion, not checking or fixing.

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?

Mentions membership inclusion and no credits, but does not provide explicit guidance on when to use this tool versus siblings or when not to use it. No alternatives or exclusions are described.

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?

Beyond annotations (readOnlyHint=false, etc.), the description adds critical behavioral details: it costs 1 credit per document, produces a 24h download URL, and performs specific actions (inject metadata, auto-tag, re-audit). 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with 4 meaningful sentences. It front-loads the main purpose and steps, then adds cost, output, and requirement. Every sentence adds value without redundancy.

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?

Given the presence of an output schema (not shown), the description adequately covers output structure (zip with tagged PDF, report, checklist). It also addresses cost, prerequisites, and high-level workflow. No major gaps for a tool with moderate complexity.

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 description coverage is 100%, so the baseline is 3. The description reiterates the need for a publicly accessible URL, which matches the schema's own description. It does not add new parameter-specific meaning beyond that.

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 clearly states the tool auto-fixes PDFs for accessibility by injecting metadata, auto-tagging, and re-auditing. It distinguishes itself from sibling tools like eap_check_pdf (checking) and eap_export_pdf (exporting) by focusing on the fixing action.

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 explains that it costs a remediation credit and requires a publicly accessible URL, setting clear prerequisites. It does not explicitly say when not to use it or mention alternatives, but the cost and dependency on accessibility provide strong usage context.

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?

The description adds specific fields to the read-only and idempotent behavior indicated by annotations. It provides useful context about what the tool returns without contradicting annotations. However, it does not mention prerequisites or failure cases, which would enhance transparency.

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, well-structured sentence that immediately conveys the tool's purpose and key fields. No extraneous information.

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?

Given no parameters and the presence of an output schema (not shown but implied), the description fully covers what the tool does and what it returns. An agent can safely select and invoke this tool without additional context.

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?

The tool has zero parameters, so the description cannot add parameter semantics beyond the schema. Schema coverage is 100%, and the description appropriately focuses on the return fields. With zero parameters, baseline score is 4.

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 clearly states the tool retrieves EasyAccessPDF account status, listing specific fields (membership plan, expiry date, remaining credits, current prices). It effectively distinguishes from sibling tools that focus on PDF operations.

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?

While no explicit when/when-not is given, the purpose is clear and the context signals show no sibling tools for account status, implying this is the tool to use for account info. The description does not provide alternatives, but the distinction from PDF tools is evident.

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