Server Quality Checklist

Tool Scores

• remove_fieldC
  2.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 disclose behavior. It states deletion but does not mention side effects, prerequisites (e.g., field must exist, must be a false positive), or what happens after deletion.

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

  Conciseness3/5

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

  The description is extremely concise (one sentence), but it omits necessary details. For a destructive single-parameter tool, it should be longer to provide behavioral and usage context.

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

  Completeness2/5

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

  The tool is simple but lacks completeness. Despite having an output schema, the description does not mention return value or confirm deletion. It also does not specify that the field_id must correspond to a false positive field.

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

  Parameters1/5

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

  Schema coverage is 0%, and the description does not add meaning to the single parameter 'field_id'. It mentions 'false positive' but does not explain how to identify such a field or what value to provide for field_id.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool deletes a field that is a false positive. It uses specific verb 'delete' and resource 'field'. However, it does not distinguish from sibling tools like 'remove_fields' which might delete multiple fields.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'prune_fields' or 'remove_fields'. No exclusions or context are given.

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

• list_fieldsC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden. It implies a read operation but does not explicitly state it is non-destructive, nor does it mention pagination behavior beyond a vague hint. No details on output structure or side effects.

  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 with no extraneous words. Front-loaded with core purpose. Very concise while still conveying optional behavior.

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

  Completeness2/5

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

  Despite having an output schema (unknown content), the description lacks scope, explanation of 'current working fields', and any filtering capabilities. For a listing tool, more context is expected.

  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?

  The description adds some meaning to the page_index parameter by noting optional pagination, but it does not clarify that page_index specifies which page or what values are valid. Since schema has no description, this is a minor improvement.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (list) and the resource (current working fields), and adds the optional page constraint. It distinguishes from sibling tools like add_field, remove_field, etc. However, 'current working fields' is somewhat vague.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool vs alternatives like prune_fields or render_preview. The description does not include context for using the optional page parameter or any prerequisites.

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

• list_templatesC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, pagination, or rate limits. A simple 'List' implies read-only but is not explicit.

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

  Conciseness3/5

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

  The description is very short and front-loads the purpose, but it lacks structure and details. It is concise but not optimally informative.

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

  Completeness3/5

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

  Given the output schema exists, the description needn't explain return values, but it omits any mention of pagination or ordering. The description is somewhat incomplete for a listing tool with many siblings.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain the 'limit' parameter or its behavior (e.g., max limit, pagination). The description adds minimal value 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 verb 'List' and the resource 'saved templates', and specifies the output fields (name, field count, hash). It distinguishes from sibling tools like list_fields, which lists fields, and other template-related tools.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives like list_fields or other template tools. With 13 siblings, explicit usage context is missing.

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

• update_fieldC
  2.9/5.0
  Behavior2/5

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

  No annotations provided, so the description carries full burden. It indicates mutation (move/resize/rename) but does not disclose side effects, permissions, or whether changes are saved. Lacks behavioral depth.

  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 very concise (2 sentences), front-loads the main purpose, and provides specific alignment details without waste. Could be slightly more structured but remains efficient.

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

  Completeness2/5

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

  Given 9 parameters and 0% schema coverage, the description is incomplete. It fails to explain all parameters, required field_id, or output behavior, despite an output schema being 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 0%, so description must compensate. It explicitly explains align and vertical_align with allowed values. However, it does not explain x, y, h, w, name, or field_type, leaving many parameters undocumented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool moves/resizes/renames a field or sets text alignment, specifying the resource and actions. It distinguishes from add_field and remove_field but does not differentiate from update_fields (plural).

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool vs alternatives like update_fields or remove_field. No when-to-use or when-not-to-use statements provided.

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

• remove_fieldsB
  3.1/5.0
  Behavior2/5

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

  No annotations provided; description only says 'Delete' without mentioning behavioral traits like idempotency, error handling, or whether it's destructive. Minimal disclosure.

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

  Conciseness3/5

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

  One sentence, front-loaded with action. Adequate length for a simple tool but lacks necessary detail on parameters and behavior.

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

  Completeness2/5

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

  Output schema exists but tool is a mutation with no annotations; description does not cover important aspects like permissions or limits, making it incomplete for safe invocation.

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

  Parameters1/5

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

  Schema coverage is 0%; description adds no meaning to the 'field_ids' parameter beyond its existence. No format, source, or validation hints.

  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 states 'Delete many fields in one call' with specific verb and resource, and distinguishes from sibling 'remove_field' as batch version.

  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?

  Clear indication that this is a batch version of 'remove_field', implying use when multiple fields need deletion. No explicit exclusions or alternatives given, but sibling tools provide context.

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

• fill_pdfA
  3.6/5.0
  Behavior4/5

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

  The description discloses key behaviors: how AcroForm fields are filled natively vs. drawn for others, and that warnings flag values that are shrunk/truncated. Since no annotations exist, the description carries full weight. However, it lacks details on failure modes or access requirements.

  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 very concise: three sentences without any redundant text. The first sentence states the core purpose, followed by terse but necessary details. 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?

  Given the output schema exists (not shown), the description need not detail return values. It covers the main filling behavior and the warning list. Still, it omits edge cases like invalid field IDs or missing output paths, but these are minor for a tool of this complexity.

  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?

  The explanation of `values` (field id->text mapping, checkbox handling) adds meaning beyond the schema, and `output_path` is implied. However, `flatten` is not mentioned at all, and schema coverage is 0%, so the description does not fully compensate for the missing parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fills a PDF and saves it, which is a specific verb+resource. While it does not explicitly distinguish from sibling tools like render_filled_preview, the 'save it' part differentiates it from pure rendering tools. Overall, the purpose is unambiguous.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or which sibling tools are better suited for specific scenarios. The only usage hint is implicit from the description's focused task.

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

• add_fieldA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description bears full burden. It explains the coordinate system (percentages, top-left origin), the meaning of align and vertical_align parameters, and how values are positioned. However, it omits behavioral details like what happens on duplicate names, field_type/drop behavior, or page_index scope.

  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 efficient: four sentences that front-load the purpose, then add coordinate and alignment details. No redundancy or filler.

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

  Completeness3/5

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

  Given 9 parameters, no schema descriptions, no annotations, and an existing output schema? the description covers the most critical input semantics but omits name, field_type, and page_index. It also does not reference the output schema. There are clear gaps for a tool with this complexity.

  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 0%, so description must compensate. It explains x,y,w,h as percentages with top-left origin, and align/vertical_align with value constraints. But name, field_type, and page_index are not explained, leaving gaps for 4 of 9 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 adds a field that the detector missed (false negative), which is a specific verb+resource. It distinguishes from siblings like update_field (modify existing) and remove_field (delete) by focusing on adding missed detections.

  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 usage for adding missed fields based on detector output, but does not explicitly state when not to use it or mention alternatives among the sibling tools. The context is clear but guidance is implicit.

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

• prune_fieldsA
  3.9/5.0
  Behavior4/5

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

  The description discloses that removed IDs are returned for auditability and that the operation is reversible via add_field. It also explains that thresholds are strictly-less-than and that page_index limits to one page. However, it does not describe what happens when no criteria are provided (e.g., deletes nothing or everything), which is a behavioral gap.

  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 (3 sentences), front-loaded with the purpose, and logically structured: purpose first, then parameter details, then return value and reversibility. Every sentence serves a clear purpose.

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

  Completeness2/5

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

  Despite explaining parameters and return value, the description omits a critical detail: the behavior when no criteria are provided. Since all parameters are optional, an agent might invoke the tool with no arguments, potentially deleting all fields—a dangerous outcome. The description should clarify this edge case.

  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?

  With schema description coverage at 0%, the description fully compensates by explaining each parameter's semantics: field_type for exact match, confidence_below/width_below/height_below as strictly-less-than thresholds (width/height in % of page), page_index to limit to one page, and exclude_ids to keep fields. This adds critical meaning beyond the bare 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 purpose: 'Bulk-delete fields matching ALL given criteria.' It specifies a verb (delete) and resource (fields), and the phrase 'ALL given criteria' and example 'detection noise' distinguish it from siblings like remove_field (single) or remove_fields (possibly different criteria).

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

  Usage Guidelines2/5

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

  The description lacks explicit guidance on when to use this tool versus alternatives. It does not warn about potential dangers (e.g., deleting all fields if no criteria are provided) or specify prerequisites. The sibling tools include remove_field and remove_fields, but no comparison is made.

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

• render_previewA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It transparently explains the color coding (blue=deterministic, green/orange/red=confidence levels) and that labels show field IDs. It does not address safety or rate limits, but for a preview tool, this behavioral disclosure is sufficient.

  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 two concise sentences front-loaded with purpose, followed by necessary details about color coding. 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.

  Completeness4/5

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

  For a preview tool with one parameter and no output schema, the description adequately explains the output (rendered page with boxes), color meanings, and verification purpose. Missing parameter documentation slightly reduces completeness.

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

  Parameters2/5

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

  The input schema has one parameter (page_index) with 0% description coverage. The description does not mention page_index or provide any semantic guidance beyond the schema's default value. This is a significant gap as the parameter's meaning is left entirely to 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 renders a page with field boxes, with specific color coding distinguishing deterministic vs ML detections. This verb+resource specification is distinct from siblings like fill_pdf or render_filled_preview.

  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 verification of placement via visual inspection, but does not explicitly state when to use or avoid this tool relative to alternatives such as render_filled_preview or list_fields. No exclusions or context for selection are provided.

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

• save_templateA
  4/5.0
  Behavior4/5

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

  With no annotations, description explains behavioral impacts: templates cause open_pdf to return fields with confidence 1.0 and skip ML, making filling deterministic. Does not mention overwriting behavior.

  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?

  Multi-sentence description is informative with no redundancy. Each sentence adds value, though could be slightly more concise.

  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 one parameter and an output schema (though not shown), the description adequately covers the tool's purpose and behavior without missing critical details.

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

  Parameters2/5

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

  Schema has only one parameter 'name' with 0% description coverage. Description does not elaborate on the meaning or format of the name, beyond implying it identifies the template.

  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 saves the current field layout as a reusable template. It uses specific verb 'save' and resource 'template', differentiating from sibling tools like list_templates.

  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 instructions on prerequisites: name fields and remove false positives before saving. Explains benefit (deterministic fill) but lacks explicit alternatives or 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.

• close_workspaceA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description effectively discloses key behaviors: saved templates and output PDFs are not deleted, and the operation is idempotent. It could add more, but covers essential traits for 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 two concise sentences with no wasted words. The first sentence states the purpose, the second adds important behavioral context, achieving excellent efficiency.

  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 no parameters and an output schema exists (so return values not needed), the description adequately covers the tool's action and non-destructive nature. Minor missing detail is timing relative to other operations, but it's largely complete.

  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?

  There are no parameters, so the description does not need to add meaning. Baseline 4 per rule for zero parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'Release' and the resource 'current PDF and field data', making the tool's main function obvious. However, it does not explicitly differentiate from sibling tools, though the cleanup purpose is 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?

  The description advises use 'when work is finished' and highlights idempotency for automation, providing clear usage guidance. It lacks explicit when-not-to-use advice but the context is sufficient.

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

• update_fieldsA
  4.2/5.0
  Behavior3/5

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

  Discloses partial success behavior and item structure, but lacks details on permissions, side effects, or error types.

  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 concise sentences, no redundancy, front-loaded purpose.

  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?

  Output schema exists, so return values not needed. Description covers parameter structure and distinguishes from sibling tools. However, could mention when not to use it more explicitly.

  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 provides no description (0% coverage), but description specifies allowed fields for each item (x,y,w,h,name,field_type,align,vertical_align), compensating well.

  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 it's a batch version of update_field, with verb 'update' and resource 'fields'. Distinguishes from sibling update_field.

  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?

  Implies when to use (batch updates) vs update_field (single). Also explains partial failure behavior with unknown field_ids.

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

• render_filled_previewA
  4.7/5.0
  Behavior4/5

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

  Discloses typography approximation and no resource consumption, but does not detail behavior for invalid values or page_index beyond default.

  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?

  Four brief, well-structured sentences covering purpose, mechanics, cost, limitation, and usage advice; 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?

  Provides complete guidance on when and how to use, what to expect, and next step, compensating for lack of annotations and output schema.

  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?

  Explains values as field-id-to-text mapping with checkbox support, but page_index is left without explanation despite 0% 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?

  Clearly states it previews the filled page before PDF generation, explains it draws values into boxes, and distinguishes from fill_pdf.

  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 advises to use for verifying placement, alignment, and overflow before calling fill_pdf, and notes no cost/fill consumption.

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

• open_pdfA
  4.8/5.0
  Behavior5/5

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

  No annotations provided, so description fully discloses traits: image conversion deterministic, resolution order, skipping steps with force_detect, and confidence handling. 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?

  Well-structured with bullet points, front-loads purpose, every sentence adds value. Appropriately sized for the complexity.

  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?

  Highly complete given 4 params, no annotations, and output schema present. Only max_pages is not explained, but overall thorough.

  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 0%, but description adds meaning for path, force_detect, and min_confidence. Missing explanation of max_pages parameter, which is a minor gap.

  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 opens a PDF or scanned image and detects fillable fields, listing three resolution methods. It distinguishes itself from sibling tools like fill_pdf or list_fields.

  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 explains when to use force_detect, min_confidence, and the resolution order. Provides clear context for when to use this tool vs alternatives.

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