Server Quality Checklist

Tool Scores

• genoffice_app_screenshotA
  3.7/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 of behavioral disclosure. It mentions the CDP mechanism and the app-window prerequisite, but does not disclose side effects (e.g., whether the window must be in foreground, whether app activation occurs), how the screenshot is captured, or any blocking/timeout behavior. For a capture tool with zero annotation coverage, this is thinner than ideal.

  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, front-loaded with the core action in the first sentence and prerequisite+usage in the second. Every sentence earns its place with no filler or redundant restatement of the tool name.

  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?

  For a single-parameter capture tool, the description covers purpose, prerequisite, output format, and downstream usage. However, it lacks behavioral context like screen-focus requirements or failure modes when the app isn't running, the debug port is unreachable, or the path is unwritable. Adequate for a simple tool but slightly under-specified on edge cases.

  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 schema already documents outPath with an example. The description reinforces that outPath is where the PNG is saved but adds no new format constraints beyond the schema's .png example. Baseline 3 is appropriate when schema does the heavy lifting.

  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?

  Clear verb+object+method: 'Capture a PNG screenshot of the GenOffice app window over CDP and save it to outPath.' This precisely states the resource (GenOffice app window), the action (capture PNG screenshot), the mechanism (CDP), and output location (outPath). Distinguishes cleanly from siblings like genoffice_app_status, genoffice_app_launch, and genoffice_extract_text.

  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 prerequisite ('Requires the app running with the debug port (genoffice_app_launch)') and a clear downstream usage suggestion ('Use together with vision to inspect the current UI state'). It says when to use the tool (to inspect UI state), though it doesn't explicitly state when NOT to use it or mention the alternative for text interaction (genoffice_app_eval, genoffice_extract_text).

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

• genoffice_app_open_fileA
  3.9/5.0
  Behavior3/5

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

  The description discloses key behaviors: it launches the app normally via macOS open, registers certain document types, doesn't need CDP. Since there are no annotations, this carries the transparency burden. It covers the launch mechanism and platform constraint but doesn't mention what happens if the file is already open, error behavior, or whether it returns any status. Adequate but not rich.

  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?

  Three sentences, each carrying value: what it does, the CDP note, and platform constraint. Efficient and front-loaded with the verb+object. Slightly verbose with the parenthetical about registered document types, but overall no waste.

  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 launch tool with full schema coverage, the description covers the essential context: mechanism, platform, no-CDP requirement, and supported file types. It doesn't explain return behavior or error cases, but for a straightforward launch action this is reasonably complete relative to 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 100% with a single 'path' parameter already well-described as 'Absolute path to the file to open'. The description reinforces that the file types are Office/PDF set. Baseline 3 is appropriate since the schema fully documents the parameter and the description adds marginal context about file type compatibility.

  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?

  Specific verb+resource: 'Open an Office/PDF file... via the macOS open command'. It specifies the exact file types (.docx/.xlsx/.pptx/.pdf) and mechanism (macOS open command). The purpose clearly distinguishes it from sibling tools like genoffice_extract_text or genoffice_docx_patch, which operate on file content rather than launching the app.

  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 when to use it: to open a file in the desktop app. It explicitly notes the app doesn't need CDP running and is macOS only, providing clear context. However, it doesn't explicitly say when NOT to use it or name alternative tools (e.g., when to prefer genoffice_extract_text for content operations). The context is clear but exclusions are missing.

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

• genoffice_docx_watermarkA
  4.1/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the key behavioral traits: header regeneration with watermark paragraph, byte-preserving body roundtrip, new-file output with original untouched. This is meaningful behavioral context beyond a simple 'adds watermark' statement. It could mention failure modes or return value, but the disclosed behavior is substantial.

  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?

  Three sentences, each earning its place: the operation, the empty-string removal behavior, and the safety guarantee about not modifying the original. Concise and information-dense without fluff. Slightly more verbose than the strict minimum but all content is essential behavioral guidance.

  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 3-parameter watermarking tool with 100% schema coverage and no output schema, the description adequately covers the operation, side effects, removal behavior, and safety. It lacks explicit mention of prerequisites (e.g., whether GenOffice engine must be running) but that appears to be an operational concern rather than a description gap for this tool's purpose.

  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 100%, with each of the three parameters adequately described in the schema (path as absolute source path, text with empty-string semantics, outPath with default filename pattern). The description adds the byte-preserving and header-regeneration context but doesn't add parameter-level detail beyond the schema. Baseline 3 is appropriate since the schema carries the heavy lifting.

  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?

  Clear verb+resource: 'Set a text watermark on a .docx using the GenOffice engine.' It specifies the operation (watermarking), the target file type (.docx), and distinct behavior (regenerating the header while preserving body bytes). The description distinguishes this from sibling docx tools (extract_text, blocks, patch, create, delete) by describing a specific mutation purpose.

  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 states the byte-preserving roundtrip behavior and that empty string removes the watermark, giving clear operational context. It also notes the tool writes a NEW file and never modifies the original, which guides safe usage. However, it doesn't explicitly say when NOT to use this tool or name alternatives among siblings (e.g., when to use docx_patch instead).

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

• genoffice_extract_textA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that output is markdown-ish with slide/table structure, and that it's a read-only extraction. However, it doesn't disclose behavior for unsupported formats, large files, binary content limitations, or what happens with password-protected files. For a read-only tool with no annotations, this is adequate but not rich.

  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?

  Two sentences covering purpose, input scope, output format, and use case. Zero filler. It's slightly redundant in restating file extensions that already appear in the schema (and in the parameter description), but it's efficiently front-loaded and every sentence earns its place.

  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?

  Despite no output schema and no annotations, the description conveys format, structure, and intended usage. It informs the agent what to expect (markdown-ish text with slide/table structure). Given a single parameter fully documented and no nested complexity, the description is largely complete; it could mention failure modes (unsupported file types) but that's a minor gap for a straightforward extraction tool.

  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% with a single 'path' parameter, and the description reinforces it by restating the supported file extensions (.docx, .xlsx, .pptx, .pdf). The description adds the absolute-path requirement contextually and confirms supported types, which complements the schema's extension list. With 100% coverage and one parameter, the value-add is modest but present.

  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?

  Specific verb (extract) + resource (readable text from Office/PDF files) + explicit format list (docx/xlsx/pptx/pdf). The return type (markdown-ish text with slide/table structure) is clearly stated. This clearly distinguishes it from the numerous sibling genoffice_*_patch/create/delete tools, which are mutation-focused.

  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?

  Explicitly says 'Use this to read the content of a document before editing it,' which anchors the primary use case and differentiates it from sibling editing tools. It doesn't enumerate 'when not to use' nor mention alternatives by name, but the preceding sentence establishes clear context, and the pre-edit framing is sufficient since the siblings are self-evident mutations.

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

• genoffice_pptx_createA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses that it creates a NEW file with one blank slide and writes to outPath, which is reasonably transparent. However, it doesn't mention whether an existing file at outPath gets overwritten/destroyed, or any error conditions (e.g., if outPath directory doesn't exist).

  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?

  Three sentences, front-loaded with the core action, and zero wasted words. Every sentence conveys distinct, useful information about purpose, deferred behavior, and file destination.

  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?

  For a simple 1-parameter creation tool with no output schema, the description is mostly adequate. However, it lacks disclosure about overwrite behavior and what the return value is. Given no annotations, a bit more behavioral coverage (e.g., 'will overwrite existing file') would help.

  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% (single outPath param fully documented). The description restates that outPath is where the file is written, which adds marginal value echoing the schema. Baseline 3 is appropriate since schema does the heavy lifting.

  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 specific verb+resource (create a .pptx from scratch using createBlankPptx) and scope (one blank slide, written to outPath). It distinguishes from sibling genoffice_pptx_patch by explicitly saying to use that afterwards.

  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 what this tool does NOT do (doesn't fill in content) and directs the agent to use genoffice_pptx_patch afterwards. This is clear when-to-use and when-not-to-use guidance with an explicit named alternative.

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

• genoffice_pptx_deleteA
  4.1/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full behavioral disclosure burden. It does well: discloses it's a delete operation (irreversible for the output), explains the byte-preserving rebuild behavior (other slides/zip parts keep original bytes), clarifies source file is never modified (via schema too), and states it writes a new file. This is rich behavioral context for a mutation tool with zero annotation coverage.

  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 two-sentence block that is information-dense and front-loaded with the core purpose. However, the parenthetical about byte-preserving is somewhat long and technical, potentially adding cognitive load that could be simplified. It's not wasteful, but the ebracing of implementation detail slightly reduces clarity of the overall action.

  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 deletion tool with no output schema and no annotations, the description covers the key operational details: what's deleted, how elements are matched, the non-destructive source behavior, and that a new file is written. Combined with 100% schema coverage of parameters, the tool is well documented. No output schema means it can't describe return values, but the description compensates for the mutation-tool gaps well.

  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 100%, so the schema already documents all four parameters with descriptions. The description adds the context that elements come from genoffice_pptx_slides, which reinforces the schema's parameter description of 'Element names or ids to delete'. Per baseline rules, 3 is appropriate when schema does the heavy lifting; the description's added value over schema is marginal but present.

  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 uses specific verb+resource+scope: 'Delete one or more text/shape elements from a slide of a .pptx using the GenOffice engine'. It explicitly names the tool family (GenOffice), what it deletes (elements), the source (slide of .pptx), and the matching mechanism (by name or id from genoffice_pptx_slides). This clearly distinguishes it from siblings like genoffice_pptx_patch (which edits) and genoffice_pptx_create (which creates).

  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 states what it does and references genoffice_pptx_slides as the source for element names/ids, giving the agent context on prerequisites. It notes 'Writes a NEW file' clarifying it doesn't modify in place. However, it doesn't explicitly state when NOT to use this vs alternatives like genoffice_pptx_patch for element modification, so it stops short of 5.

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

• genoffice_pptx_slidesA
  4.1/5.0
  Behavior3/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 states the operation opens a file and lists slides/elements, implying read-only behavior, but doesn't explicitly state it's non-destructive, mention failure modes (e.g., invalid path, corrupt file), or describe performance characteristics. The open operation's side effects on the GenOffice engine are unclear.

  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, zero waste. First sentence defines the action and output; second sentence gives usage guidance. Front-loaded with the core purpose.

  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?

  The tool is relatively simple (1 param, no output schema, no annotations), so the description covers the essentials. However, without annotations and output schema, it doesn't describe what the returned text preview structure looks like or whether the open operation requires the app to be launched first (sibling genoffice_app_launch suggests a dependency). This is adequate but slightly under-specified for a tool with zero structured metadata.

  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% (only the 'path' parameter, clearly described as absolute path to the .pptx). The description doesn't add parameter details beyond the schema, but the single parameter is self-explanatory. Baseline 3 is appropriate given full 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?

  Description states specific verb+resource (opens .pptx with GenOffice engine) and clearly lists what output is delivered (every slide with id, name, type, text preview). It distinguishes itself from genoffice_pptx_patch by positioning as a pre-edit inspection tool.

  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 instructs to use BEFORE genoffice_pptx_patch and explains the purpose (identify which slide and element to edit). This gives clear sequencing guidance and names the alternative tool it pairs with.

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

• genoffice_app_statusA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It correctly discloses it is read-only and does not launch anything, and explains what 'live' means for the process version. However, it doesn't disclose edge-case behaviors like what happens if the app isn't installed or the port is down, or describe the shape of the returned status object.

  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?

  Three sentences, zero waste. Every sentence earns its place: purpose, return values, and read-only behavior are all covered concisely with the most important behavioral caveat ('does not launch anything') queued at the end. Well front-loaded.

  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 zero-parameter status-check tool, the description is essentially complete. It covers what's checked, what's returned, and the safety profile. The only minor gap is not describing the structure/type of the returned status payload, but with no output schema and 0 params, the description does a solid job for the tool's low 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?

  The tool takes 0 parameters (schema coverage 100%, 0 params), so per the rubric, a baseline of 4 applies. The description doesn't need to document parameters but adds value by explaining exactly what is verified and returned, which helps the agent understand the tool's inputs/outputs conceptually.

  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 uses a specific verb ('check') with a clear resource (GenOffice app installation and CDP debug port). It lists the exact return values (app bundle version, process version, page title/url), making its purpose distinct from sibling tools like genoffice_app_launch or genoffice_app_eval.

  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 clearly states what is checked (installation, debug port) and explicitly notes it is read-only and does not launch anything, which distinguishes it from sibling genoffice_app_launch. However, it doesn't explicitly state when to use this vs. alternatives or include when-not guidance, though the read-only declaration implies when it's appropriate.

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

• genoffice_docx_blocksA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses that it lists top-level blocks (and not deeper nesting) which is useful, but does not state error behavior for invalid paths, file-size limits, or whether it only handles paragraphs/headings/tables. No contradiction present, adds modest context about 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?

  Two tight sentences with zero waste. The first states the operation and output; the second gives actionable placement guidance. Every word earns its place.

  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 simple single-parameter read tool with 100% schema coverage, the description is complete: it states the operation, the output shape (index/type/style/text), and the intended workflow. It doesn't discuss pagination or large-file behavior, but given the simplicity this is sufficient.

  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 only one parameter (path), fully described as 'Absolute path to the .docx file.' The description confirms it operates on .docx files but adds no additional format or constraint detail 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?

  Specific verb+resource (Parse a .docx with the GenOffice engine) and clearly lists the output (top-level blocks with index, type, style, text). Distinguishes from siblings by naming genoffice_docx_patch as its downstream counterpart.

  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?

  Explicit when-to-use guidance: 'Use this BEFORE genoffice_docx_patch to pick the block indexes you want to rewrite.' This clearly positions it as a prerequisite step and names the alternative/successor tool.

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

• genoffice_docx_deleteA
  4.2/5.0
  Behavior4/5

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

  With zero annotations provided, the description carries the full burden of behavioral disclosure, and it does well: it discloses the byte-preserving roundtrip behavior (deleted blocks spliced out, remaining blocks keep original bytes), notes the source is never modified ('never modified' in schema, writes a NEW file), and indicates default output naming. This is meaningful safety-critical context for a mutation-like delete tool.

  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?

  Three sentences of zero waste. The first sentence states purpose and mechanism, the second gives the indexing source, the third flags the new-file behavior. Every sentence carries distinct information with no redundancy or filler.

  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 delete tool with full schema coverage, no output schema, and clear indexing source referencing, the description is largely complete. It explains the mechanism, source relationship, and file-writing behavior. Minor gap: it doesn't describe what the output/return value looks like after deletion (e.g., whether it returns the new path or a count of deleted blocks), though with no output schema defined this is a small omission rather than a critical one.

  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 100%, so the schema fully documents all three parameters (path, indexes, outPath). The description adds value by clarifying the indexes semantics (0-based visible order from genoffice_docx_blocks) which the schema only partially hints at ('from genoffice_docx_blocks'). The outPath default naming is also reinforced. Since the schema already covers the parameters well, a baseline 3 is appropriate with modest added 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?

  The description clearly states the verb (delete), the resource (top-level blocks/paragraphs/headings from a .docx), and the key mechanism (byte-preserving roundtrip). It distinguishes from siblings like genoffice_docx_patch (patching) and genoffice_docx_create (creation), and specifically references genoffice_docx_blocks as the source of indexes, making its role in the family 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 explicitly states that indexes come from genoffice_docx_blocks (0-based visible order), which is the key prerequisite. It clarifies that the source file is never modified and that a new file is written. However, it doesn't explicitly enumerate when NOT to use this tool versus genoffice_docx_patch or mention any restrictions (e.g., cannot delete specific paragraphs vs whole blocks), so it stops short of a full when/when-not explanation.

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

• genoffice_docx_createA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full transparency burden. It discloses key creation semantics: builds a new file, writes to outPath, each string becomes a paragraph, enables line breaks within a paragraph. This behavioral detail (paragraph mapping and line-break handling) goes beyond what the schema states. Missing info about overwrite behavior or return values, but the write-target is explicit.

  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?

  Three sentences, focused and front-loaded with the core purpose. The paragraph interpretation detail is valuable but the parenthetical is slightly dense. Overall efficient with no wasted 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 simple 2-param creation tool with 100% schema coverage and no output schema, this is largely complete. The paragraph-to-paragraph mapping is explained, line-break handling is documented, and the write target is specified. Could mention what it returns or overwrite behavior, but for a straightforward creation tool the coverage is adequate.

  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%, so baseline is 3. The description adds real value beyond the schema: it maps array elements to paragraphs, explains that strings map 1:1 to paragraphs, and details handling for line breaks within paragraphs. The outPath parameter gets additional clarity as the write destination. This exceeds what the schema alone provides.

  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?

  Clear verb+resource: 'Create a NEW .docx from scratch' distinguishes it from siblings like genoffice_docx_patch and genoffice_docx_watermark which modify existing files. Names the engine function (buildBlankDocx), adding implementation context. The 'NEW' emphasis explicitly differentiates from patch/delete/watermark 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?

  States when to use it (creating from scratch) and what optional content can be passed. Doesn't explicitly name alternatives or state when NOT to use, but 'Create a NEW .docx from scratch' effectively implies it's the creation tool versus the sibling modification tools. Could be stronger with explicit exclusion guidance towards patch tools.

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

• genoffice_app_evalA
  4.4/5.0
  Behavior4/5

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

  No annotations were provided, so the description carries the full burden. It discloses the read-only default, the mutate=true requirement to change the page, the CDP (Chrome DevTools Protocol) mechanism, and the prerequisite that the app must be running with a debug port. This is solid behavioral disclosure given zero annotation coverage, although it doesn't detail error behavior or edge cases.

  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?

  Three short, dense sentences deliver purpose, usage guidance, behavioral constraints, and prerequisites with zero wasted words. Information is front-loaded with the core action first, followed by safety behavior and usage context.

  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 2 parameters, no output schema, and no annotations, the description covers the purpose, the safety model (read-only vs mutate), the prerequisite (debug port), and the use case distinction from siblings. It could mention the return value format (what the evaluation result looks like) but given no output schema and moderate complexity, it is reasonably 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?

  Schema coverage is 100% and both parameters have descriptions in the schema. The description adds meaningful context by clarifying the 'mutate' parameter's read-only default and the implication that mutation requires explicit opt-in, which reinforces but does not merely duplicate the schema. The expression example (document.title) is embedded in the schema, not the description, but the description's context adds 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?

  Description uses specific verb+resource: 'Evaluate a JavaScript expression in the GenOffice app page context over CDP.' It clearly states DOM reads/writes capability and distinguishes from sibling read tools by noting it covers 'UI state that the read tools do not cover.' The purpose is fully clear and precise.

  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 states when to use it ('for inspecting UI state that the read tools do not cover') and mentions the mutability toggle explicitly. However, it does not explicitly name alternative tools (though it implies genoffice_extract_text and screenshot as the read tools) nor does it explicitly state when NOT to use it beyond the implication.

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

• genoffice_pptx_patchA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden — and it delivers richly. It discloses the byte-preserving behavior (only edited elements regenerated, untouched elements zip parts keep original bytes), the formatting template derivation from the first run/paragraph, the multi-line paragraph behavior, and the critical safety property of never modifying the original. This is exemplary disclosure for a patching tool.

  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 efficient — three sentences covering purpose, mechanism, formatting behavior, and safety. It front-loads the core action first. Slightly long for what it conveys but every sentence earns its place with distinct information.

  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 has 4 params (100% schema coverage), no output schema (whose absence means no return-format obligation), and involves a nondestructive-but-mutating operation, the description is fully complete. It explains the patching mechanism, formatting constraints, multi-line handling, and output-path default behavior. No gaps that would mislead an agent.

  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% (all 4 parameters documented in schema), so baseline is 3. The description adds context by explaining \n creates one paragraph per line and that the first run/paragraph is used as formatting template — connecting to the 'text' parameter's behavior. It adds modest value beyond the schema but the schema already does heavy lifting for path/outPath/slide 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 'Replace the text of one or more text elements on a slide of a .pptx' — a specific verb (replace) + resource (.pptx slide text elements). It distinguishes from siblings by naming 'GenOffice element-level byte-preserving patching' and explicitly contrasting with regenerate-all approaches. The scope (one slide, text-only) is precise.

  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 byte-preserving behavior, says it writes a NEW file and never modifies the original, and clarifies formatting template behavior (first run/paragraph) and how \n creates paragraphs. It doesn't explicitly name sibling alternatives (e.g., genoffice_pptx_create for new files, genoffice_pptx_delete for removals), but the context is sufficiently clear for when to use this tool vs creating/editing whole files.

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

• genoffice_app_launchA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full disclosure burden, and it delivers: it reveals that a non-CDP running instance is terminated first ('single-instance lock would otherwise swallow the relaunch'), that killExisting controls this destructive behavior, that auto-updater relaunches are handled via retry-until-port-answers, and platform-specific launch mechanics. This is rich, honest behavioral disclosure beyond what any annotation would provide.

  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 and front-loaded with purpose, then covers the critical destructive behavior, the retry logic, and platform details—all in four sentences with zero wasted words. Slightly longer than strictly necessary, but every clause earns its place given the nuanced CDP/auto-updater/kill behavior it must convey. Minor deduction for the parenthetical redundancy on killExisting.

  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 single boolean parameter, the absence of an output schema, and complex runtime behavior (CDP port, single-instance lock, auto-updater relaunch), the description covers all essential facets: what happens on launch, when termination occurs, how the retry loop works, and platform differences. An agent would have everything needed to invoke this tool correctly and predict its side effects.

  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% and the single parameter (killExisting) has a descriptive schema entry ('Kill a running instance without CDP first (default true)'). The description reinforces this by mentioning killExisting=false as an abort option. There's a slight duplication of schema info in the description, but the description adds context on WHY this matters (single-instance lock swallowing relaunch), providing marginal value on top of 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 uses a specific verb+resource ('Launch the installed GenOffice app with the CDP debug port open') and clearly states its purpose—enabling the agent to drive the app via screenshots and DOM evaluation. It distinguishes itself from sibling tools by being the sole launch tool; siblings like genoffice_app_screenshot and genoffice_app_eval assume the app is already running, while genoffice_app_status checks state.

  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 explains when to use it (to start the app so it can be driven) and key behavioral context: if the app runs without CDP, it's terminated, with killExisting=false as an escape hatch. It also covers platform differences (macOS `open -a` vs binary launch). While it doesn't name alternative sibling tools explicitly, the context makes the use case unambiguous.

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

• genoffice_docx_patchA
  4.7/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well: it discloses that the original file is never modified (writes a new patched file), explains the byte-preservation mechanism (untouched blocks keep original bytes, only edited blocks regenerated as OOXML fragments), and states that paragraph formatting (styleId/rawPPr) is carried over. It does not disclose error conditions or edge cases, but covers the core behavioral guarantees clearly.

  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 well-structured, front-loaded single paragraph starting with the primary action, followed by the key guarantee (byte-preserving), then input/output format. Every sentence adds meaningful information with zero waste. The input/output mention at the end is compact.

  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?

  For a 3-parameter tool with 100% schema coverage and no output schema, this is complete: it explains the byte-preserving mechanism, the index sourcing dependency, the input format, the output behavior, and the safety guarantee (never modifies original). The sibling genoffice_docx_blocks is explicitly referenced for index sourcing, which is the key inter-tool dependency. No output schema exists, but the description clarifies the output is a new patched file.

  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%, so the baseline is 3. The description adds value beyond the schema by explaining the edits format [{index, text}] and clarifying that index refers to the 0-based visible order from genoffice_docx_blocks, which is essential meaning not fully captured in the schema alone. It also confirms that formatting is carried over, which the schema doesn't state.

  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 has a specific verb+resource ('Rewrite paragraphs of a .docx using the GenOffice byte-preserving roundtrip') and clearly distinguishes from siblings by emphasizing the byte-preserving property and the 'patch' nature (regenerate only edited blocks). It names the sibling genoffice_docx_blocks for index sourcing, which differentiates it well from create/delete/watermark tools.

  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 states that index values come from genoffice_docx_blocks (0-based visible order), providing a clear dependency. It states when to use this tool (to edit paragraphs without disturbing other parts) and implicitly distinguishes from genoffice_docx_delete (which removes blocks). The byte-preserving guarantee gives clear context for when this is the right choice over other patch tools.

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