office-mcp-server

by jiahuidegit

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.4.1
Disambiguation4/5
Word and Excel tools are clearly separated by prefixes, and each add_* operation targets a distinct content type. The only minor ambiguity is between excel_add_chart and excel_write_data, since both involve writing data, but descriptions clarify the purpose.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with resource prefixes (word_, excel_), using lowercase snake_case throughout. The verbs are descriptive and predictable across both document types.
Tool Count4/5
16 tools is slightly above the typical 3-15 range, but each tool serves a distinct purpose for Word and Excel document generation. The count feels reasonable for covering two office formats without being bloated.
Completeness4/5
The tool set covers the full lifecycle of creating and saving Word and Excel documents, with comprehensive content-adding operations. Minor gaps include lack of editing existing files, cell styling, and true chart creation, but these are outside the core generation scope.
Average 2.8/5 across 16 of 16 tools scored. Lowest: 2/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 is failing
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?
描述未披露任何行为细节（如添加工作表的位置、对现有工作表的影响、是否可能失败等）。虽然注释提供了readOnlyHint=false，但描述本身未补充任何额外背景。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述仅5个字符，过于简短，属于欠规格而非精炼。虽然简洁，但未提供任何有效信息，未能体现'每个句子都应赢得其位置'的原则。
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?
工具是可变操作且无输出schema，描述未说明添加工作表的完整行为（如是否创建空表、默认位置、返回值等），对于代理正确调用来说信息不足。即使参数简单，描述也未能提供必要的上下文。
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已完整描述所有三个参数（workbookId、sheetName、tabColor），覆盖率达100%。描述未添加任何参数层面的额外说明，但基于基线规则，schema已经承担了语义职责。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述仅为'添加工作表'，直接重复了工具名称和标题，未提供任何超出名称的具体说明，也未与兄弟工具（如excel_write_data、excel_add_chart）进行区分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述完全没有提供任何使用场景、前提条件或与其他工具的对比，无法帮助代理决定何时使用此工具而非替代方案。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context such as what happens to existing files at outputPath, whether the workbook is initialized in memory or written to disk, or that other operations depend on it. It does not contradict annotations but also adds zero value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it is under-specified and repeats the tool name without adding informational value. True conciseness requires that each word earns its place; here the phrase provides no insight and is better classified as under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 4 parameters, 2 required, no output schema, and multiple sibling tools for the same domain, this description is severely incomplete. It does not explain the tool's role in the Excel workflow, the significance of template/theme, the output path behavior, or any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The tool description does not add any extra meaning to parameters such as title, outputPath, theme, or template beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建 Excel 工作簿' is essentially the Chinese translation of the tool name excel_create. It states a verb and resource but adds no detail that distinguishes this from sibling tools like excel_add_sheet or excel_save. It is a tautology rather than a meaningful purpose statement.
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?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no workflow positioning (e.g., 'create the workbook first, then add sheets'). The description completely lacks 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?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description 'merge cells' adds no behavioral detail beyond these annotations, such as the effect on existing cell data or edge cases. No contradiction with annotations, but no extra value is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, with only a single word 'merge cells'. While it has no waste, it is under-specified and fails to communicate essential usage nuances. This is not concise; it is simply minimal.
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 write operation (merge cells) but the description provides no context about behavior, such as what happens to cell contents when merging, whether dependencies exist, or any return values. Given the absence of an output schema and the lack of operational details, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (workbookId, sheetName, range) having a clear description. The description does not add any parameter-level semantics, but the schema fully covers the parameters, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '合并单元格' (merge cells) is a direct tautology of the tool name 'excel_merge_cells'. It states the action but adds no specificity beyond the name, and does not distinguish from sibling tools. It merely restates the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description gives no context about prerequisites, typical use cases, or exclusions. It is entirely silent on usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the annotations. Annotations already indicate it is not read-only and is idempotent, but the description does not explain effects like overwriting existing widths, whether it applies to specific sheets, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tautological phrase that restates the tool name. It is under-specified rather than concise, as it fails to provide any meaningful substance while occupying a line of 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?
With no output schema and sparse annotations, the description carries the burden of explaining the operation's behavior. It fails to describe what the tool actually does beyond setting column widths, leaving an agent unclear about the operation's scope, return values, or failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional parameter semantics, so 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '设置列宽' (set column width) essentially restates the tool name in Chinese, providing no additional specification or distinction from sibling tools. This is a tautology rather than a meaningful purpose statement.
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 gives no guidance on when to use this tool versus alternatives, no context about use cases, prerequisites, or exclusions. It does not mention how it relates to other excel tools or when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds no behavioral context beyond that, such as whether the table is appended, whether existing content is affected, or any side effects. It fails to disclose any traits not already captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single phrase without elaboration does not adequately serve the agent. It is concise but not appropriately sized for the tool's complexity.
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 minimal description, the tool's behavior is under-specified. It does not explain what happens when a table is added (e.g., position, effect on existing content, return value). The description plus annotations provide only a bare outline, leaving the agent without sufficient context for correct invocation and expectation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having its own description (e.g., docId '文档ID', headers '表头', rows '数据行', style '表格样式'). The tool description adds no additional parameter semantics, so it hits the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加表格' (Add table) is essentially a direct restatement of the tool name word_add_table. It identifies the resource (table) but provides no specific detail about the operation, such as adding a table with headers and rows. It does not distinguish from sibling tools beyond the name itself.
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 offers no guidance on when to use this tool versus alternatives. It does not mention any preconditions, document requirements, or suggest when adding a table is appropriate. No exclusions or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the tool is known to be a safe write operation. However, the description adds no additional behavioral context, such as whether existing cell content is overwritten, formula syntax requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two Chinese characters, which is too terse to be considered appropriately concise. It lacks sentence structure and any informative content, making it seem like an under-specified fragment rather than a well-crafted description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has four required parameters and no output schema. The description provides no information about tool behavior, return values, or error conditions, making it completely inadequate for an agent to use correctly in context.
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 clear descriptions for all four parameters (cell, formula, sheetName, workbookId). The 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加公式' translates to 'Add formula', which is a specific verb+resource pairing. However, it is a bare phrase without the context of what 'adding a formula' entails or how it differs from sibling tools like excel_write_data, limiting its usefulness for tool selection.
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 are no mentions of use cases, exclusions, or related tools, leaving the agent to infer when this tool should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context. It does not disclose how the code block is inserted, whether it replaces existing content, or what happens on success/failure. No contradiction with annotations, but no added value either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, with no wasted words. However, one could argue it is under-specified; it achieves conciseness but at the expense of substance, making it only minimally acceptable.
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 3 parameters and no output schema, the description is incomplete. It does not explain the return value, edge cases, or how this tool fits into the broader workflow. The sibling tools are all document/worksheet operations, but no guidance is provided for when to choose add_code over add_paragraph or add_table.
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 100% of parameters with descriptions (docId, code, language), so the baseline is 3. The tool description does not add any extra meaning beyond the schema, but it does not need to given the full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加代码块' (Add code block) merely restates the tool name 'word_add_code', offering no additional detail about what the tool does. It is a tautology that provides no differentiation from sibling tools like word_add_paragraph or word_add_heading.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name and schema 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?
Annotations already indicate the tool is non-read-only, non-destructive, and idempotent, and the description adds no extra behavioral context. It does not clarify what 'save' entails (e.g., whether it overwrites, creates a new version, or applies header/footer edits) despite the annotations lowering the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (four Chinese characters), which is under-specification rather than effective conciseness. It omits critical context about the operation and parameters, making it insufficiently informative even as a single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and optional header/footer/page-number features, the description is inadequate. It does not explain what saving involves or the effect of the parameters, and there is no output schema to compensate, leaving the agent with limited operational 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 coverage is 100%, with each parameter having a short description. The tool description adds no additional meaning to the parameters, so the baseline score of 3 applies; it does not compensate further but is not lacking due to high schema coverage.
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 '保存文档' (save document) clearly states a verb (save) and a resource (document), making the core action unambiguous. However, it does not explicitly mention Word or differentiate itself from sibling tools like excel_save, so it stops short of full differentiation.
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 lacks any mention of context, prerequisites, or exclusion criteria, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-idempotent behavior. The description adds no extra behavioral context, such as whether existing data is overwritten, how the sheet is selected, or what happens on error. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, making it front-loaded but under-specified. It is concise but sacrifices necessary information, so it does not serve as a model of effective 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?
For a mutation tool with 8 parameters and no output schema, the description does not explain behavior such as overwriting, error handling, return values, or interaction with existing sheet content. This leaves significant gaps 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?
Schema coverage is 100% with all 8 parameters documented, so the description need not repeat parameter details. Baseline 3 applies; the description itself adds nothing 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 'Write table data' uses a specific verb (write) and identifies the resource (table data), making the core action clear. However, it does not explicitly mention Excel or worksheet, so it does not differentiate from sibling tools like excel_add_sheet or excel_add_formula.
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, typical usage scenarios, 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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds no extra behavioral context, such as how heading insertion interacts with existing content, whether it requires a specific document state, or any side effects. The only added detail (level range) is also present in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence, which is easy to read and front-loaded. However, it is so brief that it misses an opportunity to provide useful context, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 required parameters and no output schema, the description gives a basic purpose. It is minimally viable but does not explain the effect of numbering or any behavioral implications. Given the tool's simplicity, this is adequate but not 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 baseline is 3. The description does not add meaning beyond the schema; 'support 1-6 levels' simply restates the enum on the level parameter. No additional context for numbering or docId is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'add' and the resource 'heading' clearly, and notes the supported levels (1-6). It does not explicitly distinguish it from sibling tools like word_add_paragraph, but the name and scope make the purpose understandable.
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?
There is no guidance about when to use this tool versus alternatives. It does not mention any prerequisites (e.g., the document must exist), nor does it explain situations where another tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but the description adds no additional behavioral context. It does not disclose where the paragraph is inserted (e.g., at end of document), whether it replaces any existing content, or the effect of the optional style and formatting parameters on the resulting paragraph.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (four Chinese characters), making it highly concise with no wasted words. However, its brevity borders on under-specification, lacking any structuring or contextual framing that might help an agent understand the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, including an enum for styles, and no output schema, the description is too minimal to be fully contextually complete. It only indicates the basic action and resource, omitting any detail about how the paragraph integrates into the document, defaults, or behavior when optional parameters are omitted.
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 all five parameters individually described. The description itself contributes no additional parameter information beyond what the schema already provides, 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 '添加正文段落' (Add body paragraph) clearly states the action (add) and the resource (a body paragraph), which distinguishes it from sibling tools like word_add_heading, word_add_table, word_add_list, and word_add_code. The inclusion of '正文' (body text) differentiates it from other paragraph-like additions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description simply states what the tool does without any indication of when to use it versus alternatives such as word_add_heading or word_add_list, nor does it mention prerequisites like an existing document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond 'create new document'. Annotations indicate it is not read-only and not destructive, but nothing is said about overwriting existing files, file format specifics, or side effects. There is no contradiction with annotations, but also no added 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 that fully states the tool's purpose without unnecessary words. It is front-loaded and easily scannable.
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 five parameters, two enums, and no output schema, the description is too minimal. It does not explain behavioral specifics like whether the document is saved immediately, how templates/theme affect output, or what happens if the output file already exists. This leaves the agent with questions beyond what the schema provides.
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 five parameters (theme, title, author, template, outputPath) already have descriptions in the schema. The tool description does not add any parameter semantics, but it doesn't need to 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 it creates a new Word document, which is a specific verb+resource action. It distinguishes itself from sibling tools like excel_create and word_add_* which either create a different file type or modify existing documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling tool names imply this is for creating new documents, but the description does not explicitly state when to use it or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, covering the safety profile. The description adds no extra behavioral context like overwriting behavior or return value, which is acceptable for a simple save 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 a single concise phrase with no unnecessary words. It is appropriately minimal for a straightforward save operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one parameter, and no output schema, the description is adequate but sparse. It omits potential failure conditions and return behavior, though annotations and schema fill some 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?
The schema has 100% coverage for the single parameter workbookId with its description. The tool description adds nothing beyond the schema, so baseline 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 '保存工作簿' (Save workbook) clearly states the action and resource. It is specific enough to distinguish from word_save by context, though it does not explicitly mention Excel in the description itself.
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 gives no guidance on when to use this tool vs alternatives. There is no mention of prerequisites (e.g., workbook must exist) or when saving is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, and the description merely says 'add list' without disclosing behavioral traits such as whether the list is appended, the need for an existing document, or the effect of repeated calls. No additional behavioral context is provided beyond what annotations already convey.
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 conveys the core purpose without redundancy. It is front-loaded and every word earns its place, exemplifying ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with fully documented parameters and annotations, the description is minimally adequate. However, it omits context such as insertion point (e.g., at cursor vs. end of document) and the default behavior of the optional 'ordered' parameter, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for docId, items, and ordered. The description mentions 'ordered/unordered', which aligns with the 'ordered' parameter, but it adds no significant meaning beyond the schema's own descriptions. Baseline 3 is appropriate due to complete schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加有序/无序列表' (Add ordered/unordered list) clearly specifies the verb (add), resource (list), and its variants (ordered/unordered), distinguishing it from sibling tools such as word_add_paragraph and word_add_heading. The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states the action without any context about document prerequisites, list formatting, or exclusions relative to other word_add_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key limitation that exceljs does not support direct chart object creation, which is not conveyed by annotations. This helps the agent set expectations. Annotations already indicate write-only (readOnlyHint=false), consistent with the description.
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 a parenthetical clarification, efficiently conveying the core function and limitation without 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 covers the essential behavior and limitation, and with the schema covering parameters, it is sufficiently complete for a write tool, though it could specify the layout of written data if needed.
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 descriptions cover all 7 parameters (100% coverage), so the description does not need to add parameter details. It adds no additional explanation beyond what the schema 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 explicitly states '写入图表数据到指定位置' (write chart data to specified position), and clarifies that exceljs does not support direct chart creation, clearly distinguishing this from other Excel tools that create charts or write general data. The verb and resource are specific and the limitation is mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating that after data is written, users must manually create charts in Excel, implying this tool is for preparing chart data rather than generating chart objects. It doesn't explicitly name alternatives but gives enough context for when to use it.
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?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds valuable context about automatic conversion to image and insertion. This clarifies the side effect of adding content to the document, which is not fully captured by the annotations alone.
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, compact sentence in Chinese that conveys both the action and the key behavior (auto-conversion). No wasted words; it is perfectly concise and 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?
Given the simplicity of the tool and the absence of an output schema, the description adequately covers the core functionality. It doesn't explain return values, but that is unnecessary for a content-insertion tool. The mention of automatic conversion to image covers the key behavioral aspect.
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 describes all 5 parameters with 100% coverage. The description adds no additional parameter-specific semantics beyond what the schema provides, 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 tool's function: adding a Mermaid flowchart/architecture diagram that is automatically converted to an image and inserted. It uses a specific verb (add) and resource (Mermaid diagram), distinguishing it from sibling tools like word_add_code or word_add_paragraph.
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 implies the tool is used when you need to insert a Mermaid diagram as an image, and distinguishes it from code insertion by noting the automatic conversion. It gives clear context for when to use it, though it doesn't explicitly name alternatives or exclusion scenarios.
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/jiahuidegit/office-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/jiahuidegit/office-mcp-server)

Score Badge

Copy to your README.md:

[![office-mcp-server MCP server](https://glama.ai/mcp/servers/jiahuidegit/office-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/jiahuidegit/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/jiahuidegit/office-mcp-server'

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