Word AI

by flyfish-dev

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.8.6
Disambiguation4/5
Most tools have distinct purposes, with detailed descriptions helping to differentiate. However, there are a few aliases and overlapping tools (e.g., docx_outline and docx_get_outline; docx_validate and docx_compare_structure) that could cause confusion.
Naming Consistency4/5
The naming follows a consistent pattern of domain prefix (docx_, word_session_, officecli_) followed by verb_noun. Minor inconsistencies exist, like docx_table_to_csv vs. docx_export_table_csv and the alias docx_outline, but overall it is predictable.
Tool Count3/5
63 tools is high for a single server. While the domain is broad and the tools are mostly justified, some redundancy and alias tools could be consolidated. The count feels slightly excessive for the scope.
Completeness5/5
The tool surface is remarkably comprehensive, covering reading, writing via PatchSet, Word session integration, validation, backup/restore, and auxiliary inspection. There are no obvious missing operations for the stated purpose of DOCX manipulation and automation.
Average 3.1/5 across 63 of 63 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on June 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Read-only' implying no mutation, but with no annotations provided, the description carries full burden. Missing details on whether the tool requires file locks, network access, or has side effects beyond reading. Information about return format or error conditions is absent.
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?
At two sentences, it is concise, but the lack of substantive content makes it under-specified rather than efficiently informative. Every word does not earn its place because the description fails to convey actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the tool's purpose, inputs, outputs, or behavior, leaving the agent with insufficient information to use it correctly.
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 description coverage is 0%. The description only mentions 'Defaults to the .NET Open XML backend when available' for the engine parameter. No explanation of docx_path or patchset parameters, leaving the agent without guidance on required inputs or format expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Read-only. Alias-grade PatchSet planning assessment' but fails to define what a PatchSet planning assessment is or how it differs from sibling tools like docx_assess_patchset or docx_preflight_patchset. The term 'Alias-grade' is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 such as docx_assess_patchset or docx_preflight_patchset. The description merely notes a default backend preference, which does not help an agent decide between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it is a write operation and restores from backup, but it does not disclose important behavioral traits such as required permissions, potential data loss, or the relationship between backup_path and restore_path. Without annotations, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two words plus one sentence), but it omits critical information. The 'Write.' prefix is unclear and does not add value. Conciseness is not beneficial when it sacrifices clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no annotations, and no output schema, the description is entirely inadequate. It fails to explain prerequisites (e.g., valid backup file), side effects, or the relationship between the paths. The agent cannot effectively use this tool.
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 has no parameter descriptions (0% coverage) and the tool description does not explain the meaning of backup_path, restore_path, or make_backup_of_current. The agent cannot determine which parameter is the source or destination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Restore from backup and optionally back up replaced file first,' which gives a general idea but doesn't differentiate from the sibling tool 'docx_restore_backup' or clarify the specific rollback context. The 'Write.' prefix is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 versus alternatives like docx_backup or docx_restore_backup. The description lacks any context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a write operation ('Write.'), which is helpful, but provides no details on consequences like overwriting or error handling. With no annotations, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively brief, missing essential details. While it is short, it sacrifices clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters, no output schema, and no annotations, the description fails to cover return values, error conditions, or prerequisites, leaving the agent underinformed.
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 explain the parameters 'backup_path' or 'target_path.' The phrase 'to target_path' gives minimal hint, but it's insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Restore a backup to target_path,' which identifies the action and resource. However, it does not differentiate from sibling tools like docx_rollback or docx_backup, and the initial 'Write.' is redundant.
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 versus alternatives or what prerequisites are needed. The description lacks context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description carries full burden. It states 'Read-only' (no mutation) and the backend default behavior. However, it does not disclose what the comparison report looks like, any side effects, or how the tool behaves with various parameters. Critical behavioral context is missing.
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?
Description is only two sentences, but it is not optimally structured. It includes minor details like backend default but omits more important info. It is concise but at the cost of completeness.
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 the tool complexity (12 parameters, structural comparison), the description is incomplete. No output schema is provided, and the description does not describe the comparison logic, the meaning of 'structural comparison', or how parameters control the behavior. Many sibling tools exist, but this description does not help the agent decide.
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 description coverage is 0%, meaning no parameter descriptions in schema. The description does not mention any parameters (e.g., engine, strict, touched_para_ids). Agents cannot infer the meaning or usage of the 12 parameters from this description. This is a severe gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'structural comparison' and 'Same validation report', indicating a comparison tool. However, it is vague and does not specify what exactly is compared (e.g., paragraphs, tables). Among siblings like docx_validate and docx_text_diff, distinction is minimal. The purpose is clear enough but lacks specificity.
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 versus alternatives. It mentions 'Read-only' and a backend default, but does not compare to siblings like docx_validate or docx_text_diff. The agent is left to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It indicates a read operation ('read') and JSON output format, but does not mention side effects, permissions, rate limits, or whether it is destructive. More context is needed.
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 short (one sentence) but contains filler words ('Optional,' 'auxiliary') that do not add value. It front-loads the read purpose but lacks structured organization. It is adequate but not optimally concise.
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?
For a tool with 4 parameters, no output schema, and no annotations, the description fails to provide enough context. It does not explain what 'issues' are, how parameters affect output, or what the JSON output looks like. The agent cannot reliably use this tool without additional knowledge.
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 description coverage is 0%, and the description adds no information about the four parameters (limit, docx_path, issue_type, max_output_chars). The agent must infer parameter usage from names alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a read operation with JSON output for 'formatting/content/structure evidence,' implying it checks for issues in a document. However, it does not explicitly link to DOCX or clarify what 'issues' means, leaving ambiguity. Sister tools like 'docx_health_check' suggest a more precise purpose.
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?
Only describes itself as 'Optional OfficeCLI auxiliary read,' offering no guidance on when to use this tool over alternatives like 'docx_health_check' or 'officecli_validate.' No conditions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only declares read-only behavior. With no annotations, it fails to disclose what happens when no footnotes/endnotes exist, performance implications, or permission requirements. This is insufficient for full transparency.
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 with no wasted words, but it is under-specified, sacrificing completeness for brevity. It meets a minimal standard but is not optimally informative.
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 the large set of sibling tools and no output schema, the description is too vague. It does not explain the return format, whether it lists or counts notes, or the effect of max_preview. Substantial gaps exist.
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 adds no meaning for either parameter (docx_path or max_preview). The description does not mention these parameters at all, leaving the agent with no guidance.
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 inspects footnotes/endnotes and is read-only, specifying a specific verb and resource. However, it does not differentiate it from similar sibling tools like docx_list_parts or docx_inspect.
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 versus alternatives. The phrase 'when present' implies conditional usage but lacks explicit context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses 'Read-only' (a safety trait) but fails to mention error behavior, prerequisites, or any side effects. The mention of returning 'hash/complexity' adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loads 'Read-only', but it sacrifices clarity on purpose and parameters. Some structure is sacrificed for brevity.
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 the number of sibling tools and no output schema, the description is incomplete. It does not explain the return format or how to use the parameters effectively, leaving the agent without sufficient context to select or invoke correctly.
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 coverage is 0%, so the description must explain parameters. It mentions 'paragraph_index or paraId' but provides no details on their meaning, format, or which one to prefer. The schema only defines types and required status, lacking semantic help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Read one paragraph' which clearly identifies the action and resource, but the output description 'hash/complexity' is vague and does not fully clarify the tool's purpose. It is not a tautology, but lacks precision.
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 versus alternatives like docx_list_paragraphs or docx_extract_plain_text. The description only says 'Read-only' but does not explain the context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions default naming and sidecar-only context, but fails to describe other key traits like file creation permissions, output location, or whether the operation is destructive.
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 extremely brief with two sentences and no extraneous wording. However, the brevity sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters (2 required), no output schema, and no annotations, the description fails to cover essential details like the role of table_index, docx_path, or scope_tag. The agent would likely be underinformed.
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% (no parameter descriptions in schema). The description only hints at the out_path parameter ('default naming when out_path is omitted'), but provides no information about docx_path, table_index, or scope_tag.
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 states the tool exports a table to CSV, and mentions behavior when out_path is omitted. This clearly identifies the verb and resource, though it does not distinguish from the sibling docx_export_table_csv beyond the 'Write-sidecar only' note.
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?
Only a vague constraint 'Write-sidecar only' is given. No explicit guidance on when to use this tool versus alternatives like docx_export_table_csv or docx_read_table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'Does not modify the DOCX', which is useful, but omits details about error behavior, performance, or side effects. The short text does not compensate for the lack of annotations.
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 concise (2 sentences), but it sacrifices essential information for brevity. While not wasteful, it fails to include parameter details or usage context, making it less effective than a slightly longer description would be.
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 the complexity of 6 parameters and no annotations or output schema, the description is far from complete. It does not explain return values, file size limits, or supported image formats, leaving critical gaps for an agent to use the tool properly.
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?
The input schema has 6 parameters with 0% description coverage, and the tool description adds no information about parameters beyond docx_path and output_path. Parameters like page, screenshot_width, and max_output_chars remain unexplained, forcing reliance on schema names alone.
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 it renders a DOCX screenshot/PNG to an output path, which is a specific verb+resource. However, the phrase 'Optional OfficeCLI auxiliary sidecar export' adds confusion without clarifying its role versus siblings like officecli_view_html.
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 versus alternatives (e.g., officecli_view_html, docx_extract_plain_text). The description does not mention any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral trait disclosed is non-modification. No annotations exist, so the description carries full burden. It does not cover prerequisites, error scenarios, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but at the expense of necessary details. A single sentence that omits parameter explanations and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate given the tool has 2 parameters, no output schema, and no annotations. The description fails to provide enough information for correct 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?
With 0% schema description coverage, the description adds no meaning to the two parameters (docx_path, out_path). The agent gets no guidance on their roles.
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?
Clearly states the tool writes .wordai index JSON and does not modify the DOCX. Distinguishes it from sibling tools that modify the document. However, the term 'sidecar' might be unclear to some agents.
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?
Implicitly suggests use for writing index without modifying DOCX, but does not explicitly state when to use this tool versus alternatives like docx_apply_patchset or read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It vaguely suggests non-destructive action ('write-temp', 'dry-run') but does not state whether the tool modifies files, requires authentication, or has rate limits. The backend hint is useful but insufficient.
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 sentences with no extraneous information. It front-loads the key idea ('write-temp', 'same as preflight') and adds one important detail about backend defaults. Every word earns its place.
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 the tool has 4 parameters, no output schema, no annotations, and many siblings (including 'docx_preflight_patchset'), the description is too sparse. It fails to explain what the dry run produces, how it differs from applying a patchset, or the meaning of 'preflight.' The tool name suggests a dry run, but details are missing.
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 coverage is 0%, and the description only hints at the 'engine' parameter ('defaults to .NET Open XML backend'). The other parameters ('docx_path', 'patchset', 'keep_output') are not described, leaving the agent without guidance on their meaning or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'write-temp' and 'same as preflight', which hints at a dry-run simulation, but it is vague and relies on jargon. It does not explicitly state that the tool applies a patchset without permanent changes, distinguishing it from 'docx_apply_patchset' only implicitly.
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 says 'useful for explicit Codex dry-run stage' but provides no explicit guidance on when to use this tool versus alternatives like 'docx_preflight_patchset' or 'docx_assess_patchset'. No when-not-to-use or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It states read-only, which is good. However, it does not disclose pagination, limits, or behavior when file is missing or corrupted. The term 'previews' is vague.
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?
Extremely concise, one sentence. While it wastes no words, it omits important details. Could be slightly expanded to clarify parameters and behavior without losing conciseness.
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 two parameters, no output schema, and no annotations, the description is incomplete. It does not explain the output structure, how 'max_preview' affects results, or how this tool differs from sibling 'docx_extract_comments'.
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 coverage is 0%, so description must compensate. It mentions 'previews' but does not explain 'max_preview' parameter (default 500) or what 'hashes' refer to. 'docx_path' is obvious but still 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?
Clearly states it is read-only and extracts comments previews, author/date/id, and hashes. The verb 'list' suggests enumeration, distinguishing it from potential extraction tools. However, it does not differentiate from sibling 'docx_extract_comments' which likely has similar purpose.
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 when to use or when not. No mention of alternatives among the many sibling tools. The tool is described as read-only, implying safe usage, but no guidance on context or priority.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool is a write operation ('Write.'), uses validation before commit, and defaults to .NET backend. However, it omits side effects (e.g., overwriting existing files), error behavior, or whether changes are reversible.
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 two sentences with no fluff, but the first word 'Write.' is abrupt and could be integrated. Overall efficient but could benefit from a clearer structure (e.g., separating input, behavior, output).
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 the tool's complexity (patchset validation, engine choice, audit JSON output) and absence of output schema, the description lacks essential context. It does not define 'constrained PatchSet', what validation entails, or how audit JSON is handled. Sibling tools are similar, making this insufficient.
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 description coverage is 0%, yet the description adds no specific parameter details. It mentions 'constrained PatchSet' and 'new DOCX' but does not explain docx_path, output_path, patchset, or engine parameters, leaving the agent to guess their meaning and constraints.
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 states 'Apply constrained PatchSet to a new DOCX plus audit JSON', clearly indicating the tool's action (apply) and resource (PatchSet to a new DOCX). However, it does not differentiate from sibling tools like word_session_apply_patchset, and the word 'constrained' is vague without further explanation.
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 versus alternatives. The description mentions 'validation gates final commit' but does not advise on prerequisites or workflow order relative to docx_assess_patchset, docx_preflight_patchset, or docx_dry_run_patchset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly labels the tool as 'Read-only', which is essential behavioral information given no annotations. It hints that 'include_text' controls visibility of text. However, it lacks details about return format, side effects, or behavior when 'include_text' is true/false.
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 extremely concise (one sentence) with important qualifier 'Read-only' front-loaded. It wastes no words. However, the brevity sacrifices some helpful detail, and a slightly longer description could improve clarity without losing conciseness.
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 no output schema, no annotations, and 0% schema description coverage, the description is incomplete. It does not explain return values, what 'counts' or 'anchors' entail, or how parameters affect output. For a tool with two parameters and many siblings, more detail is needed.
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 description coverage is 0%, so the description must explain parameters. It only mentions 'optional visible text', which vaguely relates to 'include_text', but does not describe 'docx_path' or define 'include_text' semantics. This leaves the agent guessing parameter usage.
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 is read-only and inspects 'counts, anchors and optional visible text'. This identifies the action and objects, distinguishing it from siblings like docx_read_anchor or docx_extract_plain_text. However, it does not specify what is being counted (e.g., paragraphs, tables), which could reduce clarity.
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 versus alternatives. The sibling list includes many specific read and inspect tools, but the description offers no context about trade-offs, prerequisites, or scenarios where docx_inspect is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must shoulder the burden. It only states 'read-only' but omits other behavioral traits like whether the file must be loaded, performance implications, or error conditions.
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 single-sentence and efficient, but could be improved by separating parameter details or adding structure for better scannability.
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 no output schema, two parameters with zero schema descriptions, and many sibling tools, the description is insufficient. It does not explain what a 'manifest' entails, return format, or how sizes are represented.
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%, yet the description only hints at `include_hashes` by mentioning 'optional SHA-256 hashes'. The `docx_path` parameter is entirely unexplained.
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 it is read-only and outputs a DOCX ZIP manifest with part sizes and optional SHA-256 hashes. This distinguishes it from generic listing tools like `docx_list_parts` and hash-specific tools like `docx_part_hashes`, though not explicitly.
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 versus alternatives such as `docx_list_parts` or `docx_part_hashes`. The description lacks context about prerequisite conditions or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the tool as read-only ('Does not modify the DOCX'), which is critical behavioral info. However, lacks details on output characteristics, performance, side effects, or constraints like the meaning of 'bounded' or how input parameters affect behavior.
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?
Only two sentences but first sentence includes redundant phrasing ('Optional OfficeCLI auxiliary read') that could be omitted. The structure is front-loaded with the key action, but some words are wasted.
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 3 parameters with no schema descriptions and no output schema, the description is insufficient. It does not specify output format, parameter effects, or usage nuances, making it incomplete for effective tool 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?
With 0% schema description coverage, the description adds no meaning to parameters (page, docx_path, max_output_chars). It does not explain their format, purpose, or constraints, leaving a significant gap.
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?
Description clearly states it renders a DOCX to an HTML snapshot for visual evidence and notes it does not modify the DOCX. However, the phrase 'Optional OfficeCLI auxiliary read' is somewhat vague and does not strongly differentiate from sibling tools like officecli_view_screenshot.
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 versus alternatives (e.g., officecli_view_screenshot). The term 'auxiliary read' weakly implies a supplementary role, but no clear context or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It mentions 'hash preconditions, audit, and rollback PatchSet,' which are important. However, it does not detail failure modes, required permissions, or effects of parameters like wait or timeout.
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 a single sentence that packs in information, but it is somewhat dense and could be more structured for readability. It is not excessively long.
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 four parameters, no output schema, and no annotations, the description is insufficient. It fails to specify return values, error conditions, or prerequisites like session existence, making it incomplete for reliable use.
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 description coverage is 0%, yet the description provides no explanation of the four parameters (patchset, session_id, wait, timeout_seconds). This is a critical gap for an agent to correctly invoke the tool.
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 states the tool applies a PatchSet to a Word document, which is a specific verb+resource. However, it does not distinguish from siblings like docx_apply_patchset or docx_dry_run_patchset, which have similar purposes.
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. The description mentions 'hash preconditions, audit, and rollback' but does not clarify when those apply or when to prefer other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly states the tool is non-destructive ('does not modify DOCX') and writes a sidecar file. However, it lacks details on whether it overwrites existing files, permissions needed, or what 'visible body text' excludes (e.g., headers/footers).
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 concise (one sentence), which is good for readability. However, it omits critical information, making it under-specified. Every sentence earns its place, but more is needed.
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 the tool has two parameters, no output schema, and no annotations, the description is incomplete. It does not specify whether 'out_path' is optional, the default output name, or the text encoding. Among many sibling tools, this one lacks context to distinguish its exact purpose.
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%, so the description must compensate. It provides no explanation of the 'docx_path' or 'out_path' parameters, such as their purpose, format, or default behavior. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports visible body text to .txt and does not modify the DOCX. However, it does not differentiate from the similarly named sibling tool 'docx_extract_plain_text', which likely performs the same function.
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 versus alternatives like docx_extract_plain_text or other export tools. The phrase 'Write-sidecar only' hints at a use case but is not explicit about prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Behavioral transparency is minimal. The description notes it is read-only, but fails to disclose what happens if the file is missing, if no bookmarks exist, or any side effects. Annotations are absent, so the description should compensate.
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 (one sentence) and front-loaded with 'Read-only', which is good. However, it could be more informative without sacrificing conciseness.
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 tool with one parameter and no output schema, the description is somewhat complete in stating the purpose. However, it lacks details about return value format, error conditions, or edge cases, which would be helpful.
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 description coverage is 0% and the description provides no details about the required 'docx_path' parameter, such as expected format or path resolution. The agent gets no help understanding parameter semantics.
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', the resource 'bookmarks and paths', and the purpose 'for cross-reference preservation'. It distinguishes from siblings like docx_list_anchors since bookmarks are a specific feature.
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 such as docx_list_anchors or docx_list_headings. The description only says 'Read-only' but does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'Read-only' without annotations to reinforce. It doesn't disclose behavior on missing headings, multiple matches, or performance impact. The safety profile is implied but not detailed.
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, front-loaded sentence with no filler. Every word adds meaning.
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?
With 4 parameters and no output schema, the description omits return format, error handling, and detailed param usage. Insufficient for complete understanding.
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 coverage is 0%, but the description explains heading_anchor_id and heading_text as identification methods. However, docx_path and max_chars are left undocumented, leaving gaps.
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 'Read one heading section by heading anchor_id or exact heading text', specifying the verb (read), resource (heading section), and two identification methods. It distinguishes from siblings like docx_list_headings or docx_read_anchor, though it could be more explicit about what 'heading section' entails.
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 docx_read_anchor or docx_list_headings. The 'Read-only' prefix hints at safety but doesn't explain prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It labels the tool as an 'auxiliary read', suggesting no destructive side effects, but fails to mention required dependencies, error behavior, or output format details. The description is insufficient for a mutation-capable tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two brief sentences. The first sentence is somewhat cryptic ('Optional OfficeCLI auxiliary read'), but the second clearly states the main action. No extraneous content.
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 the tool has no output schema, no annotations, and many siblings, the description omits critical context: prerequisites (e.g., OfficeCLI), the nature of validation results, and return format. It does not adequately prepare an agent to use the tool correctly.
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?
The description provides no information about the two input parameters (docx_path and max_output_chars), despite 0% schema description coverage. The schema itself lacks descriptions, so the tool is entirely opaque regarding parameter semantics. The description must compensate but does not.
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 validates DOCX using OfficeCLI with JSON output, and positions it as auxiliary after Word AI validation. It distinguishes from sibling 'docx_validate' by noting the OfficeCLI backend, but doesn't explicitly differentiate from other validation tools.
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 as a secondary validation step ('after Word AI validation') and as 'extra evidence', providing some context. However, it offers no explicit guidance on alternatives, when not to use, or prerequisites like OfficeCLI installation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a write operation ('Write') but does not disclose behavioral traits like destructiveness, prerequisites (e.g., required taskpane state), error conditions for missing selection, or side effects. With no annotations, the description should provide more detail.
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 very short (two brief sentences) and front-loaded with the key action. However, it sacrifices necessary detail for conciseness.
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 5 parameters and no output schema or annotations, the description is incomplete. It fails to explain return values, prerequisites, or parameter interactions, leaving significant gaps for an AI agent.
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%, yet the description only mentions 'tag/title' without explaining parameters like wait, session_id, or timeout_seconds. It does not map these to specific fields or clarify their roles, leaving the agent without necessary semantics.
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 wraps the current Word selection in a content control with a stable tag/title. The verb 'wrap' and resource 'current Word selection' are specific. It distinguishes from sibling tools like word_session_read_content_control, which are read-only.
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 versus alternatives such as docx_apply_patchset or other document manipulation tools. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden for behavioral disclosure. It only states 'Read-only', which is minimal. It does not describe what 'full metadata' entails, return format, error conditions, or performance implications.
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 exceptionally concise with two short phrases, but it sacrifices informational completeness. It earns a high score for brevity but not for substance.
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 a single parameter, no output schema, and no annotations, the description should compensate with richer details. It does not describe return values, data structure, or potential errors, making it insufficiently complete.
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 coverage is 0% and the description does not elaborate on the sole parameter 'docx_path'. It fails to clarify that this is the path to the .docx file, leaving the agent to infer from context.
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 verb 'Extract' and the resource 'full comment metadata and text', indicating read-only operation. While it does not explicitly differentiate from the sibling 'docx_list_comments', the use of 'extract' versus 'list' implies more comprehensive retrieval.
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 indicates the tool is read-only, advising safe usage without modifications. However, it provides no explicit guidance on when to use this tool versus siblings like 'docx_list_comments' or other extraction tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry transparency burden. It states 'Read-only.' indicating no document modification, but lacks details on output format, performance, or any other behavioral traits. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (8 words) and front-loaded with 'Read-only.' Every word serves purpose, but could be slightly expanded to improve completeness without sacrificing brevity.
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 no output schema and simple parameter, description is insufficient. It fails to describe the exact output (relationship IDs, alt metadata format) or any usage context. Leaves gaps for practical use.
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?
Single parameter docx_path has 0% schema description coverage. Description adds no meaning beyond the parameter name and type. Does not clarify expected format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists drawing/pict objects (images) and returns relationship IDs and alt metadata. Verb 'list' on resource 'images' is specific and distinguishes from siblings like docx_list_parts or docx_list_paragraphs.
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 other listing tools (e.g., docx_list_paragraphs, docx_list_content_controls). The 'Read-only' prefix hints at safety but doesn't help select among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but only states it is read-only. It does not disclose pagination behavior, performance implications, or whether the preview truncates content. The list of returned fields is helpful but insufficient for a complete behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 14-word sentence that front-loads the key behavioral trait ('Read-only') and lists the returned fields. Every word earns its place; no redundancy or fluff.
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 three parameters and no output schema, the description should explain parameters and return format more thoroughly. It omits how include_empty affects results and does not describe the structure of the returned inventory. The tool's complexity requires more detail for a complete understanding.
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 description coverage is 0%, yet the description adds no meaning to the three parameters (docx_path, max_preview, include_empty). It mentions 'preview' in the returned data but does not clarify max_preview. The description fails to compensate for the missing schema documentation.
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 is a read-only paragraph inventory that returns specific attributes (style, paraId, heading level, scope, preview, hash, complexity). This distinguishes it from sibling tools like docx_read_paragraph (single paragraph) or docx_list_headings (only headings), making its purpose precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. While 'Read-only' implies safety, it does not explain contexts where this tool is preferred over docx_read_paragraph or docx_list_headings. Sibling tools are numerous, and the description offers no comparative rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'Read-only' implying no destructive side effects, and mentions return hash for write preconditions. However, it does not explain what the hash is, or any other behavioral details like error handling or resource locking.
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 concise (13 words), which is efficient, but it omits essential information such as parameter details and output format. It is front-loaded with 'Read-only', but overall it is too minimal to be fully effective.
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 the complexity (6 parameters, no output schema, no annotations), the description is insufficient. It does not explain the return value beyond a 'hash', nor does it cover error conditions, prerequisites, or the meaning of 'write preconditions'. The tool's role is partially clear but incomplete.
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 description coverage is 0%, and the description provides no information about any of the 6 parameters (col, row, docx_path, table_index, max_chars, scope_tag). The description fails to compensate for this gap, leaving agents unable to understand parameter roles.
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 verb 'Read' and resource 'single table cell', and adds that it returns a hash for write preconditions. This distinguishes it from sibling tools like docx_read_table, but the return value could be more explicit.
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 'Read-only' tag implies it is for reading, not writing, but no explicit guidance on when to use this tool over alternatives like docx_read_table or docx_read_paragraph. The description lacks exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It labels 'Write' but does not detail side effects, failure modes, or state changes. It is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a 'Write.' prefix, making it concise. However, it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description lacks critical information about return values, prerequisites, and parameter semantics. It is far from complete.
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 description coverage is 0%, so the description must explain parameters. It only mentions 'rollback PatchSet' and fails to clarify the purpose of wait, command_id, session_id, timeout_seconds, or rollback_patchset, adding no value beyond schema names.
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 rolls back a previous word_session_apply_patchset command by applying a rollback PatchSet. It uses a specific verb and resource, distinguishing it from siblings like docx_rollback.
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 after a word_session_apply_patchset but does not explicitly state when to use vs alternatives, nor when not to use. It lacks exclusions or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly labels the tool as 'Read-only', which informs the agent that it does not modify documents. However, with no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention performance implications, file size limits, or output format details beyond 'human review'.
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 extremely concise—a single sentence of eight words. It gets straight to the point, but its brevity sacrifices necessary parameter and usage details. It is front-loaded with the key purpose and read-only nature, earning points for efficiency, but not fully self-contained.
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 two required string parameters (presumably file paths) and one optional integer, the description lacks crucial context about what the diff output looks like, how the 'context' parameter affects it, or its relationship to validation. No output schema exists to compensate, so the description should provide more depth.
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?
With 0% schema description coverage, the description must explain parameters but fails to do so. It does not mention that 'source_docx' and 'target_docx' are required file paths, nor does it explain the 'context' integer parameter (default 2) which likely controls diff context lines. This omission severely hinders correct usage.
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 'Unified visible-text diff for human review', which specifies the tool's purpose as generating a readable diff of visible text. It distinguishes itself from sibling tools like 'docx_compare_structure' (structural diff) and 'docx_extract_plain_text' (plain text extraction) by focusing on visible text for human review.
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 phrase 'after validation' hints at a specific point in the workflow but provides no explicit guidance on when to use this tool versus alternatives like 'docx_compare_structure' or 'docx_list_revisions'. It lacks when-not-to-use instructions and does not mention prerequisites or recommended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the operation does not modify the original document, which is a key behavioral trait. However, it does not mention whether backups can overwrite previous ones, permission requirements, or any side effects beyond the sidecar creation. The description adds value but is minimal.
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 a single concise sentence, but it is arguably too minimal. It lacks critical information about parameters and output, making it efficient but incomplete. It would benefit from additional structure, such as separate lines for purpose and parameters.
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 the absence of output schema and parameter descriptions, the description should compensate by outlining return values (e.g., path to backup file) and parameter details. It does not, leaving the agent uninformed about the backup location or how to specify a custom directory. Sibling tools for restore suggest the backup format matters, but no info is provided.
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 description coverage is 0%, and the description does not explain either parameter (docx_path, backup_dir). The agent must infer meaning from parameter names alone, which is insufficient for correct invocation, especially since backup_dir's default behavior or format is unclear.
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 creates a timestamped backup ('Create timestamped backup') and explicitly notes it does not modify the original DOCX. It also specifies 'Write-sidecar only,' distinguishing it from potential siblings that might modify the original. The verb and resource are specific.
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 the tool is for creating backups ('Write-sidecar only') but does not explicitly state when to use it versus alternatives like docx_restore_backup or docx_rollback. No when-not or explicit context is provided, only a hint of safety ('does not modify original').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool does not modify the DOCX and writes a sidecar, but fails to mention error handling, permissions, or sidecar overwrite behavior. With no annotations, more behavioral detail is needed for full transparency.
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 crisp sentences with no wasted words. Key constraints (write-sidecar, non-destructive) are front-loaded, making it easy to parse.
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?
For a tool with 4 parameters, no output schema, and no annotations, the description is too minimal. It does not address return values, error scenarios, or parameter dependencies. The presence of similar sibling tools increases the need for completeness.
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 description coverage is 0%, and the description only partially mentions out_path being optional. It does not explain docx_path, table_index, or scope_tag, leaving their meaning and constraints entirely to the schema.
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 it exports a table to CSV without modifying the DOCX, using 'Write-sidecar only'. However, it does not differentiate from the sibling tool docx_table_to_csv, which may have similar functionality, reducing clarity.
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 via 'Write-sidecar only' and mentions default sidecar naming, but lacks explicit guidance on when to use this tool versus alternatives, such as docx_table_to_csv. No prerequisites or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It declares 'Read-only' which is good for safety, but lacks details about behavioral traits such as ordering, filtering, performance, or whether it includes all occurrences. The description is adequate but minimal.
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 a single sentence, very concise, and front-loaded with 'Read-only.' However, it is under-specified given the number of siblings and parameters. It could be expanded to include parameter details without losing conciseness.
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 has no output schema, 2 parameters with 0% coverage, and many sibling tools. The description fails to explain what a 'stable editing anchor' is, how max_preview affects the output, or what the return format looks like. Many gaps remain.
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?
The input schema has 0% description coverage, meaning the JSON schema does not describe any parameters. The tool description also does not explain what docx_path or max_preview mean. This fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is read-only and lists stable editing anchors: content controls, headings, bookmarks, and paraId paragraphs. It distinguishes itself from sibling tools like docx_list_headings and docx_list_bookmarks by combining multiple anchor types into one.
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 the tool is for listing all stable anchors at once, but it does not explicitly state when to use this tool over more specific siblings like docx_list_headings or docx_list_bookmarks. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It correctly states 'Read-only' and enumerates the data returned. However, it does not disclose potential errors (e.g., file not found), performance considerations, or any other behavioral traits such as file locking or auth requirements. For a tool with no annotations, this is minimally adequate but incomplete.
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 concise: one sentence that communicates the core purpose and return attributes. It is front-loaded with the 'Read-only' flag. Every word is informative without redundancy. However, it could benefit from a slightly more structured enumeration of attributes.
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 the tool has 2 parameters with no descriptions in the schema, no output schema, and a large set of sibling tools, the description should provide more context. It does not explain the parameters, describe the output format (array, object?), or specify the required file path. While it lists the return fields, crucial details for correct usage are missing. The tool's simplicity (list with basic fields) partially compensates, but completeness is still lacking.
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 schema has 0% description coverage, meaning the parameters docx_path and max_preview have no descriptions in the schema. The tool description does not explain what these parameters represent or how to use them. The agent must infer that docx_path is the file path and max_preview controls preview length. This is insufficient for correct invocation, especially since docx_path is required.
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 lists content controls and specifies the returned attributes (tag, alias, id, preview, text hash, complexity). However, it does not explicitly differentiate from sibling tools like docx_read_content_control, which likely reads a single content control. The verb 'list' sufficiently implies its function but lacks explicit exclusion.
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 begins with 'Read-only', which implies safe usage without modifications. However, it does not provide guidance on when to use this tool versus alternatives like docx_read_content_control or other listing tools. There is no mention of prerequisites or conditions under which it is appropriate to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It declares read-only nature, which is essential for safety. However, it does not disclose other behaviors such as whether it returns all tables, performance characteristics, or any limitations on the preview rows (e.g., max_cell_chars parameter). Adequate but not comprehensive.
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?
Extremely concise: three short phrases that convey the core purpose and read-only nature. No redundant words, and key information is front-loaded.
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 no output schema and many sibling tools, the description is too sparse. It does not explain what 'scope tags' or 'complexity' mean, whether all tables are listed, or the format of preview rows. Assumes significant domain knowledge.
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 adds no explanation for either parameter. 'docx_path' and 'max_cell_chars' are not described; the latter's purpose is only weakly implied by 'preview rows'. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is read-only and lists the specific information it returns: table dimensions, scope tags, complexity, and preview rows. This provides a precise verb-resource combination and distinguishes it from siblings like docx_read_table which read full table content.
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 versus alternatives like docx_read_table or docx_export_table_csv. The description mentions 'read-only' and 'list', but does not clarify use cases or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals key behaviors: writing to a temporary copy, validating, removing output unless keep_output is true, and default backend. This is fairly transparent, though details on validation scope and error handling are missing.
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 with minimal waste; 'Write-temp.' is slightly cryptic but still efficient. The description is front-loaded with key action and outcome.
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 the complexity (4 params, no output schema) and absence of parameter descriptions, the tool description is incomplete. It does not explain what validation entails or how to use the engine parameter, leaving significant gaps for an agent.
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 description mentions only keep_output implicitly and does not explain docx_path, patchset, or engine parameters. With 0% schema description coverage, the tool description fails to add meaning beyond the schema, leaving agents without guidance on parameter usage.
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 specifies a dry-run operation on a patchset, using a temporary copy and validation, which clearly states the verb and resource. However, it does not differentiate from the sibling tool docx_dry_run_patchset, leaving ambiguity about unique functionality.
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 versus alternatives like docx_dry_run_patchset or docx_apply_patchset. The description implies use before applying, but lacks direct statements on when not to use or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 declares 'Read-only' and mentions return fields, but fails to disclose behaviors like whether search covers non-visible text, how regex/case sensitivity work, or any potential side effects. The disclosure is minimal.
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 a single sentence, which is concise, but it omits crucial details for a tool with 6 parameters and many siblings. The brevity compromises completeness, making it insufficient for effective agent use.
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 the tool's complexity (6 parameters, no output schema, many siblings), the description lacks details on return structure beyond field names, error handling, or how parameters affect behavior. It does not adequately differentiate from sibling tools or cover edge cases.
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?
The schema has 6 parameters with 0% description coverage. The description does not explain any parameter meaning, syntax, or constraints, leaving the agent entirely dependent on parameter names and defaults. There is no added value from the description.
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 searches visible paragraph text and returns specific fields (paraId, index, scope, hashes). It distinguishes from siblings by specifying 'search visible paragraph text' as opposed to reading all text or specific paragraphs.
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 searching text in the document, but does not explicitly clarify when to use this tool over siblings like docx_read_paragraph or docx_extract_plain_text. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool is read-only, which is a key behavioral trait. Without annotations, it adequately covers the safety profile, but lacks details on performance, permissions, or output format. For a simple read tool, this is acceptable but not thorough.
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 very short and to the point, with no filler. However, it sacrifices parameter clarity for brevity, missing an opportunity to add value in the single sentence.
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 the lack of output schema and unclear parameter, the description is incomplete for an agent to use confidently. The tool's purpose is clear, but the agent cannot determine the required input format or the exact structure of the output.
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?
The single parameter docx_path has no description in the schema (0% coverage) and the tool description does not clarify its meaning, format, or constraints. An agent would not know how to specify the path correctly without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is read-only and provides a heading outline with section paragraph ranges, specifically for large-document chunking. This distinguishes it from sibling tools like docx_outline or docx_list_headings, which likely do not include paragraph ranges.
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 large-document chunking, but does not explicitly state when to use this tool vs alternatives like docx_outline or docx_list_headings. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only' and 'without modifying them', which is sufficient for a read operation. However, it does not disclose potential errors or behavior when headers/footers are absent. Since no annotations are provided, the description carries the full burden, but the information is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. It is concise but lacks structured presentation. Every sentence earns its place, though the content is sparse.
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?
No output schema is provided, and the description does not specify what the tool returns (e.g., a list of headers/footers with text). Given the tool's simplicity, a description of the return format is necessary for 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 schema has 0% parameter description coverage and the description does not explain the parameters (docx_path, max_preview). The description adds no value beyond what the schema provides, leaving the agent to guess the meaning of max_preview.
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 inspects header/footer parts and visible text without modification. It uses a specific verb ('inspect') and resource ('header/footer parts'), distinguishing it from siblings like docx_list_parts or docx_inspect.
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. It does not provide context, prerequisites, or exclusions, leaving the agent to infer from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'read-only' and 'previews and hashes' but lacks details on side effects, permissions, or return format. The minimal description leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that packs essential information (read-only, heading-focused, previews, hashes). No wasted words, though slightly more structure could improve clarity.
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?
No output schema exists, and the description does not explain what the tool returns (e.g., list of headings with previews and hashes). For a tool with this potential complexity, the description is too incomplete for safe agent invocation.
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 coverage is 0% with no descriptions for the two parameters. The description mentions 'previews' but does not explain 'docx_path' or 'max_preview' syntax or purpose. The description fails to add 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 it is 'Read-only' and provides a 'Heading-only view with previews and hashes.' This directly defines the tool's purpose and distinguishes it from sibling tools like docx_list_paragraphs or docx_get_outline.
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 the tool is used for headings, but it does not provide explicit when-to-use guidelines or compare with alternatives like docx_get_outline or docx_read_heading_section. The agent must infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only 'Read-only' is disclosed; no information about error handling, output format, or side effects is provided. With no annotations, the description carries full burden and is insufficient.
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 concise with no wasted words, but extremely short; a slight expansion would not hurt conciseness.
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 the single parameter and no output schema, the description lacks details on return value, examples, or how the tool integrates with other operations, leaving the agent underinformed.
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 sole parameter 'docx_path' is self-explanatory, but the description adds no additional meaning or context, and schema description coverage is 0%.
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 'Inspect numbering.xml numId/abstractNum mappings' with a clear verb and resource, distinguishing it from sibling tools like docx_list_styles or docx_map.
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 read-only inspection, but no explicit guidance on when to use this vs. alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool is read-only and does not modify the document, which is critical behavioral information. However, with no annotations provided, it lacks details on what 'validate and preview' entails (e.g., return value, UI interaction, or side effects like displaying a prompt).
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 concise (one sentence plus 'Read-only' prefix) and front-loaded with the key behavior. Every word adds value, though it could be slightly improved by briefly noting the output or side effects.
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 the complexity (4 parameters, no output schema), the description is insufficient. It does not explain the return value, the preview mechanism, or how to interpret the result. Agents would need external knowledge to use this tool effectively.
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?
With 0% schema description coverage for all 4 parameters, the description provides no explanation of what 'wait', 'session_id', 'timeout_seconds', or 'patchset' mean. This leaves the agent guessing about parameter semantics beyond their types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to validate and preview a PatchSet without modifying the document. It specifies the 'read-only' nature and the target (Office.js taskpane). This distinguishes it from sibling tools like 'docx_apply_patchset' which modify the document.
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 non-destructive preview before application, but does not explicitly mention when to use or not use this tool versus alternatives like 'docx_dry_run_patchset' or 'word_session_apply_patchset'. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Read-only' indicating non-destructive behavior, but with no annotations, it lacks details on side effects (e.g., UI changes), session requirements, or latency. The read-only nature is disclosed, but other traits are omitted.
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 very concise and front-loaded with 'Read-only.' It achieves clarity in a single sentence, but does not waste words. However, it could be slightly more informative without losing conciseness.
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 being a simple tool, the description lacks essential context such as the need for an active session, relationship to sibling tools, and return behavior. No output schema is provided, and parameter info is missing, making it incomplete for reliable agent 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?
The description provides no information about the three parameters (wait, session_id, timeout_seconds). With 0% schema description coverage, the description fails to compensate, leaving the agent without guidance on how to use these 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 it is a read-only operation that refreshes the open-document content-control snapshot via the Office.js taskpane. This is specific and distinguishes it from sibling tools that read, list, or modify content controls.
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 refreshing a snapshot but does not explicitly state when to use this tool over alternatives like word_session_read_content_control or docx_list_content_controls. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately states 'Read-only,' indicating no side effects. While no annotations are present, the description does not provide additional details on error handling or performance, but it is adequate for a simple listing 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?
The description is a single concise sentence that front-loads the key information ('Read-only. List field instructions'), with no wasted words.
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 the number of sibling tools and lack of output schema, the description is too minimal; it does not hint at the return format or how the list is presented, leaving the agent without sufficient context for correct usage.
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 description coverage is 0%, and the description does not mention the parameters 'docx_path' or 'max_preview' at all, leaving the agent without any guidance 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 explicitly states 'List field instructions' and provides concrete examples (TOC, REF, PAGEREF, SEQ), making the tool's purpose clear and distinguishing it from sibling tools like docx_list_parts or docx_list_headings.
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 labels the tool as 'Read-only,' implying it is safe for inspection without modification. However, it does not explicitly specify when to use it versus alternatives (e.g., docx_inspect) or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It correctly states 'Read-only' indicating no destructive side effects, but does not disclose performance implications, authentication needs, or behavior for large files. The list of included elements provides some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the tool's purpose and scope without any unnecessary words. Every part adds value.
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 the absence of an output schema and the complexity of the tool (producing a map of multiple document aspects), the description is insufficient. It does not explain the return structure, how to interpret the map, or any constraints. Parameter descriptions are entirely missing, leaving significant gaps.
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?
The description provides no explanation of the three parameters (docx_path, max_preview, include_text). With 0% schema description coverage, the description must compensate but fails entirely, leaving the agent to infer meanings from defaults and names.
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 this is a read-only tool that produces a map of various document elements (health, headings, anchors, paragraph chunks, table summaries, hashes). It specifies verb 'map' and resource 'docx', distinguishing it from sibling tools that focus on individual elements.
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 labels it 'Read-only' implying safe use, but does not explicitly state when to use this tool over siblings like docx_list_headings or docx_list_tables. It implies usage as a comprehensive overview, but lacks contextual guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It explicitly states 'Read-only', which discloses non-destructiveness. It does not describe error behavior (e.g., missing anchor), rate limits, or output format (since no output schema). It adds basic context but lacks depth for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without any extraneous words. Every token serves a clear function, making it easy to parse quickly.
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 the tool has 3 parameters (1 optional), no output schema, and no annotations, the description is too minimal. It does not explain the optional max_chars parameter or the nature of the returned text (e.g., plain text vs. formatted). Agents would need external knowledge to use it effectively.
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 description coverage is 0%, and the description does not explain any parameter beyond anchor_id's source. docx_path and max_chars are not mentioned, leaving the agent to infer their meaning from the schema types alone. The description fails to add value over the raw schema.
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 ('Read'), the resource ('text behind an anchor_id'), and the prerequisite tool ('docx_list_anchors'). It distinguishes from siblings like docx_list_anchors by specifying a different operation. However, the phrase 'behind an anchor_id' is slightly ambiguous, though context makes it understandable.
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 implicitly tells when to use this tool: after listing anchors with docx_list_anchors. It does not explicitly exclude alternatives or provide when-not-to guidelines, but the coupling with the sibling tool is clear. Among the sibling tools, this is the only one that reads text by anchor ID, so usage context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states 'read-only' but lacks details on session requirements, error states, or what happens if tag not found. For a tool with no annotations, this is insufficient.
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, no extraneous words. Front-loads 'read-only' and action. 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?
With 4 parameters, 0% schema coverage, and no output schema, the description is too brief. Lacks details on parameter meaning, return values, and prerequisites.
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 coverage is 0%, but description only mentions 'tag' implicitly. No explanation of wait, session_id, timeout_seconds. Parameters are not documented beyond 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 reads content-control text from an open Word document by tag, using Office.js taskpane. It distinguishes from file-based tools like docx_read_content_control.
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 read-only usage and mentions 'by tag', but does not explicitly state when to prefer this over siblings or conditions to avoid. Some context from sibling names hints at live document vs file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly labels the tool as read-only, which is critical for an agent to understand it won't modify data. No other behavioral traits (e.g., permissions, rate limits) are mentioned, and there are no annotations to supplement. The backend default is a minor behavioral detail.
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 concise at two sentences, with the core purpose front-loaded. However, it could be structured more clearly, perhaps separating the purpose from the backend default. Still, it is efficient and avoids verbosity.
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 the lack of an output schema and the presence of many similar siblings, more context is needed. The description does not explain what the tool returns (e.g., a report object), nor how it differs from docx_plan_patchset or docx_preflight_patchset. This gap could lead to incorrect tool selection.
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?
Among three parameters, only the 'engine' parameter's default behavior ('Defaults to the .NET Open XML backend when available') is described. The 'patchset' and 'docx_path' parameters receive no explanation, and the schema itself lacks descriptions (0% coverage), leaving the agent to guess their 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 tool is read-only and its purpose: to resolve PatchSet targets and report risks, touched objects, and precondition gaps. This is specific and distinguishes it from write-oriented siblings like docx_apply_patchset.
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 indicates it is read-only, implying it is safe to use without side effects. However, it does not explicitly state when to use this tool versus alternatives like docx_preflight_patchset or docx_dry_run_patchset, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly labels the tool as 'Read-only', which is the primary behavioral trait. No annotations are provided, so the description carries the full burden; it does not mention error handling or output format, but for a simple read operation it is adequate.
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 extremely concise—two fragments totaling 11 words—with no redundancy. It front-loads the key behavioral trait 'Read-only'.
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?
While the description lists what properties are inspected, it does not specify the return structure (e.g., list of sections). For a list tool with no output schema, the description should clarify the output format.
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 single parameter 'docx_path' has no explanation in the description or schema (0% coverage). The description does not clarify expected path format or constraints, providing minimal added 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 tool inspects section properties, margins, page size, and header/footer refs, which aligns with the tool name 'list_sections'. It distinguishes itself from siblings like 'docx_list_parts' by specifying the resource (sections).
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 such as 'docx_inspect' or 'docx_list_parts'. The description only states what it does, not the context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It declares 'Read-only' (safe, no mutation) but lacks details on edge cases (e.g., invalid table_index, empty table, scope_tag filtering behavior). No mention of output format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with vital info front-loaded ('Read-only'). Every word adds value; zero waste. Excellent conciseness.
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?
No output schema exists, yet the description fails to indicate return format (e.g., 2D array, cell content) or error behavior. Missing prerequisites (e.g., valid docx) and parameter details for required fields. Incomplete given the tool's moderate 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 description coverage is 0%, so the description must compensate. It explains table_index and scope_tag's roles but omits docx_path (required) and max_chars_per_cell (default 2000). Partial compensation, leaving two parameters undocumented.
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 'Read a table matrix by table_index and optional content-control scope_tag,' specifying the verb (read), resource (table matrix), and key parameters. It effectively distinguishes this tool from siblings like docx_read_table_cell and docx_export_table_csv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions read-only and optional scope_tag but does not explicitly state when to use this tool versus alternatives like docx_read_table_cell for single cells or docx_export_table_csv for CSV export. Usage context is implied but not expanded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 declares read-only behavior and notes the default backend fallback. However, it does not disclose specifics like error behavior, output format, or what constitutes a failure. The description adds some context but is not comprehensive.
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 very concise (two sentences) and front-loaded with 'Read-only.' It efficiently conveys the core purpose. However, it could benefit from a slightly structured format for readability.
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?
With no output schema and 12 parameters, the description is incomplete. It does not describe return values, how to interpret results, or handle failures. The context around typical use cases and integration with sibling tools is missing.
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%, so the description must explain parameter meaning. It only generically mentions 'touched_*' parameters without detailing each. Parameters like engine, strict, and allow_* are not explained. Given 12 parameters, this is insufficient.
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 is read-only and validates structural invariants. It specifies the action (validate) and the resource (docx structural invariants). It also distinguishes itself from sibling tools by focusing on validation after edits.
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 after making edits by instructing to supply touched_* for intentional edits, but it does not explicitly state when to use this tool versus alternatives like docx_inspect or docx_health_check. No explicit exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description correctly identifies it as a read-only operation. However, it lacks details on response format, error behavior, or performance implications, leaving the agent with incomplete behavioral expectations.
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 brief (three short sentences) with no redundancy. It front-loads the key action and constraints. While efficient, it sacrifices detail that could aid clarity.
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 the lack of output schema and annotations, the description fails to fully specify the tool's behavior. It doesn't mention the document type (implied .docx), does not describe the query syntax beyond 'CSS-like', and omits expected output structure.
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%, so the description must compensate. It explains the 'selector' is CSS-like and output is JSON, but does not clarify 'docx_path' or 'max_output_chars'. The agent is left guessing about the required document path and output limit.
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 is for running CSS-like queries on Office documents, outputting JSON. It is distinct from the numerous docx_* siblings that target specific document parts or actions.
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 says 'Use only for inspection, never mutation' and labels it 'auxiliary', providing some usage context. However, it does not explicitly compare to alternative tools or give conditions when to choose this over similar read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explicitly states 'Read-only', signaling no side effects. However, no annotations are provided, and description lacks details on permissions, rate limits, or return format. Adequate but not thorough.
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 starting with 'Read-only' immediately conveys safety. Extremely concise with no wasted words.
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?
Tool is simple with one optional parameter and no output schema. Description covers core purpose but lacks information about return data structure or behavior when no sessions exist.
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 one parameter (include_inactive), but description does not mention it or explain what 'active' means. With 0% schema description coverage, description fails to add 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?
Description clearly states 'List active Office.js taskpane sessions', using a specific verb and resource. It also specifies 'Read-only', distinguishing it from mutation tools. Among siblings, it is the only one explicitly for listing sessions.
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 word_session_snapshot or word_session_refresh. Missing context about whether this is a lightweight alternative or for specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only,' which clearly indicates no side effects. It outlines the output components (package parts, hashes, outline, health report), providing a good behavioral summary. Since there are no annotations, the description carries the full burden and does so adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key fact ('Read-only') and efficiently lists the fingerprint components. Every word adds value with no redundancy, making it optimally concise.
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 large number of sibling tools and no output schema, the description is moderately complete. It lists what the fingerprint includes but lacks details on how to interpret the output or why one would choose this over similar composite tools like docx_map. More context would help an agent decide appropriately.
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 coverage is 0%, and the description does not explain the lone parameter 'docx_path.' Although the parameter name is self-explanatory, the description adds no additional semantics or constraints, failing to compensate for the lack of schema 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 produces a 'strong structure fingerprint' including specific components (package parts, hashes, outline, health). This distinguishes it from sibling tools like docx_health_check or docx_part_hashes which focus on individual aspects. However, it doesn't explicitly state it's a composite/summary, slightly reducing clarity.
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?
No explicit guidance on when to use this tool versus alternatives. It's implied that this tool gives a broad overview while siblings are more specific, but no when-not-to-use or alternative directions are given. The description relies on user inference from the component list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on full burden. It explicitly states 'Read-only', indicating non-destructive behavior, and warns against regeneration, highlighting limitations. This adds useful context beyond the tool's name.
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 extremely concise with two short sentences, each serving a clear purpose: stating read-only nature and extraction goal, then a warning. It is front-loaded with key info.
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 simple tool with one parameter and no output schema, the description adequately covers core behavior and limitations. It does not explain return format or full scope (e.g., whether tables are included), but is sufficient for coarse review.
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 only parameter 'docx_path' is not described at all; the description adds no meaning beyond the schema. With 0% schema coverage, the description should compensate but does not, though the parameter is self-explanatory.
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 it extracts visible body text for coarse review, specifying a verb ('Extract') and resource ('visible body text'). However, it does not distinguish from similar sibling tool 'docx_export_plain_text', missing a chance to differentiate.
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 advises 'never use to regenerate DOCX', providing a clear exclusion. However, it lacks explicit guidance on when to use this tool over alternatives like 'docx_export_plain_text', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description starts with 'Read-only' which is good, and lists what it checks. However, it does not disclose behavior about limits, side effects, or performance. Since no annotations exist, the description carries full burden; it provides some transparency but incomplete.
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 front-loaded key information ('Read-only. Conservative stability report:') and a concise list of checked items. Every word earns its place.
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 description lists what the report covers but does not describe output format or return structure. Given no output schema, this is a gap. For a health check tool with only 2 parameters, it is somewhat complete but lacks detail on what 'recommended safety policy' means.
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 schema has 0% description coverage. The description does not explain the parameters (docx_path, max_items) beyond the schema. It lists output contents but not how parameters affect behavior. Minimal added value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'read-only conservative stability report' and lists specific elements it checks (duplicate tags, content controls, fields, etc.), distinguishing it from sibling tools that focus on specific aspects like reading paragraphs or tables.
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 this is a high-level health check, but it does not explicitly state when to use it versus alternatives (e.g., when to use docx_list_comments vs this tool). The usage context is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It declares read-only behavior and hints at preview truncation via 'preview'. However, it does not disclose details about hash computation or relationship targets, but the key behavioral traits (safe, read-only) are communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys purpose and key output details efficiently.
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 description covers the basic purpose and output elements but lacks detail on the return format (e.g., structure of each hyperlink entry) and does not explain the 'max_preview' parameter. Given no output schema, more completeness would be beneficial.
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 explain the parameters. 'docx_path' is obvious, but 'max_preview' is not described beyond the schema. The description fails to add meaning to the parameters, which is critical given zero schema 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 it lists hyperlinks, specifies it's read-only, and mentions what is included (targets, preview, hashes). This distinguishes it from sibling tools that list other document components.
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 read-only usage but does not provide explicit guidance on when to use this tool versus alternatives like docx_list_anchors or docx_search_text. No exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses the tool is read-only, which is a key behavioral trait. However, it does not explain what 'compact' means, return format, performance implications, or whether it accesses the file system (docx_path). More detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It conveys essential information efficiently and is front-loaded with 'Read-only' to immediately inform about safety.
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 tool's simplicity (one parameter, no output schema), the description covers the purpose and invariants use case. However, it lacks details on the output structure (what does the hash map contain?) and what 'parts' refers to. Some completion is missing for full autonomy.
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 has 0% description coverage for the only parameter docx_path. The description does not explain what docx_path is (e.g., path to the DOCX file) or any constraints (e.g., file must exist). This leaves the agent without guidance on how to fill the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a compact DOCX part-hash map and specifies its use case 'for before/after invariance checks'. The verb 'get' is implied, and it distinguishes from siblings like docx_structural_fingerprint by specifying 'part-hash map'. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the tool is for invariance checks, implying use when comparing DOCX state before and after modifications. However, it does not explicitly exclude other uses or contrast with sibling tools that might serve similar purposes (e.g., docx_structural_fingerprint).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes 'Read-only', which is a strong behavioral disclosure in the absence of annotations. However, it does not elaborate on behavior for invalid command IDs, timeouts, or return format details. The annotation burden is fully carried by the description, which only partially addresses it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words. The key attribute 'Read-only' is front-loaded, aiding quick comprehension.
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 status retrieval with one parameter and no output schema, the description covers the core purpose, read-only nature, and return content (status/result/error). It could hint at where to obtain command_id, but is largely complete given the tool's low complexity.
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 0% description coverage (no parameter descriptions). The tool description mentions 'a queued Office.js session command' but does not clarify the format or expected values of command_id. The description adds minimal value beyond the parameter name.
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 returns status/result/error for a queued Office.js session command. It uses a specific verb ('return') and resource ('status/result/error'), and distinguishes itself from sibling tools like word_session_list and word_session_apply_patchset.
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 after queuing a command, but does not explicitly state when to use this tool versus alternatives (e.g., after word_session_apply_patchset). No guidance on prerequisites or error scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. States 'Read-only' (non-destructive) and specifies data source 'styles.xml'. Does not describe output format, but acceptable for a simple listing 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?
Extremely concise at 8 words, front-loads key traits ('Read-only'), no wasted language.
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?
Adequately covers purpose and safety for a read-only list tool with one parameter. Lacks output specification and usage caveats, but sufficient for a straightforward action.
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?
Single param 'docx_path' with 0% schema coverage. Description adds no extra meaning beyond the field name; it merely recontextualizes the path as input to the listing operation.
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 verb 'list', resource 'Word styles', and source 'from styles.xml'. Distinguishes from sibling tools that list other document parts.
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?
Implies usage for style-aware generation but provides no explicit when-to-use, when-not-to-use, or alternatives. The 'Read-only' prefix hints at safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states 'Read-only,' indicating no destructive behavior, and mentions the output includes previews and hashes, adding some behavioral context beyond the input schema.
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 extremely concise—a single sentence that is front-loaded with the key behavioral hint 'Read-only'. Every word is necessary and there is 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?
Given no output schema, the description adequately describes the return type (tracked-change nodes with previews and hashes), which is sufficient for a simple listing tool. However, it lacks details on error behaviors or performance implications.
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 description does not explain the parameters (docx_path and max_preview) beyond their schema definitions. With 0% schema description coverage, the description should compensate, but it only hints at max_preview by mentioning 'previews', leaving the required docx_path unexplained.
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 specifies that the tool lists tracked-change nodes, providing previews and hashes. It uses a specific verb and resource, distinguishing it from sibling tools that list other document elements like paragraphs, tables, or comments.
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 states 'Read-only,' implying safe usage without side effects, but it does not explicitly provide guidance on when to use this tool over alternatives, such as docx_assess_patchset, for revision analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly declares read-only behavior, which is critical for safety. However, no annotations are provided, so the description carries the full burden; it lacks details on return format or side effects but is sufficient for an alias.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads key attributes (read-only, alias). No fluff or 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 simple alias with one parameter, the description is adequately complete. It does not explain return values, but no output schema exists; the agent can infer from the canonical tool docx_get_outline.
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 one parameter (docx_path) with 0% description coverage. The description adds no information about the parameter; the parameter name is self-explanatory but the description does not compensate for the lack of schema documentation.
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 is a read-only alias for docx_get_outline, indicating the tool retrieves a document outline. Distinguishes from siblings by naming the canonical tool.
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?
Mentions it is an alias for docx_get_outline and kept for Codex prompt ergonomics, implying redundancy but not specifying when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It declares 'Read-only' and 'safe edits', indicating non-destructive behavior. But it does not detail what happens if the tag is missing or return format, leaving some ambiguity beyond the immediate read action.
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, no wasted words. Front-loaded with 'Read-only' for immediate clarity. Every word contributes to understanding.
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 read tool with two string params and no output schema, the description is nearly complete. It lacks detail on return value (plain text?) and error cases, but the intended use is clear. Among many siblings, it is specific enough.
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%. The description adds minimal value: 'by w:tag' implies the tag parameter identifies the content control, but docx_path is entirely unexplained. A tool with two required params should describe both, especially the file path.
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 explicitly states 'Read content-control text by w:tag' and 'Read-only', clearly defining the action (read), the resource (content control identified by tag), and the nature (read-only). This distinguishes it from sibling tools like docx_list_content_controls (list) or docx_write_index (write).
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 says 'Preferred primitive for safe edits', implying use for reading before editing, and 'Read-only' clarifies it is safe. However, it does not explicitly state when not to use it or contrast with alternatives like docx_list_content_controls for finding tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explicitly states the tool is read-only and lists what it returns (sizes and hashes). While it lacks details on error behavior or output format, it adequately conveys the non-destructive nature.
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 extremely concise, consisting of one short sentence. It front-loads the critical 'Read-only' qualifier and states the action without any extraneous 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?
Given the tool's simplicity (one parameter, no output schema) and many siblings, the description is mostly complete. It tells what it does and its read-only nature, but lacks comparison to similar tools like docx_package_manifest.
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 single parameter 'docx_path'. It adds no meaning beyond the schema, failing to compensate for the lack of parameter documentation.
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 'all package parts', and specifies the output includes 'sizes and hashes'. This uniquely identifies its function among sibling tools like docx_part_hashes and docx_package_manifest.
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 includes 'Read-only', which clearly indicates this tool is for inspection without modification. However, it does not provide explicit guidance on when to use this tool versus similar siblings or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares 'Read-only' upfront, indicating no destructive side effects. Also explains the fallback behavior with session_id. Given no annotations, the description provides necessary behavioral context, though it could mention any permissions or rate limits.
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 'Read-only.' No wasted words; every sentence adds value. Ideal conciseness.
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?
Lacks output schema and does not describe the return format or structure of the snapshot. While it specifies it is a 'content-control snapshot,' more detail (e.g., JSON array) would improve completeness for an agent.
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?
Only one parameter (session_id) with 0% schema description coverage. The description compensates fully by explaining its optionality and default behavior ('If session_id is omitted, uses the most recently active session.'), adding essential semantics.
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 'Return the latest content-control snapshot for an open Word session.' Verb and resource are specific, and the description distinguishes it from siblings like 'word_session_read_content_control' by focusing on the full snapshot.
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 'If session_id is omitted, uses the most recently active session,' providing clear guidance on parameter usage. However, it does not mention when not to use this tool or alternatives beyond implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![word-ai MCP server](https://glama.ai/mcp/servers/flyfish-dev/word-ai/badges/card.svg)](https://glama.ai/mcp/servers/flyfish-dev/word-ai)

Score Badge

Copy to your README.md:

[![word-ai MCP server](https://glama.ai/mcp/servers/flyfish-dev/word-ai/badges/score.svg)](https://glama.ai/mcp/servers/flyfish-dev/word-ai)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/flyfish-dev/word-ai'

If you have feedback or need assistance with the MCP directory API, please join our Discord server