Server Quality Checklist

Tool Scores

• eap_get_account_statusA
  3.8/5.0
  Behavior2/5

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

  No annotations provided, so description must disclose behavioral traits. It describes what information is retrieved but does not state that the operation is read-only or provide any safety or authorization notes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Single sentence that is front-loaded with the verb and resource, concise with no unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters and no output schema, the description adequately lists the information returned. Could be improved by explicitly stating it is a read-only operation.

  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?

  No parameters exist; schema coverage is 100% (empty). Description adds meaning by listing the account status fields returned, going beyond the schema's lack of parameters.

  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?

  Description clearly states the tool retrieves account status and lists specific fields (membership plan, expiry, credits, prices). It distinguishes from sibling tools which operate on PDF files.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Description implies usage for checking account status but does not explicitly state when to use it versus alternatives, nor provides when-not guidance. Sibling tools are contextually distinct, but no explicit usage guidance.

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

• eap_fix_pdfA
  3.9/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Discloses actions, return format (24h URL with zip), and cost. Missing details on failure modes, whether original PDF is unchanged, and auth requirements.

  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?

  Description is concise with three sentences, front-loading the purpose. Includes relevant billing info. No unnecessary verbiage.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers input (URL), process (auto-fix, re-audit), output (zip with three files), and constraints (cost, 24h URL). Lacks details on error handling but is sufficient given no output schema.

  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 coverage is 100% with descriptions for both url and title. Description adds only the 'publicly accessible' constraint for url, which is already in schema. No significant extra meaning.

  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?

  Clearly states the tool auto-fixes PDFs for accessibility, listing specific actions (inject metadata, auto-tag, re-audit). Distinguishes from siblings like eap_check_pdf (check only) and eap_convert_to_markdown (conversion).

  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?

  States cost and that membership does not include auto-fix, and requires a publicly accessible URL. Does not explicitly say when to use or not, but purpose is clear enough to infer.

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

• eap_convert_to_markdownA
  4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must cover behavioral traits. It mentions the tool is free and has a 50MB size limit, but does not disclose what happens on failure, whether it is read-only, or any authentication requirements. The lack of such details hinders safe invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the core action and includes a clear list of supported formats. Every word contributes to understanding, with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one parameter and no output schema, the description covers the essential aspects: purpose, supported formats, cost, and input requirement (public URL). It does not explicitly state the output format (Markdown is implied by the name), but it is sufficient for an agent to use correctly. Minor omission: no mention of return type or error behavior.

  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% for the single parameter 'url', which the schema describes as 'Publicly accessible URL'. The description adds value by listing supported document formats (PDF, Word, etc.), which is not in the schema, thus helping the agent understand what types of URLs are acceptable.

  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?

  The description clearly states the tool converts documents to Markdown, specifies supported formats, and distinguishes itself from siblings which are PDF-specific operations. The verb 'convert' and resource 'document to Markdown' are explicit.

  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?

  The description tells when to use (to convert documents to Markdown), the required input (a publicly accessible URL), and lists supported formats. It lacks explicit alternatives or when-not-to-use, but the sibling tools are obviously different, providing implicit guidance.

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

• eap_check_pdfA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description bears the full burden. It explains the tool returns pages, grade, issue list, and tag coverage, and clarifies it uses veraPDF. The cost behavior is also disclosed ('no credits charged'). There is 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.

  Conciseness5/5

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

  The description is brief (two sentences) and well-structured. It fronts the purpose, then lists key outputs and requirements. No unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with no output schema, the description adequately covers inputs (URL constraints) and outputs (grade, issues, etc.). It mentions standards and cost. Lacks error handling details, but overall sufficient.

  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%, but the description adds value by specifying that the URL must be publicly accessible and has a 50MB size limit, which is not in the schema description alone.

  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?

  The description clearly states the tool checks PDF accessibility compliance using specific standards (PDF/UA-1, ISO 14289-1) and lists the outputs (pages, grade, issue list, tag coverage). It distinguishes from sibling tools (e.g., convert, fix) by focusing on checking/analysis.

  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?

  The description specifies that a publicly accessible URL is required and mentions the 50MB limit. It also notes 'included with membership — no credits charged'. However, it does not explicitly state when to use this tool versus alternatives, though the sibling tools are clearly different in function.

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

• eap_export_pdfA
  4.5/5.0
  Behavior4/5

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

  Discloses that the tool is included with membership and uses no credits, which is valuable behavioral context. Also explains the annotated-pdf output format (24h download URL). However, it does not describe return types for json, html, or text outputs, nor mention any side effects or rate limits. With no annotations, the description reasonably covers the key aspects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two sentences with no wasted words. The key action and formats are front-loaded. Every sentence adds value—the first gives purpose and membership info, the second details formats. Highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 2 parameters, no output schema, and no annotations, the description covers the core purpose and parameter details well. It lacks explicit description of return values for json, html, and text formats, but the schema's explainability and the tool's simplicity (likely returns the converted file directly) make it mostly complete. The missing return details are a minor gap.

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

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Adds significant meaning beyond the input schema by explaining each format: 'json (structured document tree)', 'annotated-pdf (layout visualization with labeled structure boxes — returned as a 24h download URL)'. The schema only gives enum names and basic descriptions, so the description enriches parameter understanding.

  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?

  Clearly states 'Export a PDF to another format' and lists the specific formats (json, html, text, annotated-pdf). The verb 'Export' and resource 'PDF' are explicit, and the tool name and description distinguish it from siblings like eap_check_pdf, eap_convert_to_markdown, etc.

  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?

  Provides clear context: 'Pass a publicly accessible URL of the PDF' and notes membership inclusion. Does not explicitly state when not to use or compare with alternatives, but the specificity of formats and the mention of membership provide sufficient guidance for typical use.

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