Office-MCP-Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but a few pairs like add_comment/add_comments and edit_table_cells/edit_table_paragraphs could cause confusion without careful reading. Descriptions sufficiently differentiate them.
Naming Consistency5/5
All tools follow a consistent word_verb_noun pattern (e.g., word_read_document, word_insert_table, word_accept_all_changes), making actions and targets predictable.
Tool Count2/5
With 37 tools, the server is over-sized compared to the typical 3-15 range. While the Word domain is broad, this count feels heavy and could overwhelm agents.
Completeness3/5
Core editing, formatting, tables, comments, and tracked changes are well covered, but several significant gaps exist: headers/footers and footnotes are read-only, and images can only be listed, not inserted or modified.
Average 3.6/5 across 37 of 37 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on August 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Delete paragraphs by paraId' and does not mention the destructive nature's implications, whether track_changes affects reversibility, what happens to paragraph IDs, or any response/return value. The obvious 'delete' implies mutation but no further 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 concise sentence with no filler. It front-loads the action and object, achieving maximum brevity. There is zero waste, making it appropriately minimal for the information it conveys.
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 destructive nature and lack of annotations, the description is too sparse to be complete. It does not explain usage context, alternative tools, track_changes behavior, or the result of the operation. The schema covers parameters well, but the tool's overall behavioral context is absent, making it insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all three parameters, including the meaning of para_ids, file_path, and track_changes. The description's 'by paraId' merely echoes the schema's para_ids property and adds no new semantic detail beyond what the schema already defines.
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 'Delete paragraphs by paraId' clearly states the verb (delete) and resource (paragraphs) with the selection method (paraId). It is unambiguous about the operation but does not explicitly distinguish from sibling tools like word_edit_paragraphs or word_delete_table_paragraphs, relying on the tool name to disambiguate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as word_edit_paragraphs or word_delete_table_paragraphs. It neither offers context nor exclusions, leaving the agent to infer usage from the tool 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?
There are no annotations, so the description must explain behavior. It only says 'read' and 'with anchors' but doesn't specify the return format, whether anchors are identifiers for paragraphs, or any limitations. It doesn't disclose output structure or error behavior.
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 short sentence that is immediately clear and free of filler. It front-loads the verb and resource, making it easy to scan. 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.
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 annotations, the description is incomplete. It doesn't explain what 'anchors' are, what the returned data looks like, or whether all paragraphs are read. For a simple read tool, more detail about the return value is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents file_path as the absolute path to the .docx file, so the description adds no additional parameter meaning. The mention of 'anchors' relates to output, not input parameters, so the description provides no extra 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 reads a Word document's paragraphs and mentions anchors, which distinguishes it from sibling tools that read other document parts like tables or headers. However, 'anchors' is not defined, and there's no explicit differentiation from similar read tools, so a 4 is appropriate.
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 about when to use this tool or how it compares to alternatives like word_get_document_info or word_read_table_structure. The description only states what it does, leaving the agent to 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic operation and nothing about document mutation, tracked changes, or how multiple edits are handled. For a tool that modifies a file, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and free of redundancy. It efficiently conveys the essential action and scope without unnecessary detail.
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 annotations and output schema, the description should provide more context about return values, side effects, and usage expectations. It fails to mention that the document is modified in-place or any behavior around tracked changes, making it incomplete for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already well-documented. The tool description adds no extra meaning beyond the schema, such as syntax details or interplay between parameters, so the baseline score of 3 applies.
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 'find and replace' and the resource 'a Word document's paragraphs', making the core purpose unmistakable. It inherently distinguishes from search-only or paragraph-editing siblings, though it doesn't explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like word_search_text or word_edit_paragraphs. The description does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer usage 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?
With no annotations, the description carries full responsibility, but it only states the action and target file. It does not disclose side effects, prerequisites (e.g., file existence), overwrite behavior for existing style IDs, or any error conditions—significant gaps for a mutation 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 sentence, directly states the action and target, and contains no redundant information—ideal 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?
For a create operation with 9 parameters and no annotations, the description is too minimal. It lacks any explanation of style reuse, when to use this vs direct formatting, or behavioral outcomes. The schema covers parameters, but the overall tool context is poorly filled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the input schema. The description adds no parameter-specific meaning, but the baseline of 3 applies due to complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a clear resource ('custom paragraph style') and location ('Word document's styles.xml'), distinguishing it from sibling formatting tools that apply formatting rather than define reusable styles.
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 word_format_text or word_set_paragraph_formats. The description simply states what it does without explaining the contextual use case 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action, but does not disclose side effects, whether the file is modified in place, idempotency, or any return value. This is insufficient for a mutation 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, direct sentence with no wasted words. It is front-loaded and earns its place, though it sacrifices informativeness 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 lack of annotations and output schema, the description should provide more context about the operation's outcome, such as return values or in-place mutation behavior. It covers neither, leaving the agent with incomplete information for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the file_path parameter (100% coverage) with a clear description. The tool description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('assign'), the resource ('stable paraId anchors'), and the condition ('to any paragraph missing one'). This specificity distinguishes it from sibling tools like word_edit_paragraphs or word_set_paragraph_formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool or how it relates to alternatives. While it implies a use case (paragraphs missing anchors), it does not state prerequisites, exclusions, or contrast with other word 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, and the description only states the deletion action and the removal of anchor markers. It does not disclose irreversibility, permission requirements, behavior on missing comments, or whether related replies are also affected.
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 leads with the verb and object, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two fully documented parameters, but the description lacks context about error handling, return values, and side effects on related document elements. It is minimally adequate but not comprehensive.
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?
Both parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds no additional parameter-level detail beyond identifying the comment to delete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with a clear resource ('a comment') and adds 'and its anchor markers' to define scope, distinguishing it from sibling comment tools like word_add_comment or word_read_comments.
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 about when to use this tool versus the many comment-related siblings (add, read, reply). It does not mention prerequisites (e.g., comment must exist) or alternatives.
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 of behavioral disclosure. It only states the action without explaining side effects, such as whether existing document formatting is overwritten, whether the change is reversible, or if it applies to the entire document. This is insufficient for a mutation 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, front-loaded sentence with no redundant words. It efficiently communicates the core action and resource.
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?
While the parameter schema is thorough, the description lacks behavioral transparency and usage guidance. Since there are no annotations or output schema, the description should provide more context about the effects of applying a preset, but it does not, leaving the agent without a full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters (file_path and preset), so the description adds little extra meaning. The baseline is 3 due to high schema coverage; the description does not provide additional parameter context like format constraints or typical 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 identifies the action ('Apply'), the target resource ('Word document'), and the specific scope ('named page-layout + default-font preset'). It distinguishes from siblings like word_set_page_layout, which likely sets individual layout options rather than using a named preset.
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 predefined presets, but it does not explicitly state when to use this tool versus alternatives like word_set_page_layout or word_format_text. There is no mention of when not to use it or any contrasting guidance.
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 it only states the action 'delete' without disclosing side effects, such as track_changes behavior (default true per schema), what happens to empty cells, or whether the operation is reversible. This is minimal behavioral disclosure.
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 action and scope. Every word earns its place, with no filler or repetition.
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?
As a destructive operation with no annotations and no output schema, the description is incomplete. It does not explain the track_changes default, the effect on document structure, or any return value. The user lacks enough context to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description adds 'by paraId', which reinforces the para_ids parameter but is largely redundant with the schema's description. No additional meaning is provided 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 'Delete paragraphs inside table cells by paraId' uses a specific verb and resource, clearly distinguishing this tool from siblings like word_delete_paragraphs by scoping to table cells. The method (by paraId) is also stated.
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 phrase 'inside table cells' implies the context of use, separating it from general paragraph deletion. However, there is no explicit 'when to use' or 'when not to use' guidance, nor mention of alternatives like word_edit_table_paragraphs for modifying instead of deleting.
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 carries the full burden of behavioral disclosure. It only states the basic replace operation and does not mention whether changes are tracked by default, whether edits are applied in a single pass, what happens if a paraId is not found, or any side effects (e.g., formatting loss). This is insufficient for a mutation 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 leads with the action and object. There is no redundant or filler content; 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?
The tool has 3 parameters (including a nested edits array) and no output schema or annotations. The description is too minimal to convey behavior such as the track_changes default, batch edit semantics, or error handling. It needs more context to be a complete guide for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage with descriptions for file_path, edits, and track_changes. The description adds no additional parameter context beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Replace'), identifies the resource ('text of specific paragraphs'), and specifies the selection method ('by paraId'). This clearly distinguishes it from sibling tools like word_insert_paragraphs and word_delete_paragraphs, which have different operations.
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 editing existing paragraphs by their ID, but it provides no explicit guidance on when to prefer this tool over alternatives like word_set_paragraph_formats or word_replace_texts. No exclusions or alternative suggestions 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 are provided, so the description carries full responsibility for behavioral disclosure. It only states the action without mentioning side effects (e.g., overwriting existing formatting), whether it modifies the file in place, error behavior for invalid para_id, or any other operational details. As a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core purpose. Every word contributes value, with no redundant or 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?
Despite a rich schema, the tool complexity (nested edits array, no annotations, no output schema) demands more descriptive context. The description does not explain batch behavior, whether formatting is additive or replaces existing, or what happens when para_id is not found. It falls short of providing a complete operational picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description adds little beyond listing the formatting types already present in the schema. It does not provide additional syntax, relationships, or edge-case details, making it consistent with the baseline of 3.
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 action ('Apply'), the resource ('run-level formatting... to paragraphs'), and the targeting mechanism ('by paraId'). It explicitly lists the formatting types (bold/italic/underline/font/size/color), distinguishing it from paragraph-level formatting tools like word_set_paragraph_formats.
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 when to use this tool through the phrase 'run-level formatting', indicating character-level styling rather than paragraph-level. However, it does not explicitly name alternatives or state when not to use it, so guidance is largely implicit.
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 of behavioral disclosure. It only states the action without mentioning side effects (e.g., in-place document modification, overwriting existing highlights), the scope of highlighting (whole paragraph vs exact match), or return behavior. This is a significant gap for a mutation 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, front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose, making it highly concise and well-structured.
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 no output schema and no annotations, the description is too thin. It fails to clarify whether the highlight applies to entire paragraphs or exact text matches, what happens to existing highlights, or what the tool returns after modification. The sibling context suggests related tools, but the description itself lacks essential completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal semantic nuance beyond 'search' and 'color' mapping, so the baseline score of 3 applies.
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 action (search and apply highlight) and the resource (text/paragraphs in a Word document). It distinguishes itself from siblings like word_search_text (search only) and word_format_text (general formatting) by specifying the highlighting function.
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 a use case (highlight matching text) but provides no explicit guidance on when to use this tool versus alternatives like word_search_text or word_replace_texts. No exclusions or prerequisites are mentioned, making it minimally adequate but not instructive.
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 only states the basic action and does not disclose failure modes, file modification side effects, track_changes behavior, or reversibility. This is a mutation tool, so such details are important.
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. Every word contributes to the core 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?
Given the existence of word_insert_table_paragraphs, the description is ambiguous about whether this inserts into the main document body or table cells. It also does not mention the track_changes default or success/failure behavior, and there is no output schema to clarify return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema, so the baseline is 3. The description adds no extra semantic value beyond what the schema already provides; it merely mirrors the action and the after_para_id concept.
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 action (insert), resource (new paragraphs), and location (after a given paraId). This distinguishes it from edit/delete paragraph 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 a use case (inserting paragraphs after an existing paragraph found via paraId), but provides no explicit when/when-not guidance or alternatives. It does not mention that word_insert_table_paragraphs exists for table cells.
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 carry the behavioral burden. The description only says 'Insert' and specifies an anchor point, but does not disclose that changes are tracked by default (per track_changes parameter), how the tool handles invalid paraIds, or any side effects. It lacks transparency about the mutation behavior.
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 communicates the essential action and target without any wasting words. It is concise and to the point.
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 (4 params) and lack of output schema or annotations, the description is too thin. It omits important context such as insertion order, behavior when after_para_id is not found, and the default for track_changes. The schema covers parameters but not runtime behavior, leaving the agent with gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no new parameter semantics beyond what the schema already provides; the term 'after a given paraId' merely reiterates the after_para_id parameter's schema 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 action ('Insert new paragraphs'), the target location ('into a table cell'), and the exact insertion point ('after a given paraId'). It distinguishes this tool from siblings like word_insert_paragraphs by specifying 'table cell', making the purpose unambiguous.
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 adding paragraphs to table cells, which gives some context for use. However, it does not explicitly mention when to use this tool instead of alternatives like word_insert_paragraphs or word_edit_table_paragraphs, nor does it state any 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?
No annotations are present, so the description must carry the full burden. It does not explicitly state that the operation is read-only, nor does it disclose what the search returns (e.g., paragraph numbers, matched text snippets). This lack of disclosure could lead to incorrect expectations.
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 is front-loaded with the action and target. Every word earns its place with 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?
With no output schema and no annotations, the description should explain what the result of a search is (e.g., list of matches, locations) and any limitations (e.g., only paragraphs, not headers/footers). None of this is provided, leaving the tool's behavior incomplete for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides, but it does not need to since the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'search' and identifies the resource 'Word document's paragraphs', clearly distinguishing it from siblings like word_replace_texts or word_read_document. The scope of matching text 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 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 such as word_read_document or word_replace_texts. The purpose implies a read-only search, but that is not stated.
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 disclose behavioral traits. It only states the operation itself and the target (by paraId) but does not mention whether existing formatting is replaced, what happens if a paraId is not found, any error conditions, or whether it is a mutation with side effects. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently captures the tool's purpose without wasted words. It is appropriately sized for the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a batch mutation with no output schema and no annotations, yet the description provides no information about return values, error handling, or prerequisites. While the schema covers parameters adequately, the description alone does not give enough context for an agent to understand the full scope of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters (file_path, edits with para_id and optional formatting fields). The description adds no additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies paragraph-level formatting (alignment, spacing, indent) targeting paragraphs by paraId. This specific verb+resource+scope distinguishes it from sibling tools like word_format_text (character formatting) and word_edit_paragraphs (content editing).
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 when paragraph formatting such as alignment, spacing, or indent needs to be applied, but it does not provide explicit guidance on when to prefer this tool over alternatives like word_set_headings or word_edit_paragraphs, nor does it mention exclusions or prerequisites.
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 carries the full burden. It does not disclose side effects, error behavior on invalid paraId, return values, or whether the operation modifies the document in a reversible manner. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is efficient and free of clutter. 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 tool is simple and all parameters are documented, but without annotations or output schema, the description leaves gaps around behavioral expectations (side effects, error cases). It is adequate for a basic call but not fully complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds slight context about the para_id anchoring but does not meaningfully go beyond the 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 a specific action (add), the resource (a single comment), and the anchoring target (paragraph by paraId). It also distinguishes from the sibling 'word_add_comments' by emphasizing 'single'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding a single comment anchored to a paragraph, but does not explicitly contrast with alternatives like word_add_comments (plural) or mention when to use one over the other. The 'single' wording provides some differentiation, but no explicit when/when-not guidance.
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 of behavioral disclosure. It states the file creation but does not disclose behavior when the file already exists (overwrite vs. error), whether parent directories are created, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and includes optional behavior without any fluff. It is appropriately sized and easy to parse.
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 core purpose and optional parameter, but without annotations or output schema, it omits important context like behavior on existing files and return values. It is adequate for a simple creation tool but not fully robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes both parameters. The description rephrases 'file_path' as 'given path' and 'initial_paragraphs' as 'seeded with paragraphs', adding no additional meaning or constraints 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 creates a new .docx file at a given path, using a specific verb ('Create') and resource. It distinguishes from sibling tools which are for editing, reading, or converting, and mentions the optional paragraph seeding, making the purpose unambiguous.
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 is given on when to use this tool versus alternatives. The creation purpose is implied but no alternatives or exclusions are mentioned, leaving the agent to infer context from the tool name and description.
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 carries the full burden of behavioral disclosure. It only states the basic replace action without mentioning side effects, reversibility, permissions, or the track_changes parameter that defaults to true. This is a significant gap for a mutation 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 communicates the core function immediately. It has no superfluous words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple structure with 3 parameters fully described in the schema, but the description itself omits important context such as the ability to apply multiple edits in one pass (mentioned in the schema) and the default track_changes behavior. Without an output schema, the description could provide more context about expected outcomes or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all parameters, including para_id and text. The description adds little beyond what the schema already provides; it references paraId and text but does not clarify formats, constraints, or usage details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Replace the text'), the specific resource ('a specific paragraph inside a table cell'), and the identification method ('by paraId'). This distinguishes it from siblings like word_edit_paragraphs (general paragraphs) and word_edit_table_cells (editing entire cell content).
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 editing paragraphs within table cells but provides no explicit guidance on when to use this tool versus alternatives like word_edit_paragraphs or word_edit_table_cells. It does not state exclusions or mention alternative tools, so usage is implied rather than explicit.
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 bears full responsibility for behavioral disclosure. It states only the action ('Read all comments') without clarifying whether replies or resolved comments are included, what the return format is, or what happens when no comments exist. This lack of context leaves significant ambiguity.
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 directly communicates the tool's purpose with no unnecessary words. It is well-structured and front-loaded.
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 read tool with one parameter, the description is reasonably complete, but it does not explain return values or the scope of 'comments' (e.g., including replies or resolved comments). Since there is no output schema, this missing information lowers the completeness score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter (file_path) with a clear description. The tool description does not add extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and the resource 'all comments in a Word document', clearly distinguishing it from sibling comment tools like add_comment, reply_to_comment, and delete_comment. It clearly states what the tool does.
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?
Usage is implied (read comments from a Word file), but the description does not explicitly mention when to use this tool over alternatives such as word_read_document or word_read_table_structure. No exclusions or alternative guidance 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?
With no annotations, the description carries full responsibility for disclosure. It gives one behavioral detail (anchored to same paragraph) but omits side effects, return behavior, permissions, or whether the document is modified in place. This is insufficient for a mutation 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, tightly worded sentence with no redundancy. It leads with the verb and resource, making it efficient and easy to parse.
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 add-operation with full schema coverage and no output schema, the description provides the essential purpose. However, it lacks details about return values, preconditions, or side effects, leaving the tool's complete context only partially addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds minimal semantic context beyond the schema—only that the reply is anchored to the same paragraph, which relates to comment_id but doesn't elaborate on parameter constraints or relationships.
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 the action ('Add a reply comment') and the resource ('an existing comment'), and distinguishes it from sibling tools like word_add_comment by specifying that it's a reply anchored to the same paragraph. This makes the purpose unmistakable.
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 when to use this tool (when replying to an existing comment) but does not explicitly contrast with word_add_comment or word_add_comments. It provides clear context but no exclusions or alternative guidance.
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 carries the full burden. It states the action 'set or clear' but doesn't disclose side effects such as modifying the .docx file, potential to overwrite existing heading styles, or any permission requirements. This is a mutation tool with inadequate behavioral disclosure.
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 is front-loaded with the action and object. Every word contributes to meaning, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 2 well-documented parameters and no output schema. However, the lack of usage guidelines and behavioral transparency means the agent might not know when to call this or what happens after execution. It's minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both file_path and edits documented, and nested items (para_id, level) also have descriptions. The description adds little beyond the schema, mainly repeating 'by paraId' and mentioning the set/clear behavior which aligns with the level parameter's '0 to clear'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Set or clear' and identifies the resource 'heading style on paragraphs' with the key 'paraId'. This clearly distinguishes it from sibling tools like word_set_paragraph_formats which handle broader paragraph formatting.
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 heading formatting but provides no explicit guidance on when to use this tool versus alternatives like word_set_paragraph_formats or word_edit_paragraphs. There are no exclusions or alternative recommendations.
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 must carry the full burden of behavioral disclosure. It states 'Replace' implying mutation, but does not mention side effects, reversibility, permission requirements, or how track_changes affects the operation. The schema mentions track_changes, but the description itself provides no context about what modifying the file entails.
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 core action and method. Every word contributes to understanding the tool's purpose, with no redundant or filler content.
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?
The description plus the rich schema (which includes parameter descriptions and the note about applying edits in one pass) provides sufficient context for a straightforward text-replacement tool. However, it lacks explicit guidance on distinguishing from sibling tools or addressing edge cases like merged cells, but the schema covers most operational details, making the overall description nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as every parameter has an individual description, so the baseline is 3. The description adds little beyond the schema's already detailed explanations; it only repeats the coordinate concept (table index, row, column) already present in the schema, and does not introduce any new semantic insight.
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 'Replace', the resource 'text of specific table cells', and the method of identification via table index, row, and column. This is specific and distinguishes it from sibling tools like word_edit_table_paragraphs, which edits paragraphs within cells rather than replacing cell text.
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 when the user needs to directly replace cell text by coordinates, but it does not explicitly state when to use this tool over alternatives such as word_edit_table_paragraphs or word_read_table_cell. No exclusions or alternative recommendations are provided, so guidance is merely implied.
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 carry the full burden of behavioral disclosure. It does not state that the tool modifies the existing document, whether unspecified settings are preserved, if the file must exist, or any error conditions. 'Set' implies mutation, but the description gives no details on scope or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource. Every word contributes meaning, with no filler or redundancy.
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 mutation tool with 11 parameters and no annotations, the description is thin. It does not clarify how orientation interacts with width/height settings, whether margins apply to all sections, or the behavior if conflicting values are provided. While the schema documents individual parameters, the overall effect and edge cases remain ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with each parameter individually described. The description adds only a high-level summary ('page size, orientation, and/or margins') without detailing relationships or precedence, but this is acceptable given the schema's completeness.
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 action: 'Set page size, orientation, and/or margins for a Word document.' It specifies the resource (Word document) and the fields affected, distinguishing it from the read-only sibling word_get_page_layout.
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 gives clear context: use this tool when you need to modify page setup. It doesn't explicitly mention alternatives or exclusions, but the purpose is unmistakable and aligns with the verb 'set', which implies modification rather than reading.
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. 'Read' clearly implies a non-destructive operation, which is good. However, it does not disclose potential edge cases such as how multiple sections are handled, what happens if the variant is missing, or the exact return format. This is a notable gap 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 efficiently states the action and key qualifiers. No redundant or filler words are present, earning a perfect score for 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 read tool, the description is adequate but incomplete. It lacks explicit mention of return value structure (since there is no output schema) and does not address multi-section behavior, which is important for header/footer reading in Word documents. The one-sentence description leaves some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds little beyond restating the variant names ('default/first/even') already present in the schema. It does not clarify any additional meaning or relationships between 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 uses a specific verb ('Read') and identifies the exact resource ('header or footer') with variants, clearly distinguishing it from sibling tools like word_read_document or word_read_footnotes. The phrase 'via the document's section properties' further clarifies the mechanism without ambiguity.
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 when to use the tool (to read header/footer text) but does not explicitly mention alternatives or exclusions. Unlike the get_calls example, it does not say 'use X instead' or describe scenarios where this tool is not appropriate, leaving usage guidance to inference.
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 must carry the transparency burden. It adds implementation detail (settings.xml w:documentProtection) and clarifies the action type, but it does not disclose whether existing protections are overwritten, whether the file is modified in place, or that the password is required to remove the restriction. This is partly balanced by the wording, but lacks depth.
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, tightly worded sentence that front-loads the primary purpose and includes a useful technical hint. No filler 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?
With three well-documented parameters and a simple, well-defined operation, the description covers the core behavior sufficiently. It does not mention return values or behavior when protection already exists, and no output schema is present, but for a focused protection tool this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the schema already documents their meaning. The description adds no extra parameter semantics beyond contextualizing the purpose (password protects, edit_restriction controls the restriction type). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('enforce') and clearly names the resource ('password-protected editing restriction' on a Word document), plus the underlying mechanism ('settings.xml w:documentProtection'). This distinguishes it from sibling word_* tools that handle formatting, reading, or content 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 context of use is implied: when you need to add password-protected editing restrictions to a Word document. However, it provides no explicit guidance on when to prefer this over other tools (e.g., word_apply_document_preset) nor any exclusions or prerequisites.
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 of behavioral disclosure. It clearly indicates this is a read-only operation ('Get'), but it does not describe the return format, error handling, or edge cases (e.g., whether counts include tables). This is adequate for a simple getter but lacks depth.
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 redundant words. It is front-loaded with the action and target, making it immediately understandable.
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 tool with one parameter and no output schema, the description adequately conveys the tool's purpose and implicitly the return value (counts). It does not explicitly state the exact response structure, but the simplicity of the tool makes this acceptable. The description covers the essential information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'file_path', which is described as 'Absolute path to the .docx file'. The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the exact resource: paragraph/word/character counts for a Word document. This clearly differentiates it from siblings like word_read_document, which presumably reads content, and word_get_page_layout, which handles layout.
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 when to use the tool (when you need document statistics), but it does not explicitly state alternatives or exclusions. There is no mention of when not to use it or which sibling tool might be more appropriate.
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 must carry the behavioral burden. The verb 'Read' implies a non-destructive operation, but the description does not disclose potential errors, file handling behavior, or side effects. It conveys safety but lacks rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's function. No filler or redundancy; it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description sufficiently communicates what the tool reads: page size, orientation, and margins. However, it does not specify the return format or structure, but this is not strictly necessary for such a simple getter. The presence of sibling tools like word_set_page_layout provides helpful contrast.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single parameter file_path is described as 'Absolute path to the .docx file'. The description adds no additional meaning beyond this, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and clearly identifies the resource: 'page size, orientation, and margins for a Word document'. This distinguishes it from sibling tools like word_set_page_layout (which writes) and word_get_document_info (which covers broader document info).
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 context (when you need page layout details), but it does not explicitly state when to use this tool over alternatives or mention any exclusions. For a simple read operation, the implied usage is clear, but no direct comparison to siblings like word_set_page_layout 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?
With no annotations, the description carries the full burden. It discloses the core behavior (insert table after paraId) and optional seeding, which is helpful. However, it does not mention the default track_changes behavior, potential side effects such as modifying the document structure, or any required permissions. The schema covers track_changes, but the description adds minimal extra 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, target, location, and optional behavior. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the schema fully documents all six parameters and there is no output schema, the description adequately summarizes the tool's purpose and key behavior. It does not need to repeat parameter details. However, it could mention the file type (.docx) or any side effects, but those are either in the schema or not critical for invocation, so it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds semantic clarity by explicitly referencing 'after a given paraId' and 'optionally seeded with cell text', which helps the agent understand the role of after_para_id and data beyond their schema descriptions. This adds incremental value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Insert' with the resource 'a new table' and the location constraint 'after a given paraId'. It also mentions the optional 'seeded with cell text' behavior. This distinguishes it from sibling tools like word_insert_paragraphs or word_edit_table_cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or compare with any sibling tool. The only implied usage is the need for a valid paraId, but no explicit when-to-use or when-not-to-use context is 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 carries the full burden. It states that the tool 'Reads' footnotes, indicating a safe, non-destructive operation. However, it does not disclose potential edge cases, return format, or the meaning of 'normal' footnotes, leaving ambiguity about exactly what is returned.
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 one concise sentence, front-loaded with the action and resource. It contains no fluff or redundant information, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, simple read operation) and full schema coverage, the description is largely complete. It clearly states the purpose and the input. However, without an output schema, it does not specify the return format, but this is a minor gap for such a straightforward read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter `file_path` with a clear description ('Absolute path to the .docx file'), achieving 100% coverage. The description does not add any parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and clearly identifies the resource: 'all normal footnotes in a Word document'. This distinguishes it from sibling tools like word_read_comments and word_read_document, which target different content types.
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 when footnotes are needed, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. There is no mention of when not to use it, but the purpose is clear enough to infer appropriate use.
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 must carry the burden. The verb 'Read' clearly indicates a non-mutating operation, providing basic transparency. However, it does not disclose potential error conditions, the format of paraIds, or whether the operation has any side effects (e.g., file locking). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, immediately stating the action and output. Every word is informative, with no wasted content, and it is front-loaded for easy scanning.
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 read operation and full schema parameter descriptions, the description sufficiently covers the tool's purpose. It specifies the output (text and paraIds) but does not detail the exact return structure (e.g., object format) or handle edge cases like empty cells. Without an output schema, a bit more detail on return format would enhance completeness, but the current state is adequate for a simple read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with each parameter (file_path, table_index, row, col) described. The tool description adds no additional parameter semantics, instead focusing on the output. Baseline 3 is appropriate as the schema handles 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 tool reads a single table cell and specifically identifies the output as 'text and paraIds'. The verb 'Read' is specific to this operation and the resource 'table cell' distinguishes it from sibling tools like word_read_table_structure, which likely reads the entire table.
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 its use for reading one cell's content, but does not explicitly state when to choose this over word_read_table_structure or other table-related read tools. No exclusions or alternatives are mentioned, leaving room for ambiguity in selection.
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 full burden of behavioral disclosure. It does reveal the batch behavior and the anchoring requirement (each comment must have a paraId). However, it omits potential side effects (e.g., whether comments are appended to existing ones), error handling on invalid paraId, or permission requirements, so transparency is only partially 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 a single, well-structured sentence that front-loads the action ('Add') and the key differentiator ('multiple comments', 'in one pass', 'anchored by paraId'). Every word earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, full schema coverage, and no output schema, the description plus schema is sufficiently complete for an agent to understand what the tool does and how to invoke it. It could mention how to find paraIds, but that is not essential for this tool's core function and is likely covered by sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds little beyond repeating the paraId anchoring concept, which is already present in the schema's comments array item description. Therefore, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: adding multiple comments in one pass, each anchored to a paragraph by paraId. This specific verb+resource phrasing distinguishes it from the sibling word_add_comment, which likely handles single comments.
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 phrase 'in one pass' provides clear context for batch operations, implying this tool is intended for adding several comments simultaneously rather than one at a time. It does not explicitly name alternatives, but the batching context is sufficient for most AI agents to select it appropriately.
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 discloses the key external dependency on LibreOffice, which is valuable. However, it does not mention error handling, file overwrite behavior, or what happens if the conversion fails, leaving some behavioral gaps.
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 states the action, the target, and a critical prerequisite in under 25 words — ideal conciseness.
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 conversion tool with two well-documented parameters and no output schema, the description covers the essential context: what it does and the required environment. It doesn't detail failure modes, but the simplicity of the operation makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — both parameters ('file_path' and 'output_path') are described in the schema. The description adds no additional parameter-level semantics beyond reinforcing the default output behavior, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Convert') and resource ('.docx file to PDF'), clearly distinguishing it from sibling tools which handle formatting, reading, or editing Word documents. The phrase 'via a local LibreOffice install' adds necessary operational scope.
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?
It clearly states the prerequisite (LibreOffice/'soffice' on PATH or standard install location), which implies when the tool can be used. It does not explicitly name alternatives or exclusions, but no sibling tool offers PDF conversion, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly indicates a read-only operation ('List') and specifies the output fields (relationship id, target path, size), which helps the agent understand what to expect. It does not describe edge cases (e.g., no images found), but the core behavior is transparent.
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 action and resource, then specifies the output fields. Every word adds value; there is no fluff or repetition.
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 listing tool with one parameter and no output schema, the description covers the essential return fields and the document type. It does not explain whether all image locations (body, headers, footers) are included, but given the tool's low complexity, the description is sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'file_path' with description 'Absolute path to the .docx file'. The tool description adds only the general context of 'Word document', which aligns with the schema. Since the schema already fully documents the parameter, the description provides baseline value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') with a specific resource ('embedded images in a Word document') and names the returned data (relationship id, target path, size). This distinguishes it from siblings like word_read_document or word_get_document_info, which are broader in scope.
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 inspecting images in a Word document, and no sibling tool appears to duplicate this functionality. However, it does not explicitly state when to use it over alternatives or mention any exclusions (e.g., 'Use this instead of word_read_document for image-only listings'), so guidance is only inferred.
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 the full burden. It clearly states the tool reads data and enumerates exactly what is returned (row/col counts, cell text, paraIds), indicating no destructive side effects. It does not cover error conditions for invalid table_index, but the read nature is transparent.
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 directly states the tool's function. Every word earns its place, with no filler 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?
The description provides a comprehensive overview of the tool's output for a table reading tool, mentioning row/col counts and per-cell text/paraIds. It omits edge cases like merged cells or empty tables, but given the simple parameter set and lack of output schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents file_path and table_index. The description adds no extra information about parameters, so it meets the baseline of 3 without needing to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' on a table resource, clearly stating it returns row/col counts and each cell's text and paraIds. This distinguishes it from sibling tools like word_read_table_cell, which reads a single cell, and other table operations.
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 reading full table structure, but it does not explicitly state when to use it instead of word_read_table_cell or other alternatives. There is no mention of exclusions or alternate tools, leaving usage context somewhat implied.
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 a heavier burden. It does disclose the core behavioral effect (restoring deletions and dropping insertions), but it omits important details like whether the change is permanent, how formatting changes are handled, and that the file is modified in place.
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 gets straight to the point, front-loading the action and providing useful detail without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with fully documented schema, the description provides sufficient context to understand the tool's purpose and main effect. It lacks caveats like irreversibility or handling of non-text changes, but is still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'file_path' with a clear description. The tool description adds no extra parameter semantics beyond referring to the Word document, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reject'), identifies the target resource ('tracked changes in a Word document'), and clarifies the effect ('restoring deletions and dropping insertions'), which distinguishes it from sibling tools like word_accept_all_changes.
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 makes the usage context clear: it is for rejecting all tracked changes in a Word document. However, it does not explicitly mention alternatives or exclusion cases, such as when to use word_accept_all_changes instead.
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 discloses the key behavioral nuance (insertions kept, deletions dropped) beyond what the name implies, giving the agent a concrete understanding of the modification semantics. It could mention in-place modification or return value, but the core behavior is well covered.
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 of 15 words, front-loaded with the action, and every phrase adds value. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is complete enough: it states the action, the resource, and the specific effect on tracked changes. Minor omissions like return value or explicit in-place save are not critical for a tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for file_path with a clear description, so the description adds no param detail. Baseline 3 is appropriate since the schema already fully documents the single 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 uses a specific verb ('Accept') and resource ('all tracked changes'), and clarifies the exact outcome: keeping insertions and dropping deletions. This distinguishes it from the sibling word_reject_all_changes and leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool's purpose and contrasts implicitly with word_reject_all_changes. It doesn't explicitly state exclusions or when-not-to-use, but the action is specific enough that usage context is clear.
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 burden of behavioral disclosure. It reveals that base document styles/media are kept and other sources contribute only text/table content, which is valuable. However, it does not mention overwrite behavior or return values, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the primary action and includes a parenthetical with important behavioral details, with no waste 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?
The tool is moderately complex, but the schema fully describes parameters and the description explains the merge behavior. The lack of an output schema means the return value is not specified, which is a minor gap, but overall the definition is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that 'other sources contribute text/table content only,' which goes beyond the schema's parameter notes. This extra semantic context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Merge multiple .docx files into one new document.' The verb 'merge' and resource '.docx files' are specific, and the behavior of appending in order distinguishes it from other document tools like word_create_document or word_convert_to_pdf.
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 for when to use this tool (combining .docx files), but does not explicitly mention alternatives or exclusions. The sibling list shows no other merging tool, so the usage is fairly evident, but it lacks explicit '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.

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:

[![Office-MCP-Server MCP server](https://glama.ai/mcp/servers/stoyantsiparov/Office-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/stoyantsiparov/Office-MCP-Server)

Score Badge

Copy to your README.md:

[![Office-MCP-Server MCP server](https://glama.ai/mcp/servers/stoyantsiparov/Office-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/stoyantsiparov/Office-MCP-Server)

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/stoyantsiparov/Office-MCP-Server'

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