MCP Word Commander

by chyinan

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Tools cover distinct operations (add, create, delete, get, insert, read, replace, search, update) on different elements (paragraphs, images, tables, rows, cells). Some overlap between add_ and insert_ functions but descriptions clarify positional difference (end vs after specific index), making disambiguation manageable.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., add_image, create_table_with_data, delete_table_row). Verbs are descriptive and nouns indicate target element. Minor exceptions like 'search_and_replace' are still clear and fit the pattern.
Tool Count4/5
20 tools is slightly above the typical recommended range but well-scoped for comprehensive Word document manipulation. Each tool serves a clear purpose and covers essential creation, reading, editing, and deletion operations across paragraphs, images, tables, and cells.
Completeness4/5
The tool set covers core CRUD operations for paragraphs, images, tables, and cells, plus document info and search/replace. Missing some advanced features like headers/footers, page setup, styles, or bookmarks, but the surface is sufficient for common document editing tasks.
Average 3.5/5 across 20 of 20 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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, description bears full burden but only states the basic operation. No mention of permanence, permissions, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and no fluff, but could be better structured with front-loaded purpose and explicit parameter details.
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 simple tool and existing output schema, description lacks error conditions, prerequisites, and behavioral context for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description only adds the note that table_index is 0-based. Does not explain file_path constraints or value ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it deletes a table at a specified index in a document. Distinguishes from sibling tools like delete_table_row and delete_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites or exclusions mentioned.
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 tool returns a JSON overview but does not disclose any side effects, permissions needed, or detailed behavior (e.g., whether it is read-only). The behavioral description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with a main purpose line, an Args section, and a Returns section. It is front-loaded and contains no unnecessary words, though the parameter description is too brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though not shown), the description partially covers what is returned (paragraphs, tables, brief paragraph info). However, it lacks detail on the exact structure and omits whether other elements like images are included, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must add meaning. It simply repeats the parameter name '文档路径' (file path) without providing any additional context, format, or example. The parameter is not explained beyond its existence in 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 that the tool retrieves an overview of a Word document, including paragraph and table counts and brief paragraph info, which distinguishes it from other tools like read_document_structure that likely provide full content. However, it does not explicitly name the sibling alternative.
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 before reading full content ('用于在读取完整内容前快速了解文档结构'), which provides a usage context. It does not mention when not to use or explicitly compare to sibling tools, leaving some ambiguity.
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 burden of behavioral disclosure. It states that width and height are optional and default to original if not specified. However, it does not mention what happens on invalid indices, missing files, or whether the operation is destructive. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes a helpful note about get_images_info. It is front-loaded with the purpose and argument list. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values need not be detailed. However, the description lacks error handling, side effects, and prerequisites (except get_images_info). For a document modification tool, more context is needed for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters but adds minimal semantics: image_index is 0-based, width_inches defaults to original. The file_path and new_image_path are not described beyond names. For 5 parameters, this is inadequate.
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's purpose: replacing an image at a specified index in a document. It also suggests using get_images_info to find indices, which adds context. However, it does not explicitly distinguish from siblings like delete_image or insert_image_after_paragraph, though 'replace' is distinct enough.
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 by mentioning the need to know the image index via get_images_info. It does not specify when not to use this tool or mention alternative tools like delete_image or insert_image_after_paragraph. More explicit guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states 'delete' but does not mention whether the operation is irreversible, if indices shift after deletion, or any return value. Output schema exists but is not referenced. For a destructive action, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single line and a parameter list with definitions. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a destructive tool with 3 parameters and an output schema, the description should cover return value, preconditions, and error cases. It is incomplete, missing all such details, and the output schema is not leveraged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It lists parameters and mentions '0-based' for indices, but does not provide additional context like file path format or constraints (e.g., row must exist). The description barely adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a row from a table, distinguishing it from siblings like delete_table (deletes entire table) and add_table_row (adds row). The verb 'delete' and resource 'table row' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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, no prerequisites (e.g., table existence, valid row index), and no mention of when not to use it. The description lacks any 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 provided, the description carries full burden for behavioral disclosure. It does not mention potential errors (e.g., invalid after_index), side effects on existing content, required permissions, or the return value. Only the basic action is described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and starts with a clear purpose sentence, followed by a well-structured args list. It is appropriately sized for the complexity, though some parameter descriptions repeat default information that is already in the schema.
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?
Output schema exists but the description does not mention what the function returns (e.g., the created table object). Additionally, error handling and edge cases (e.g., out-of-bounds after_index) are not covered. For a 7-parameter tool, the description is adequate but has notable gaps.
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 0%, but the description explains each parameter in Chinese, adding meaning beyond the schema's type and default values. For example, it clarifies that after_index is 0-based, data is a 2D array, and includes defaults for header_bold and style. This compensates well for the lack of schema descriptions.
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 purpose: inserting a table after a specified paragraph. The verb 'insert' and resource 'table' are specific. However, it does not explicitly distinguish itself from sibling tools like 'create_table_with_data' or 'add_table_row', which could cause confusion about when to use each.
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. There is no mention of exclusions, prerequisites, or scenarios where other tools might be more appropriate. The description only explains the tool's action.
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. The description mentions preserving formatting, but does not disclose other behavioral traits like side effects, error conditions, or permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes a structured args list. The purpose is front-loaded, but the format is somewhat informal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters and lack of annotations, the description provides adequate parameter explanations but lacks usage context, error handling, and return value details despite an output schema existing.
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 0%, so the description adds significant meaning. It explains each parameter's purpose and includes default behavior for match_case, which is helpful beyond the bare 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 performs search and replace while preserving formatting. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like replace_paragraph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as replace_paragraph or inserting text. The description lacks context for appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only lists parameters without mentioning side effects, error conditions, or whether the modification is destructive. The description does not indicate what happens if the cell or file does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the purpose stated upfront followed by a parameter list. It could be slightly more streamlined by omitting the 'Args:' header, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 5 required) and the presence of an output schema, the description still lacks completeness. It does not explain behavior for edge cases, potential errors, or that it modifies the document in place.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds minimal context by listing each parameter with a brief explanation (e.g., '0-based' indexing for indices). This adds value beyond the schema, but the descriptions are very basic and mostly repeat parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '修改表格中指定单元格的内容' (modify the content of a specified cell in a table). It specifies a specific verb and resource, and it is distinct from sibling tools like add_table_row or delete_table_row.
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 any prerequisites, exclusions, or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states creation, but omits potential side effects like overwriting existing files, permissions, or limitations. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact two-sentence description with an args list. Efficient but could benefit from a more structured format. No extraneous content.
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?
Basic purpose is covered, and an output schema exists (not shown). However, missing details on return values, error conditions, and behavior if file already exists limit completeness for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'file_path' has zero schema description coverage. The tool's description provides an example and meaning ('path to save the document'), adding significant clarity 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 blank Word document. Among sibling tools, no other tool creates a document from scratch, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or not use this tool. No alternatives or prerequisites mentioned, leaving the agent without context for appropriate invocation.
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 transparency. It only states that the tool deletes an image, but lacks details on side effects (e.g., irreversible deletion), required permissions, or return value. The output schema may provide some info, but it is not shown. The description is insufficient for understanding the full impact of using this 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 very concise—three sentences with no redundancy. It front-loads the purpose, gives a usage hint, and then lists parameters. Every sentence 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 with two required parameters. The description covers the core use case but lacks information on return values (though output schema may exist) and behavioral implications. For a deletion tool, more context about irreversibility would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds only that image_index is 0-based, which is minimal. file_path is not explained beyond its name. This adds little value beyond the schema titles.
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 deletes an image at a specified index in a document. It uses the verb 'delete' and specifies the resource as an image by index. This effectively distinguishes it from sibling tools like add_image, replace_image, etc.
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 provides a useful hint to use get_images_info to find image indices. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it (e.g., no prerequisites or conditions). The guidance is implicit but not comprehensive.
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 exist, so the description must fully disclose behavior. It mentions insertion but lacks details on side effects (e.g., shifting indices, file saving) or error handling. The operational impact is not clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, listing parameters with explanations in a structured format. It front-loads the purpose. However, the line-by-line list could be more streamlined for an agent, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, write operation) and the existence of an output schema, the description covers parameter semantics but misses error conditions, prerequisites, and context relative to sibling tools. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant value by explaining each parameter's role (e.g., 'after_index: 0-based index to insert after'). However, it omits constraints like file_path validity and index bounds, so it's not perfect.
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') and the resource ('paragraph after the specified paragraph'). It effectively differentiates from sibling tools like 'add_formatted_paragraph' and 'replace_paragraph' by focusing on insertion at a specific index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'add_formatted_paragraph' for different formatting needs). No prerequisites or context provided, such as the document needing to exist or the after_index must be within bounds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It states returns JSON table data but omits details like how missing table index is handled, performance implications, error behavior, or data format specifics. This is insufficient for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with three main lines, then numbered Args/Returns. Front-loaded with purpose. Could be slightly more compact but overall efficient.
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?
Output schema exists but is not shown; description notes JSON return format. For a tool with no annotations, it should mention potential errors, supported document formats, or edge cases. However, given output schema likely covers structure, description 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaningful explanations for both parameters: file_path is document path, table_index specifies which table (0-based) or all if omitted. Default behavior of table_index (null means all) is implied. Adds value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reads table content from a Word document, including both the verb 'read' and the resource 'tables'. It distinguishes from sibling tools like read_document_structure, get_images_info, etc., which perform 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or mention sibling tools. Implicit usage is clear but lacks explicit direction.
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 exist, so the description carries full burden. It fails to disclose error handling, side effects (e.g., mutation), or dependencies like file existence, leaving significant gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single purpose line followed by a clean parameter list. It is front-loaded with the main action, but the bilingual mix may slightly reduce clarity for non-Chinese readers.
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 6 parameters and no output schema details, the description omits usage context, error conditions, and behavioral constraints (e.g., valid indices). Sibling tools exist but no comparative guidance is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining each parameter's purpose, units (inches for dimensions), and allowed values for alignment. However, it could detail default behavior when width/height are null.
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 (insert image) and the resource (after a specified paragraph), clearly distinguishing it from sibling tools like 'add_image' or 'insert_paragraph_after'.
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 in document editing scenarios but provides no explicit when-to-use guidance or differentiation from alternatives such as 'add_image' or 'insert_table_after_paragraph'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool modifies content and formatting, indicating a write operation. However, no details are given about side effects, return values, or error handling. With no annotations provided, the description carries the full burden but only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear purpose line followed by a parameter list. It is not overly verbose, but the parameter list somewhat duplicates schema information. The first sentence front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While parameter explanations are provided, the description omits important context such as return value, error scenarios (e.g., invalid paragraph index), and file handling requirements. Given the tool's complexity and lack of annotations, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'Args' section provides Chinese explanations for each parameter, adding unit information (e.g., font size in pt, indent in characters) that is not present in the schema titles. This compensates for the schema's lack of descriptions, though some explanations are merely translations of parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '替换指定段落的内容，并应用新的格式' (Replace content of specified paragraph and apply new formatting), specifying the verb and resource. It distinguishes from siblings like insert_paragraph_after and delete_table by focusing on replacement of an existing paragraph by index.
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. There is no mention of prerequisites, error conditions, or situations where other tools (e.g., search_and_replace) would 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 carries the full burden. It explains the tool's primary action and parameters, but does not disclose side effects (e.g., file modification, permissions, idempotency) or error handling. The behavior is adequately described at a high level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a brief introductory sentence followed by a clean Args list. Each parameter is explained in one line. No redundant information. Could be slightly more streamlined but is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values are covered. However, the description does not address prerequisites (e.g., file must exist), error conditions, or how the tool interacts with the document (e.g., whether it creates a new paragraph or modifies existing). It is adequate for simple use but lacks depth for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well. It explains each parameter with meaning and examples (e.g., font_name includes 'SimSun' and alternatives, alignment lists options, indent_first_line as character count). This adds significant value beyond the schema's raw type and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it appends a paragraph with specific formatting to a document, using a specific verb '追加' (append) and resource '段落' (paragraph). This distinguishes it from siblings like insert_paragraph_after or replace_paragraph, which have different positioning.
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 formatted paragraph at the end of a document, but does not explicitly state when to use this tool versus siblings like insert_paragraph_after (which inserts at a specific location) or replace_paragraph. No guidance on prerequisites or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the core behavior (creating and filling a table at end of document) and mentions the header_bold option. However, it lacks details on side effects (e.g., impact on existing content), error handling, or required permissions. Since no annotations are provided, the description carries the full burden, and it is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence summary followed by a bullet list of parameters. Every element is necessary and front-loaded, making it easy to scan.
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 an output schema exists and the tool is relatively simple, the description adequately covers the action and parameters. It lacks error scenarios or validation details, but for a table creation tool, it is sufficiently 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?
With 0% schema description coverage, the description provides brief explanations for all five parameters in the Args section, clarifying that data is a 2D array and header_bold controls first row bolding. This adds meaningful context beyond the bare schema, though constraints like data matching rows/cols are not mentioned.
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: '在文档末尾创建一个表格并填充数据' (Create a table at the end of the document and fill with data). It specifies the resource (table) and location (end of document), distinguishing it from sibling tools like insert_table_after_paragraph.
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 does not provide any guidance on when to use this tool versus alternatives (e.g., insert_table_after_paragraph, add_table_row). No usage context or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It states the return type (Image objects or error string) and mentions parameters like include_tables, but lacks details on side effects, performance, or what the Image object contains. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear Args/Returns structure. Every sentence adds value, no redundancy, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers main functionality, parameter details, return type, and error handling. It explains default behavior for image_index and include_tables. Some information about the Image object format is missing, but acceptable without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains all three parameters with clear semantics: file_path as document path, image_index as 0-based optional index, include_tables with default True. Since schema had 0% description coverage, this fully compensates.
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 images from Word documents and returns them directly for AI viewing. The verb 'read' and resource 'images' are specific, and it distinguishes from siblings like get_images_info (metadata) and read_tables (tabular data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_images_info or read_document_structure. The description does not provide context for when to choose this over siblings or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states that a row is added and describes parameters, but does not disclose error handling, side effects, or whether the operation is destructive. 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 concise: one line of purpose followed by a structured list of arguments. Every sentence adds value, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with an output schema, the description covers purpose and parameters adequately. However, it lacks details on error conditions or validation rules, which could be helpful for robust usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining all four parameters including their types and meaning (e.g., '0-based' indices, default position behavior). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '向表格中添加新行' (add new row to table), which is a specific verb-resource combination. It effectively distinguishes from sibling tools like delete_table_row, update_table_cell, and create_table_with_data.
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 provides basic usage context but lacks explicit guidance on when to use this tool versus alternatives. No 'when not to use' or comparison with siblings is given, though the purpose is self-explanatory.
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 provided, so the description carries full burden. It mentions paginated reading and return type (JSON string with text and style), but does not disclose potential side effects, error conditions, or authorization requirements. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short paragraphs, the first states the purpose, the second lists parameters. Every sentence is functional and earns its place. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and existence of an output schema, the description sufficiently describes the tool's capability and return format (JSON with text and style). It does not detail the output schema, but that is expected to be defined separately. Minor omission: lacks description of what 'style information' includes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds clear meaning for all four parameters, including defaults, 0-based indexing for start_index, and explanation of include_empty. This goes well beyond the schema which only provides type and title.
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 Word document content and style information in segments, with explicit verb ('读取') and resource ('Word 文档'). It distinguishes itself from sibling tools that are write operations (e.g., add, delete, replace) by focusing on reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling read tools (e.g., get_document_info, read_images, read_tables). No exclusions or when-not-to-use information provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses supported image formats (PNG, JPG, GIF, BMP) and the parameter behavior (default sizes), but does not mention side effects, error handling, or permission requirements. Adequate for a simple add operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence for the purpose, followed by a clean bullet list for parameters. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and parameter semantics. It does not mention return values (but output schema exists, so not required). It assumes basic knowledge of file paths. Sibling tools provide differentiation context. Complete enough for a straightforward add-image tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description provides all parameter explanations. It adds meaning beyond schema types: clarifies that width/height defaults use original or scale proportionally, alignment options are 'LEFT', 'CENTER', 'RIGHT', and image_path lists supported formats.
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 starts with '在文档末尾添加图片。' which clearly states the action (add image) and the location (at the end of the document). It distinguishes from sibling tools like 'insert_image_after_paragraph' which inserts at a specific position.
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 by stating 'add at end of document', but does not explicitly guide when to use this tool versus alternatives like 'insert_image_after_paragraph' or 'replace_image'. No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it returns metadata, not content. With no annotations, this is adequate but lacks details on error handling or performance considerations. For a simple read tool, it sufficiently covers core 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?
Extremely concise (3 sentences in description, plus Args/Returns), front-loaded with purpose. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, the description is sufficiently complete for its purpose. Returns JSON list of metadata. Minor gap: no mention of file format validation or error states, but acceptable for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaningful explanations for both parameters: file_path is document path, include_tables includes table images with default true. Bridges all gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves metadata (not content) from Word document images. Differentiates from sibling 'read_images' by explicitly noting no image content returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states intended use: '用于在读取图片前了解文档中图片的结构和位置' (use before reading images). Provides clear context but no explicit when-not or alternative tools.
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:

[![MCP-Word-Commander MCP server](https://glama.ai/mcp/servers/chyinan/MCP-Word-Commander/badges/card.svg)](https://glama.ai/mcp/servers/chyinan/MCP-Word-Commander)

Score Badge

Copy to your README.md:

[![MCP-Word-Commander MCP server](https://glama.ai/mcp/servers/chyinan/MCP-Word-Commander/badges/score.svg)](https://glama.ai/mcp/servers/chyinan/MCP-Word-Commander)

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/chyinan/MCP-Word-Commander'

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