Server Quality Checklist

Tool Scores

• add_formA
  3.8/5.0
  Behavior3/5

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

  Annotations already indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds that it generates a new PDF (not modifies existing), but does not disclose details like authentication requirements or performance. The schema covers parameters well, but behavioral details beyond annotations are minimal.

  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 succinct sentences: first defines the action and outputs, second states use cases. No redundant information; every sentence adds value.

  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?

  With a complex nested schema but 100% parameter coverage and an output schema present, the description is largely adequate. It could mention that the tool creates a standalone PDF (not appended), but the name 'add_form' might imply modifying an existing document. The description resolves this ambiguity, making it complete for most scenarios.

  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?

  All parameters have schema descriptions (100% coverage), so the description adds no additional meaning beyond summarizing field types. The description does not compensate with extra context on parameter usage or constraints.

  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 'Generate a PDF containing an interactive AcroForm' and lists specific field types (text, textarea, checkbox, etc.), with use cases (data-capture, surveys, fillable templates). This distinguishes it from sibling tools like add_attachment or add_barcode.

  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?

  The description mentions suitability for forms and surveys but does not explicitly state when to prefer this tool over alternatives, nor does it provide when-not-to-use guidance. Sibling tools cover other PDF operations, so explicit differentiation would help.

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

• embed_imageA
  3.8/5.0
  Behavior3/5

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

  Annotations already provide idempotentHint=true and destructiveHint=false. The description adds no behavioral context beyond generating a PDF, such as error handling, size limits, or output details. It satisfies basic transparency but doesn't enrich beyond 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.

  Conciseness5/5

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

  The description is a single, concise sentence with no redundant information. It front-loads the core purpose and efficiently covers key aspects.

  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 rich schema (100% coverage, output schema exists), the description is adequately complete. It covers the main function and provides enough context for an agent to select the tool, though it could mention outputMode options.

  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%, so all parameters are already described. The description hints at optional caption and dimensions but adds no new meaning. Baseline score of 3 is appropriate.

  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 generates a PDF with an embedded image, specifying accepted formats (JPEG/PNG) and input method (base64). This distinguishes it from sibling tools like add_attachment or generate_basic_pdf.

  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?

  The description implies use for embedding images but lacks explicit guidance on when to use vs alternatives like add_attachment or when not to use (e.g., for non-image attachments). No sibling comparisons or exclusions are mentioned.

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

• encrypt_pdfA
  4/5.0
  Behavior1/5

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

  Annotation contradiction: destructiveHint is false but description states encryption drops existing signatures and AcroForm (destructive effects). This inconsistency undermines transparency. Annotation says not destructive, but description details destructive consequences.

  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 paragraph with front-loaded main purpose and key details. Every sentence adds value: algorithm options, password roles, permission details, and critical caveat. No wasted words.

  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?

  Given 8 parameters, nested objects, and existing output schema, the description covers essential behaviors, parameter semantics, and the ordering caveat. It addresses password rotation and permission flags comprehensively. The output schema handles return value details, so description is complete.

  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 input schema: explains password rotation, algorithm defaults, permissions structure, and the caveat about dropping signatures on pdfBase64. Schema coverage is 88%, so the description compensates well with additional context for parameters like ownerPassword, userPassword, and algorithm.

  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 re-secures a PDF with specific encryption algorithms (AES-128/256) and password options. Distinguished from siblings like decrypt_pdf and split_pdf by focusing on encryption and password rotation.

  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 explicit guidance on when to use (encrypting/re-encrypting PDFs, password rotation) and a crucial caveat about ordering (encrypt before signing). While it doesn't explicitly list when not to use, the context of sibling tools implies alternatives. The description gives clear context for usage.

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

• add_attachmentA
  4.4/5.0
  Behavior4/5

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

  Annotations indicate idempotentHint=true but lack safety details. The description adds that the tool auto-emits PDF/A-3b conformance, explains why PDF/A-3 is required for embedded files, and notes the 8 MiB attachment cap. 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 three sentences with zero waste. It front-loads the core function, immediately gives usage guidance with a strong directive, and adds technical context efficiently.

  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 complexity (multiple parameters, output schema, sibling tools), the description covers the primary use case, contrasts with siblings, and notes important constraints. It omits details about output mode but the schema covers that.

  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 67%, and the description adds value for key parameters: explains that blocks uses the same schema as generate_basic_pdf, and that attachments auto-enable PDF/A-3 and are used for Factur-X. It does not elaborate on outputMode/outputPath, but the schema provides enums and defaults.

  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 generates a PDF/A-3 document with embedded files, specifies the ISO standard, and explicitly contrasts with generate_basic_pdf for Factur-X/ZUGFeRD use cases. The verb 'Generate' and resource 'PDF/A-3' are specific and distinguish from siblings.

  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 explicitly says 'USE THIS INSTEAD OF generate_basic_pdf' when embedded files are needed, and provides context for Factur-X invoices. It does not explicitly state when not to use, but the contrast with the sibling implies the exclusion.

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

• add_chartA
  4.4/5.0
  Behavior4/5

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

  The description reveals behavioral traits like zero rasterization, auto-generated alt text for PDF/A, and constraints on series count for pie/donut. Annotations already indicate idempotent hint, and description adds value beyond that, though it could mention more about output format or error handling.

  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 concise, front-loaded with the main purpose, then lists features and constraints, and ends with a clear alternative. Every sentence provides value without 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?

  Given the complexity (16 params, nested objects, output schema), the description covers the main behavioral aspects and usage boundaries. It lacks details on error handling or limitations like max series count, but those are in the schema. The presence of an output schema reduces the need to explain return values.

  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%, so the baseline is 3. The description provides some high-level context (e.g., pie uses one series, colors are hex strings) but does not add significant detail beyond what the schema already provides for individual 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?

  The description clearly states the tool generates a single-page PDF with native vector charts, listing specific chart types (bar, barH, line, pie, donut) and rendering method. It distinguishes from sibling tool generate_basic_pdf by noting that for embedded charts, one should use that tool instead.

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

  Usage Guidelines5/5

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

  The description explicitly tells when to use this tool (standalone chart PDF) and when not to (embedded charts: use generate_basic_pdf). It also lists supported chart types and key features, giving clear context for selection.

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

• draft_governance_issueA
  4.4/5.0
  Behavior5/5

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

  Beyond annotations (idempotentHint=true, etc.), the description adds critical behavioral details: no outbound network calls, no GitHub write path, validation throws GOVERNANCE_VIOLATION. 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?

  The description is dense but front-loaded with the core purpose. It efficiently conveys the HITL contract and behavioral constraints, though it could be more structured (e.g., bullet points).

  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?

  Given the tool's complexity (11 params, governance validation, multiple output modes), the description covers all essential aspects: local-only, no submit, validation rules, output modes, and the directive to present results. Output schema exists, so return format is covered.

  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%, so baseline is 3. The description adds some context (e.g., outputMode file requires PDFNATIVE_MCP_OUTPUT_DIR) but does not elaborate extensively on each parameter.

  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 produces a local governance-compliant GitHub issue draft and compliance report, with the explicit constraint 'NEVER submit anything'. This distinguishes it from all sibling PDF manipulation tools.

  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 explains the HITL contract: agent drafts, human submits. It mentions validation and violation behavior. While it doesn't explicitly list when not to use, the sibling tools are unrelated (all PDF), so context is clear.

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

• extract_textA
  4.4/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds significant context: best-effort approach, walking content stream, handling of encrypted PDFs, extractable boolean and reason, and future roadmap. 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?

  The description is well-structured with front-loaded core purpose. Each sentence adds value, covering process, edge cases, and roadmap. Could be slightly more concise but overall efficient.

  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?

  Given the tool's complexity (7 params, 1 required, output schema exists), the description is highly complete. It explains error handling, expected behaviors, and future enhancements. The output schema covers return values, so no need for additional detail.

  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%, so baseline is 3. The description adds minimal parameter-specific detail beyond what the schema provides, though it does mention password security and verbosity effects in context.

  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 it extracts plain text from a non-encrypted PDF using specific content stream operators. It distinguishes from siblings like encrypt_pdf or annotate_pdf by focusing solely on text extraction.

  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 explains when to use (non-encrypted PDFs) and conditions like extractable=false is expected for certain PDFs. It does not explicitly state when not to use or provide direct alternatives, but the context is clear.

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

• generate_basic_pdfA
  4.4/5.0
  Behavior4/5

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

  Annotations provide idempotentHint=true, destructiveHint=false, readOnlyHint=false. The description adds context about PDF/A font embedding and ISO references. However, it does not explicitly confirm idempotency or mention any other behavioral traits beyond output modes.

  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?

  The description is a single, well-structured paragraph that front-loads the main purpose and usage guidance. It is concise but could be slightly more structured with separate sentences for return format.

  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?

  Given the tool's complexity (11 parameters, nested blocks, charts, outline, etc.) and the presence of a rich output schema, the description covers all essential aspects: purpose, usage, return formats, and key options like PDF/A and watermark.

  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 each parameter having detailed descriptions. The tool description adds no additional semantic value beyond the schema, so baseline score of 3 is appropriate.

  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 generates a multi-page A4 PDF from structured blocks, and explicitly positions it as the default tool for plain documents, distinguishing it from specialized siblings like add_barcode or add_table.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance: 'prefer this over specialized tools unless you need barcodes, tables, attachments, or non-Latin scripts.' It also mentions optional pdfA flag with conformance levels, helping the agent choose the right tool.

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

• add_tableA
  4.6/5.0
  Behavior5/5

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

  The description goes beyond annotations by detailing backend switches ('Switches the backend to buildDocumentPDFBytes') for certain parameters, PDF/A compatibility, watermark opacity restrictions under pdfa1b, and smart-table field behaviors. This provides rich behavioral context.

  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?

  The description is well-structured with a clear main purpose followed by parameter highlights. It is front-loaded but somewhat lengthy; however, every sentence adds value for a complex tool.

  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?

  Given 20 parameters, nested objects, and an output schema, the description covers key aspects: purpose, feature highlights, PDF/A, watermark limitations, output modes, and backend behaviors. It is complete for the tool's complexity.

  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?

  With 100% schema description coverage, the baseline is 3. The description adds value by explaining smart-table fields (e.g., 'tagged for PDF/A', 'pdfnative v1.2') and linking parameters to backend behavior, though much is already in the schema.

  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 generates a tabular PDF report from column headers and data rows. It distinguishes itself from siblings like add_form or add_barcode by focusing on tabular data. The verb 'Generate' and resource 'tabular PDF report' are specific and unambiguous.

  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 indicates ideal use cases ('data exports, financial summaries, schedules'), providing clear context. However, it does not explicitly contrast with alternatives like generate_basic_pdf or mention when not to use this tool.

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

• add_barcodeA
  4.7/5.0
  Behavior5/5

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

  Discloses behavioral traits beyond annotations: generates a PDF, explains format-specific behavior (ecLevel ignored for non-QR, width/height constraints), output modes, and PDF/A conformance. Annotations already indicate idempotentHint=true, and description adds valuable context without contradiction.

  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 concise and well-structured: bullet points for formats, a common recipe, and additional notes. Every sentence adds value without redundancy.

  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?

  Given the tool's complexity (10 params, enums, output schema), the description covers all key aspects: formats, parameters, output modes, and archival options. It is complete for an agent to understand and invoke the tool correctly.

  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 80%, and description adds meaning beyond schema: explains that 'data' should not be URL-encoded, ecLevel usage, and which parameters are ignored for certain formats. This enhances understanding beyond the schema's bare descriptions.

  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 generates a single-page PDF embedding a barcode or QR code, listing supported formats and a common recipe. It distinguishes from sibling tools like add_attachment or add_form, which handle other PDF elements, making the purpose precise and distinct.

  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 specific usage guidance: common recipe for QR URLs, format-specific constraints (EAN-13 digits, ecLevel recommendations), and a note not to pre-encode URLs. While it doesn't explicitly state when not to use, the context is clear for barcode generation.

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

• add_international_textA
  4.7/5.0
  Behavior5/5

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

  The description discloses key behaviors beyond annotations: automatic BiDi reordering, harakat positioning, OpenType shaping, NFC normalization, and output modes (base64/file). Annotations already indicate idempotent and non-destructive nature, and the description enriches that with PDF generation specifics. No contradictions.

  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?

  The description is dense with information but well-structured, front-loading the core purpose. It could be slightly more concise, but every sentence adds value; no redundancy.

  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?

  Given the tool's complexity (8 parameters, nested objects, output schema), the description covers all essential aspects: supported scripts, handling of complex text, optional features, and output format. It is complete for an agent to use effectively.

  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?

  The description adds significant meaning beyond the input schema, explaining the 'lang' parameter's flexibility (single code, array, comma-separated), the 'normalize' parameter's default (NFC), and the 'pdfA' parameter's impact. With high schema coverage (75%), the description still enhances understanding, earning a top score.

  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 generates a PDF with text in any of 24 scripts, with optional emoji and math symbols. It uses a specific verb ('Generate') and resource ('PDF rendering text'), and distinguishes from siblings like 'generate_basic_pdf' or 'add_attachment' by focusing on international script support.

  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 provides clear context about when to use the tool (for multi-script, complex-shaping text) but does not explicitly state when not to use it or mention alternatives like 'generate_basic_pdf' for simple Latin text. It implies usage context effectively but lacks explicit exclusions.

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

• annotate_pdfA
  4.7/5.0
  Behavior5/5

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

  Beyond annotations (idempotentHint, non-destructive), the description adds key behavioral details: non-destructive incremental update, byte-for-byte preservation, appending to /Annots, and rejection of encrypted sources. No contradictions.

  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 concise (4-5 sentences) and well-structured: purpose, incremental update, types, parameter guidance, and caveat. Every sentence earns its place with no redundancy.

  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?

  Given the complexity (multiple annotation types, many optional parameters), the description covers the core functionality, constraints, and edge cases (encrypted source rejection). Output schema exists, so return value explanation is unnecessary.

  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?

  The description clarifies parameter usage beyond schema: explains required fields per annotation type (e.g., line needs start/end), clarifies 0-based page and rect format, and lists type-specific optional fields. Adds value despite 50% schema coverage.

  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 adds markup/drawing annotations to an existing PDF, specifying the action, resource, and annotation types. It distinguishes from siblings like add_attachment or extract_text by focusing on visual overlays.

  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 explicitly notes that annotations are non-destructive visual overlays that do not remove or redact content, and that encrypted sources are rejected. This provides clear when-not-to-use guidance, though it lacks explicit alternative tool names.

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

• decrypt_pdfA
  4.9/5.0
  Behavior5/5

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

  Beyond annotations, the description reveals that decryption rebuilds the page tree, drops signatures and AcroForm, and only keeps URI links. It also notes that documents with empty user passwords decrypt without one. 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 concise and well-structured: purpose first, then caveats, then alternative usage. Every sentence adds value with no redundancy.

  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?

  Given the complexity (encryption types, caveats, output schema exists), the description covers all essential points: password handling, behavioral impacts, alternative tools, and output mode. No gaps identified.

  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 75%, and the description adds context about password types (user/owner) and empty password handling. However, it largely repeats schema notes for pdfBase64 and outputPath, adding marginal new value.

  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 decrypts an encrypted PDF and emits an unencrypted copy. It specifies supported encryption types (RC4, AES) and distinguishes from sibling tools like inspect_pdf/extract_text for reading without rebuilding.

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

  Usage Guidelines5/5

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

  Explicitly provides when to use this tool vs alternatives: 'To READ an encrypted PDF without rebuilding it, pass `password` directly to inspect_pdf / extract_text / extract_attachments instead.' Also explains the caveat about dropped signatures and AcroForm.

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

• split_pdfA
  4.9/5.0
  Behavior5/5

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

  The description discloses many behavioral details beyond annotations, such as dropping signatures/AcroForm, keeping URI links by default, rejecting encrypted sources, and the indexed naming in file mode. 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.

  Conciseness5/5

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

  The description is concise with 5 sentences, front-loaded with the primary purpose, and includes only relevant details. Each sentence serves a clear purpose.

  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?

  Given the tool's complexity (8 parameters, nested objects, output schema), the description covers all critical aspects: splitting behavior, range semantics, object handling, encryption, output modes, error conditions, and an alternative tool. It is complete for an AI agent to select and invoke the tool correctly.

  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 description coverage is high (88%). The description adds meaningful context for parameters like ranges (0-based inclusive, default end), outputMode (base64 vs file behavior), and encryption options, enhancing understanding beyond the schema.

  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's function: 'Split one PDF into several documents — one per requested page range.' It uses a specific verb and resource and distinguishes from sibling tool extract_pages.

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

  Usage Guidelines5/5

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

  The description explicitly provides usage guidelines, including when to use alternatives: 'Use extract_pages instead when you want a single PDF from an arbitrary page subset.' It also details range conventions, behavior for annotations and encryption, and output modes.

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