How do I use Office MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Office MCP Server Create an Excel file at ./report.xlsx with headers [Item, Cost] and rows [[A,10],[B,20]]" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Office MCP Server

by Alex-eng-ux

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Office MCP Server

MCP server for Microsoft Office file operations. Read, write, and create Excel (.xlsx), Word (.docx), and PowerPoint (.pptx) files directly from your local filesystem.

Works with any MCP-compatible client (Claude Desktop, Trae SOLO, VS Code via MCP extension, etc.).

Features

Excel

Tool	Function
`office_read_excel`	Read data from Excel files (specify sheet and range)
`office_write_excel`	Write or append data to existing Excel files
`office_create_excel`	Create new Excel files with headers, data, and auto-sized columns
`office_get_excel_info`	List all sheets with dimensions
`office_excel_create_table`	Create formatted Excel tables (超级表/ListObject) with styles, filter buttons, and totals row
`office_excel_set_formula`	Set formulas in cells (e.g. `SUM(A2:B2)`)
`office_excel_fill_formula`	Fill formulas across a range of cells
`office_excel_merge_cells`	Merge or unmerge cell ranges
`office_excel_add_auto_filter`	Add auto filter to a data range
`office_excel_set_styles`	Apply advanced cell formatting (font, fill, border, alignment, number format)
`office_excel_add_comment`	Add comments/notes to cells
`office_excel_add_image`	Insert images into worksheets
`office_excel_rename_sheet`	Rename worksheets
`office_excel_add_conditional_formatting`	Add conditional formatting: data bars, color scales, icon sets, cell rules
`office_excel_add_data_validation`	Add data validation: dropdown lists, number ranges, custom rules
`office_excel_freeze_panes`	Freeze rows/columns to keep them visible while scrolling

Word

Tool	Function
`office_create_word`	Create Word documents with rich formatting: headings, paragraphs, formatted tables (borders, shading, header rows, column widths), images, hyperlinks, page breaks, text styling (bold, italic, underline, strikethrough, color, highlight, superscript, subscript), alignment, lists, headers/footers with page numbers, page orientation, margins, table of contents
`office_read_word`	Get basic document info

PowerPoint

Tool	Function
`office_create_powerpoint`	Create presentations with title, subtitle, and bullet content slides
`office_add_powerpoint_slides`	Append slides to an existing presentation
`office_ppt_add_chart`	Generate single-slide presentations with charts (bar, pie, line, area, radar, bubble, etc.)
`office_ppt_add_shape`	Draw shapes (rectangles, circles, stars, arrows, hearts, etc.)
`office_ppt_add_image`	Insert images into slides
`office_ppt_add_table`	Create formatted table slides
`office_ppt_add_master_slide`	Create slide masters (templates) with consistent branding
`office_ppt_add_animation`	Create animated slides with fade, fly, zoom, bounce effects

Installation

Prerequisites

Node.js >= 18
npm

Setup

git clone https://github.com/Alex-eng-ux/office-mcp-server.git
cd office-mcp-server
npm install
npm run build

Configuration

Add the server to your MCP configuration file (mcp.json):

{
  "mcpServers": {
    "Office MCP": {
      "command": "node",
      "args": ["path/to/office-mcp-server/dist/index.js"],
      "env": {}
    }
  }
}

Configuration file locations:

Client	File Path
Trae / Trae SOLO	`%APPDATA%\TRAE SOLO CN\User\mcp.json`
VS Code + MCP extension	`.vscode/mcp.json` in project root
Claude Desktop	`claude_desktop_config.json`

Usage Examples

Excel

Create a budget spreadsheet:

Create an Excel file at ./budget.xlsx with headers ["项目", "预算", "实际", "差异"]
and rows [["研发", 100000, 95000, 5000], ["市场", 50000, 52000, -2000]]

Read data from an existing file:

Read Sheet1 from ./report.xlsx, range A1:D10

Create a formatted Excel table (超级表) with alternating row colors and totals row:

Create a table in ./sales.xlsx sheet "Sheet1":
name: "SalesTable"
columns: ["产品" (name), "销量" (sum), "金额" (sum)]
rows: [["A产品", 120, 15000], ["B产品", 85, 10200], ["C产品", 200, 28000]]
style: { theme: "TableStyleMedium9", showRowStripes: true, showFirstColumn: true }
totalsRow: true

Set formulas and apply cell formatting:

- Set formula in ./budget.xlsx sheet "Sheet1" cell D2: "B2-C2" (差异 = 预算 - 实际)
- Fill formula from D2 to D10 in ./budget.xlsx sheet "Sheet1"
- Apply styles to A1:D1 in ./budget.xlsx: bold font, blue background (#4472C4), white text, centered
- Set number format "¥#,##0" for range C2:D10
- Add auto filter to A1:D10
- Merge cells A11:D11 for a title row
- Add comment to B5: "需部门负责人确认" author: "财务部"

Add conditional formatting:

- Add data bars to C2:C10 in ./sales.xlsx: color "4472C4", showValue: true
- Add color scale to D2:D10: minColor "63BE7B", midColor "FFEB84", maxColor "F8696B"
- Add icon set (3Arrows) to B2:B10: showValue: true
- Add cell rule to C2:C10: greaterThan 15000, fill color "92D050"

Add data validation:

- Add dropdown list to A2:A10: type "list", formulae: ['"选项1,选项2,选项3"']
- Add integer range to B2:B10: type "whole", operator "between", formulae: [1, 100]

Freeze panes:

- Freeze first row in ./report.xlsx sheet "Sheet1": freezeType "row", rows: 1
- Freeze first column: freezeType "column", cols: 1

Word

Generate a meeting report with rich formatting:

Create a Word document at ./meeting.docx with:
- Heading 1: "项目周报"
- Paragraph: "本周进展顺利。"
- Heading 2: "完成事项"
- Bullet: "功能A已上线"
- Bullet: "Bug修复完成"
- Table: headers ["任务", "状态", "负责人"]
  with formatting: header shading (#4472C4), borders, column widths [2, 2, 2]
- Table rows: ["登录模块", "已完成", "张三"], ["支付功能", "测试中", "李四"]
- Page break
- Heading 2: "参考资料"
- Hyperlink: "点击查看项目文档" -> https://example.com/docs
- Paragraph: "红色粗体警告文字" bold: true, color: "FF0000"
- Paragraph: "居中对齐段落" alignment: "center"

Create a landscape document with headers, footers and page numbers:

Create a Word document at ./report.docx with:
- Heading 1: "年度汇报", alignment: "center"
- Paragraph: "内容..."
Options: orientation: "landscape", margins: { top: 0.8, bottom: 0.8, left: 1, right: 1 }, header: "公司机密", footer: "第 1 页", showPageNumber: true

Create a document with table of contents:

Create a Word document at ./report.docx with:
- TOC (table of contents)
- Heading 1: "第一章 概述"
- Paragraph: "..."
- Heading 2: "1.1 背景"
- Paragraph: "..."
- Heading 1: "第二章 方案"
- ...

PowerPoint

Create a presentation:

Create a PowerPoint at ./report.pptx with 3 slides:
Slide 1: title "季度汇报", subtitle "2026 Q2"
Slide 2: title "核心数据", bullets ["营收增长25%", "用户突破100万"]
Slide 3: title "下一步计划", bullets ["优化性能", "扩展新功能"]

Add a bar chart:

Create a chart at ./chart.pptx:
type: bar
data: [labels: ["Q1","Q2","Q3","Q4"], name: "营收", values: [120, 150, 180, 220]]
options: showLegend: true, barDirection: "col"

Add a shape:

Create a shape slide at ./shape.pptx:
shape: "star5"
options: { x: 2, y: 1, w: 4, h: 4, fillColor: "FFD700" }

Create a master slide template:

Create a master slide at ./template.pptx:
title: "CORPORATE"
background: { color: "1F497D" }
objects: [{ type: "text", text: "公司机密", options: { x: 0.5, y: 7, w: 9, h: 0.5, fontSize: 10, color: "AAAAAA" } }]
slideNumber: { x: 9.2, y: 7, fontSize: 10, color: "AAAAAA" }

Create an animated slide:

Create an animated slide at ./animated.pptx:
title: "项目进展"
content: ["需求分析已完成", "系统设计已完成", "开发实现中"]
animations: [{ type: "fade", delay: 0, duration: 500, on: "onClick" }, { type: "fly", delay: 200, duration: 600, on: "afterPrevious" }]

Supported Chart Types

Type	Description
`bar`	Bar chart (clustered, stacked, percentStacked)
`bar3D`	3D bar chart
`line`	Line chart
`pie`	Pie chart
`area`	Area chart
`doughnut`	Doughnut chart
`radar`	Radar chart
`scatter`	Scatter chart
`bubble`	Bubble chart

Common Shapes

rect, ellipse, triangle, star5, heart, diamond, cloud, lightningBolt, smileyFace, chevron, pentagon, hexagon, octagon, moon, sun, leftArrow, rightArrow, upArrow, downArrow, cube, plus, wave, funnel, ribbon, line — and 150+ more.

Development

# Watch mode
npm run dev

# Build
npm run build

# Start
npm start

Project Structure

office-mcp-server/
├── src/
│   ├── index.ts              # MCP server entry, tool registration
│   ├── types.ts              # Shared type definitions
│   └── services/
│       ├── excel.ts          # Excel operations
│       ├── word.ts           # Word operations
│       └── powerpoint.ts     # PowerPoint operations (charts, shapes, images, tables)
├── test-excel-advanced.mjs   # Excel advanced features test script
├── test-word-advanced.mjs    # Word advanced features test script
├── test-new-features.mjs     # Conditional formatting, data validation, freeze panes, TOC, master, animation test
├── package.json
├── tsconfig.json
└── .gitignore

License

MIT

Available Tools

12 tools

office_add_powerpoint_slidesAdd Slides to PowerPointA

Destructive

Add slides to an existing PowerPoint (.pptx) presentation.

Args:

filePath (string): Path to the existing presentation
slides (array of slide objects): Slides to add

Each slide can have:

title (string, optional): Slide title
subtitle (string, optional): Slide subtitle
content (array of strings, optional): Bullet points

Examples:

Use when: "Add a summary slide to the existing presentation"
Use when: "Append more slides to the quarterly report deck"

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Path to the existing PowerPoint file
`slides`	Yes	Array of slides to add

TDQS

A3.9/5.0

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.

office_create_excelCreate New Excel FileA

Destructive

Create a new Excel (.xlsx) file with headers and data.

Args:

filePath (string): Path where the new Excel file will be created
headers (array of strings): Column headers
rows (array of arrays): Data rows
sheetName (string, optional): Sheet name (default: "Sheet1")
columnWidths (array of numbers, optional): Custom column widths

Examples:

Use when: "Create a new spreadsheet for the project budget"
Use when: "Generate an Excel report with employee data"
Don't use when: The file already exists and you want to append data (use office_write_excel instead)

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Path for the new Excel file (e.g., './budget.xlsx')
`headers`	Yes	Column headers (e.g., ['Name', 'Age', 'Department'])
`rows`	Yes	Data rows (e.g., [['Alice', 30, 'Engineering'], ['Bob', 25, 'Design']])
`sheetName`	No	Sheet name (default: Sheet1)	Sheet1
`columnWidths`	No	Custom column widths

TDQS

A4.4/5.0

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.

office_create_powerpointCreate PowerPoint PresentationA

Destructive

Create a new PowerPoint (.pptx) presentation with slides containing titles, subtitles, and bullet content.

Args:

filePath (string): Path where the presentation will be created
slides (array of slide objects): Each slide has:
- title (string, optional): Slide title
- subtitle (string, optional): Slide subtitle
- content (array of strings, optional): Bullet points for the slide

Examples:

Use when: "Create a presentation about the quarterly results"
Use when: "Generate a slide deck for the project kickoff meeting"
Use when: "Make a 5-slide summary presentation"

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Path for the new PowerPoint file (e.g., './presentation.pptx')
`slides`	Yes	Array of slides to include in the presentation

TDQS

A3.6/5.0

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.

office_create_wordCreate Word DocumentA

Destructive

Create a new Word (.docx) document with rich content (headings, paragraphs, lists, tables).

Args:

filePath (string): Path where the document will be created
contents (array of content objects): Document content. Each content object has:
- type: "paragraph" | "heading" | "bullet" | "numbered" | "table"
- text: string (for paragraph, heading, bullet, numbered)
- level: number (for heading: 1-3, for lists: 0-based level)
- rows: string[][] (for table type)
- bold: boolean (optional)
- italic: boolean (optional)
title (string, optional): Document title
author (string, optional): Document author

Examples:

Use when: "Create a report document with headings and bullet points"
Use when: "Generate a Word document with a table of data"
Use when: "Write a meeting notes document"

ParametersJSON Schema

Name	Required	Description
`filePath`	Yes	Path for the new Word document (e.g., './report.docx')
`contents`	Yes	Array of content blocks to include in the document
`title`	No	Document title
`author`	No	Document author name

TDQS

A4.2/5.0

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.

office_get_excel_infoGet Excel File InformationA

Read-onlyIdempotent

Get information about an Excel file, including all sheet names and dimensions.

Args:

filePath (string): Path to the Excel file

Returns: { "sheets": [ { "name": string, "rowCount": number, "columnCount": number } ] }

Examples:

Use when: "What sheets are in this Excel file?"
Use when: "How big is the data in report.xlsx?"
Use when: "List all sheets in the workbook"

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Path to the Excel file

TDQS

A4.3/5.0

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.

office_ppt_add_chartAdd Chart Slide to PowerPointA

Destructive

Create a new PowerPoint (.pptx) with one slide containing a chart.

Args:

filePath (string): Path where the presentation will be created
chart (object): Chart configuration
- type (string): Chart type: "area" | "bar" | "bar3D" | "bubble" | "doughnut" | "line" | "pie" | "radar" | "scatter"
- data (array): Data series. Each series has:
  - labels (string[]): Category labels
  - name (string): Series name
  - values (number[]): Data values
- options (object, optional):
  - showLegend (boolean): Show legend
  - showTitle (boolean): Show title
  - chartColors (string[]): Custom color palette
  - barDirection ("bar" | "col"): Bar direction (for bar charts)
  - barGrouping ("clustered" | "stacked" | "percentStacked"): Bar grouping
  - dataLabelFormat (string): Data label format code (e.g. "#,##0")

Examples:

Use when: "Create a bar chart showing quarterly sales data"
Use when: "Generate a pie chart of market share distribution"
Use when: "Make a line chart of revenue trends over time"
Not for: Simple text slides with bullets (use office_create_powerpoint instead)

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Path for the new PowerPoint file
`chart`	Yes

TDQS

A4.5/5.0

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.

office_ppt_add_imageAdd Image to PowerPointA

Destructive

Create a new PowerPoint (.pptx) with one slide containing an image.

Args:

filePath (string): Path where the presentation will be created
image (object): Image configuration
- path (string): Path to the image file
- options (object, optional):
  - x (number): Left position (inches)
  - y (number): Top position (inches)
  - w (number): Width (inches)
  - h (number): Height (inches)
  - rotate (number): Rotation (degrees)
  - sizing ("cover" | "contain" | "stretch"): Image sizing mode

Examples:

Use when: "Create a slide with the company logo"
Use when: "Add a screenshot image to a presentation slide"
Not for: Creating slides without images

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Path for the new PowerPoint file
`image`	Yes

TDQS

A3.5/5.0

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.

office_ppt_add_shapeAdd Shape Slide to PowerPointB

Destructive

Create a new PowerPoint (.pptx) with one slide containing a shape.

Args:

filePath (string): Path where the presentation will be created
shape (string): Shape type name (e.g. 'rect', 'ellipse', 'triangle', 'star5', 'heart', 'cloud', 'lightningBolt', 'smileyFace', 'chevron', 'pentagon', 'hexagon', 'octagon', 'diamond', 'moon', 'sun', 'pie', 'arc', 'frame', 'cube', 'plus', 'wave', 'funnel', 'bevel', 'donut', 'corner', 'heart', 'plaque', 'ribbon', 'line', etc.)
options (object, optional):
- x (number): Left position (inches)
- y (number): Top position (inches)
- w (number): Width (inches)
- h (number): Height (inches)
- fillColor (string): Fill color (hex, e.g. "4472C4")
- lineColor (string): Line/border color (hex)
- lineSize (number): Line width (points)
- rotate (number): Rotation (degrees, -360 to 360)

Examples:

Use when: "Draw a red rectangle" or "Create a slide with a blue circle"
Use when: "Add a star shape to the presentation"
Use when: "Create a flowchart shape like a diamond or process box"

ParametersJSON Schema

Name	Required	Description
`filePath`	Yes	Path for the new PowerPoint file
`shape`	Yes	Shape type (e.g. 'rect', 'ellipse', 'triangle', 'star5', 'heart', 'diamond', 'chevron', 'lightningBolt', 'cloud', 'smileyFace', 'moon', 'sun', 'pentagon', 'hexagon', 'octagon', 'pie', 'arc', 'cube', 'plus', 'wave', 'funnel', 'ribbon', 'line', 'bentArrow', 'circularArrow', 'leftArrow', 'rightArrow', 'upArrow', 'downArrow')
`options`	No	Shape options

TDQS

B3.4/5.0

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.

office_ppt_add_tableAdd Table Slide to PowerPointA

Destructive

Create a new PowerPoint (.pptx) with one slide containing a formatted table.

Args:

filePath (string): Path where the presentation will be created
table (object): Table configuration
- headers (string[]): Column headers
- rows (string[][]): Data rows
- options (object, optional):
  - fontSize (number): Font size
  - fontFace (string): Font name
  - borderColor (string): Border color (hex)
  - colW (number[]): Column widths (inches)

Examples:

Use when: "Create a slide with a sales data table"
Use when: "Make a comparison table slide"
Use when: "Generate a KPI dashboard table slide"
Not for: Simple text slides (use office_create_powerpoint instead)

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Path for the new PowerPoint file
`table`	Yes

TDQS

A4.4/5.0

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.

office_read_excelRead Excel FileA

Read-onlyIdempotent

Read data from an Excel (.xlsx) file.

Args:

filePath (string): Absolute or relative path to the Excel file
sheetName (string, optional): Name of the sheet to read. Defaults to first sheet
range (string, optional): Cell range to read, e.g. "A1:C10". Reads all data if not specified

Returns: { "sheetName": string, "headers": string[], "rows": object[], "totalRows": number, "totalColumns": number }

Examples:

Use when: "Read the sales data from report.xlsx"
Use when: "What are the column headers in Sheet2 of data.xlsx?"
Don't use when: You need to write data to Excel (use office_write_excel instead)

ParametersJSON Schema

Name	Required	Description
`filePath`	Yes	Path to the Excel file (e.g., 'C:/data/report.xlsx' or './report.xlsx')
`sheetName`	No	Sheet name to read (defaults to first sheet)
`range`	No	Cell range like 'A1:C10' (reads all if not specified)

TDQS

A4.9/5.0

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.

office_read_wordGet Word Document InfoA

Read-onlyIdempotent

Get basic information about a Word (.docx) file.

Args:

filePath (string): Path to the Word document

Returns basic file info (name, size, path).

Examples:

Use when: "Check if the Word document exists and how large it is"
Use when: "Get info about the report.docx file"

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Path to the Word document

TDQS

A4.1/5.0

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.

office_write_excelWrite Data to ExcelA

Destructive

Write or append data to an existing Excel (.xlsx) file.

Args:

filePath (string): Path to the Excel file
data (array of arrays): 2D array of values to write
sheetName (string, optional): Target sheet name (default: "Sheet1")
startCell (string, optional): Starting cell, e.g. "A1" (default: "A1")

Examples:

Use when: "Add these numbers to the existing budget.xlsx"
Use when: "Write the updated inventory list to Sheet2 of data.xlsx starting at B3"
Don't use when: You need to create a new Excel file (use office_create_excel instead)

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Path to the Excel file
`data`	Yes	2D array of values to write (e.g., [["Name", "Age"], ["Alice", 30]])
`sheetName`	No	Sheet name to write to (default: Sheet1)	Sheet1
`startCell`	No	Starting cell position (default: A1)	A1

TDQS

A4.6/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesv1.0.0May 31, 2026
- First observedoffice_add_powerpoint_slides
- First observedoffice_create_excel
- First observedoffice_create_powerpoint
- First observedoffice_create_word
- First observedoffice_get_excel_info
- First observedoffice_ppt_add_chart
- First observedoffice_ppt_add_image
- First observedoffice_ppt_add_shape
- First observedoffice_ppt_add_table
- First observedoffice_read_excel
- First observedoffice_read_word
- First observedoffice_write_excel

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-05-31 06:35 across 12 tools

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.

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

powerpoint-engineOAuth
io.powerpointengine
Generate, edit, merge, translate and PDF-convert PowerPoint (.pptx) over MCP. 8 tools.
Workplace & Productivity File Systems
2
mcp-serverOAuth
com.pdfgate
MCP server for the PDFGate API. Generate PDFs, manage documents and handle e-signatures.
Documentation Access File Systems
1
Mdkit A
online.mdkit
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Developer Tools RAG Systems Data Platforms
31
Razi Document Tools A
io.github.razikallayi
Document processing over MCP: merge, split and compress PDFs, run OCR, extract document text.
Multimedia Processing
61

Office MCP Server

Features

Excel

Word

PowerPoint

Installation

Prerequisites

Setup

Configuration

Usage Examples

Excel

Word

PowerPoint

Supported Chart Types

Common Shapes

Development

Project Structure

License

Available Tools

Tool Schema Changelog

Resources

Related MCP Connectors

Appeared in Searches