Office MCP Server

by Alex-eng-ux

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but the presence of office_create_powerpoint alongside four office_ppt_add_* tools (all creating new PPTX) creates potential overlap. However, descriptions clarify that office_create_powerpoint handles multiple slides while the others create single-slide files with specific content.
Naming Consistency4/5
Tools follow a consistent prefix 'office_' with verb_noun patterns. Minor inconsistencies: use of abbreviation 'ppt' for PowerPoint tools, and mixing verbs like 'create' vs 'add' (e.g., office_create_excel vs office_add_powerpoint_slides) and 'read' vs 'get' (office_read_excel vs office_get_excel_info).
Tool Count5/5
12 tools cover a reasonable scope for an office suite, including creation, reading, and writing for main document types with some advanced PowerPoint features. The count feels appropriate without being overwhelming or too sparse.
Completeness2/5
Significant gaps exist: Word has no content reading or editing; PowerPoint lacks tools to modify existing presentations beyond adding slides; Excel misses basic operations like deleting or formatting cells. The ecosystem feels incomplete, especially for common workflows involving existing documents.
Average 4.2/5 across 12 of 12 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (destructiveHint: true, readOnlyHint: false) by stating it creates a new file. However, it does not disclose whether the tool overwrites existing files or how it behaves if the file already exists, which is important for a destructive operation.
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 well-structured with separate 'Args' and 'Examples' sections. It is concise and front-loaded with the core action. Minor redundancy in shape examples could be trimmed, 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?
For a tool with nested options and 3 parameters, the description covers essential usage. However, it omits details about file overwrite behavior, return values, and the fact that only one shape per slide is supported. This leaves gaps for an agent to infer correctly.
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?
Input schema has 100% coverage with parameter descriptions. The description adds value by listing additional shape examples beyond the schema, but it largely duplicates the schema information. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new PPTX with one slide containing a shape. However, the title 'Add Shape Slide to PowerPoint' is misleading as it implies adding to an existing presentation, not creating a new file. This discrepancy reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use when:' examples that provide usage context, but it fails to explicitly state when NOT to use this tool (e.g., for adding shapes to existing presentations). Siblings like office_ppt_add_chart exist, but no differentiation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but the description does not explain the destructive behavior (e.g., file overwrite). It lacks details on prerequisites (image must exist), side effects, or response format. The description adds minimal behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded purpose, then bulleted params, then examples. No redundant sentences. The structure is logical and easy to scan, though the Args section could be slightly more compact.
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 tool with nested objects and no output schema, the description covers basic functionality and parameters but omits important context such as file overwrite behavior, error handling, and return value. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (borderline low), but the description essentially repeats the schema without adding extra meaning. It does not clarify units for x,y,w,h (already in schema) or provide nuances like coordinate origins. The examples are about usage, not parameter specifics.
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 'Create a new PowerPoint (.pptx) with one slide containing an image,' which is a specific verb-resource combination. It distinguishes from siblings like office_create_powerpoint (blank) and office_ppt_add_chart (chart). The 'Not for' note further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples like 'Use when: Create a slide with the company logo' and 'Not for: Creating slides without images' provide clear usage context. However, it does not explicitly mention alternatives like office_create_powerpoint for blank presentations, which could improve sibling differentiation.
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 destructiveHint=true, indicating the tool creates a file. The description adds that it creates a .pptx file with slides, which is consistent. However, it does not disclose whether the tool overwrites an existing file at the given filePath or if there are any error conditions. With annotations present, the description provides some additional context but misses potentially important behavioral details.
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 brief and well-structured: a main sentence, then an Args section, then examples. Every sentence adds value, and the main action is front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, nested slides object, no output schema), the description covers the slide structure adequately and provides usage examples. However, it lacks information on behavior for existing files and return value, which would make it more 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 replicates parameter explanations (e.g., 'Path where the presentation will be created') and provides examples, but does not add significant meaning beyond what the schema already offers.
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 'Create a new PowerPoint (.pptx) presentation with slides containing titles, subtitles, and bullet content.' The verb 'Create' and resource 'PowerPoint presentation' are specific. However, it does not explicitly distinguish from the sibling tool 'office_add_powerpoint_slides', which could add slides to an existing presentation; this slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides three 'Use when' examples that all involve creating a presentation, but it does not specify when not to use this tool or mention alternatives like 'office_add_powerpoint_slides' for adding slides to existing files. The guidance is implied from the context but not explicit.
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 indicate destructiveHint=true, and the description states it modifies an existing file. No additional behavioral details beyond annotations (e.g., error handling if file not found). Adequate but not enhanced.
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?
Relatively concise but includes redundant 'Args:' section that mirrors the schema. Examples are helpful. Slight overhead but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations and full schema coverage, the description covers necessary context. Missing mention of file modification in place, but return value is obvious. Adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description merely repeats schema details (title, subtitle, content) without adding new meaning like limits or formatting rules.
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 'Add slides to an existing PowerPoint (.pptx) presentation' with a specific verb and resource. It distinguishes from siblings like office_ppt_add_chart by specifying slides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides two explicit use case examples: 'Add a summary slide' and 'Append more slides to the quarterly report deck'. It gives clear context but does not mention when not to use or compare with sibling 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat safety. It adds value by specifying the return fields (name, size, path), clarifying what the tool does beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: one sentence for purpose, a brief parameter list, and two examples. It is front-loaded and each sentence adds value, though the parameter list could be omitted given the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description adequately explains return values (name, size, path) and usage. It is sufficient given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description repeats the schema's parameter meaning ('Path to the Word document') without adding additional semantics. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'basic information about a Word (.docx) file'. It specifies the return fields (name, size, path), making it distinct from siblings that read content or manipulate other formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete usage examples like 'Check if the Word document exists and how large it is' and 'Get info about the report.docx file'. Though it does not explicitly mention when not to use or alternatives, the examples give clear 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so agent knows it's a write operation. Description adds 'Create' and file path requirement but does not disclose potential file overwrite or permission needs. No contradiction.
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?
Description is compact with clear sections (Args, examples). Every sentence adds value, no redundancy. Well-structured for agent parsing.
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, nested objects, and no output schema, description adequately explains inputs and purpose. Examples cover common use cases. Slight gap: no mention of return value or error scenarios, but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. Description adds human-readable explanation of the 'contents' array structure and optional parameters like title and author, providing beyond-schema value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new Word (.docx) document' with specific verb and resource. It lists supported content types (headings, paragraphs, lists, tables) and distinguishes from sibling tools for Excel, PowerPoint, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides 'Use when:' examples like 'Create a report document with headings and bullet points' which gives clear context. Lacks explicit when-not-to-use or alternative tools, but sibling tool names imply differentiation.
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?
Annotations already readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the return structure (sheets with name, rowCount, columnCount), providing behavioral insight beyond safety. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear summary line, structured Args and Returns sections, and three example uses. No superfluous content; all sentences serve a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully explains the return value and example use cases. Sibling tools are distinct, and the tool's role is well-defined.
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 one parameter (filePath) already described. The description does not add extra detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get information about an Excel file, including all sheet names and dimensions.' It specifies the resource (Excel file) and the action (get structural info), distinguishing it from siblings like office_read_excel (which reads cell data).
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 three explicit usage examples (e.g., 'What sheets are in this Excel file?'), effectively guiding when to use this tool. It does not explicitly state when not to use, but the examples make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description's mention of 'Don't use when the file already exists' adds useful behavioral context beyond the annotation. It implies overwriting could occur, but does not explicitly describe what happens if the file exists.
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 opening sentence, a structured argument list, and helpful examples. Every sentence serves a purpose, and the most critical information 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 purpose, usage guidelines, and parameters well. However, it lacks explicit mention of the tool's return value or success/error behavior, and does not detail overwriting behavior beyond the 'don't use' hint. Given no output schema, a bit more completeness would be beneficial.
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 baseline is 3. The description's parameter list largely mirrors the schema's descriptions without adding significant new meaning or constraints beyond the examples.
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 'Create a new Excel (.xlsx) file with headers and data,' providing a specific verb and resource. It distinguishes itself from siblings by explicitly mentioning 'office_write_excel' for appending when the file exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'Use when' and 'Don't use when' examples, and directly points to an alternative tool ('office_write_excel') for appending data to an existing file. This provides clear context for when to use this tool.
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?
Annotations indicate destructive write operation, and description confirms creating a new file. Add context that it creates exactly one slide with a table, no contradiction, but could mention overwrite behavior explicitly.
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?
Concise two-line summary followed by well-organized Args list and examples, front-loaded and no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and parameters well, but lacks description of return value/output. Since no output schema exists, description could add what the tool returns (e.g., file path or success status).
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?
Description documents filePath, table headers, rows, and a subset of options (fontSize, fontFace, borderColor, colW) but omits x, y, w, borderSize, rowH from the schema, giving partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new PowerPoint file with a single slide containing a formatted table, using specific verb 'Create' and resource 'PowerPoint .pptx', distinguishing it from sibling tools like office_ppt_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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when' examples and a 'Not for' case with an alternative tool (office_create_powerpoint), giving clear guidance on when to use this tool vs alternatives.
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?
Annotations indicate destructiveHint: true, which aligns with the description's 'Create a new PowerPoint...'. The description adds that it creates a new file, but does not explicitly mention overwrite behavior. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is effectively structured with Args section and examples, front-loading the main purpose. It is comprehensive but slightly lengthy; each section contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested chart config), the description covers purpose, parameters, and usage guidance. However, it lacks explanation of return values (no output schema) and could clarify file overwrite behavior.
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 re-explains parameters like chart type, data series structure, and options in a structured format, adding value beyond the schema. However, it could more clearly differentiate required vs optional for nested fields; schema coverage is moderate.
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 PowerPoint file with a chart slide, using specific verbs 'Create' and 'containing a chart'. It distinguishes from siblings like office_create_powerpoint (which likely creates a blank presentation) and other office_ppt_add_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' and 'Not for' examples, guiding the agent on appropriate use cases (e.g., chart generation) and exclusion of simple text slides with reference to an alternative sibling tool.
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 adds 'append' behavior to the write operation, providing nuance beyond the destructiveHint annotation. However, it does not explicitly state whether writing to a range overwrites existing cells or merges data, leaving some ambiguity. Given the annotation already signals potential destructiveness, a 4 is appropriate as it adds useful context without full clarity.
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 clear one-sentence summary, a structured parameter list, and two 'Use when' examples plus one 'Don't use when'. It is well-organized and front-loaded with the primary purpose. No unnecessary 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?
The description explains the tool works on existing files, not new ones, and uses examples to illustrate common use cases. It does not detail error conditions (e.g., file not found, sheet not found) or exactly how data is written (overwrite or append). However, given the moderate complexity and presence of annotations, it provides sufficient context for most scenarios. A 4 reflects the minor 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?
With 100% schema coverage, the baseline is 3. The description adds value by providing examples for startCell and showing how parameters are used in context (e.g., 'starting at B3'). The Args section mirrors the schema but also clarifies default values. This additional context justifies a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'write' and 'append' to describe the action on an existing Excel file. It explicitly contrasts with the sibling tool office_create_excel, preventing confusion. The examples further clarify usage scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use when' and 'Don't use when' examples that explicitly state when this tool is appropriate and when to use the sibling tool office_create_excel instead. This provides clear guidance for the AI agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the return format structure and default behaviors (first sheet, full range if unspecified), enriching transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully documents the return format. All parameters are covered in both schema and description, making it complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context like absolute/relative path, default sheet, and range example, providing slight additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read data from an Excel (.xlsx) file,' identifying the specific verb and resource. It distinguishes from siblings via the 'Don't use when' note referencing office_write_excel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' and 'Don't use when' guidance is provided, including a direct alternative (office_write_excel) for writing 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/Alex-eng-ux/office-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Alex-eng-ux/office-mcp-server)

Score Badge

Copy to your README.md:

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

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