Which integrations are available for this server?

Allows reading, writing, and converting LibreOffice documents (ODT, ODS, ODP) as well as Microsoft Office formats (DOCX, XLSX, PPTX) and PDF. Provides tools to read spreadsheet data as 2D arrays, create new spreadsheets, and convert between ODS, XLSX, CSV formats. Supports reading presentations from ODP and PPTX files, with text extraction and conversion capabilities. Enables reading, writing, and converting Writer documents (ODT, DOCX) including text extraction, editing, and creation.

How do I use mcp-office-parser?

1. Click on "Install 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., "@mcp-office-parser convert my report.docx to PDF" 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.

mcp-office-parser

by as7722314

Overview Schema Related Servers Score Discussions

JavaScript

Local

mcp-office-parser

⚠️ AI-Generated Project — Use With Caution
This project was generated with the assistance of AI. While efforts have been made to verify correctness, the code may contain errors, security vulnerabilities, or unexpected behavior. It has not been fully audited or tested in production environments. Use at your own risk, and always review the source code before deploying.

An MCP (Model Context Protocol) server for reading, writing, and converting LibreOffice and Microsoft Office documents — implemented in pure JavaScript with no external binary dependencies.

Quick Start

npx @barry.wu0329/mcp-office-parser

Related MCP server: office-mcp

What It Does

mcp-office-parser exposes document manipulation capabilities as MCP tools that AI assistants (like Claude) can use to:

Read ODT, DOCX, ODP, PPTX, TXT, and more
Read spreadsheets from ODS, XLSX, CSV files
Create new documents (ODT, ODS, DOCX, XLSX, PDF)
Edit existing documents by inserting text
Convert between formats (e.g., DOCX → PDF, ODT → TXT)
Search through documents for specific content
Merge multiple documents into one

Configuration

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "mcp-office-parser": {
      "command": "npx",
      "args": ["@barry.wu0329/mcp-office-parser"]
    }
  }
}

VS Code (MCP extension)

Add to .vscode/mcp.json:

{
  "servers": {
    "mcp-office-parser": {
      "command": "npx",
      "args": ["@barry.wu0329/mcp-office-parser"]
    }
  }
}

Supported File Formats

Format	Read	Write	Notes
`.odt`	✅	✅	LibreOffice Writer
`.ods`	✅	✅	LibreOffice Calc
`.odp`	✅	✅	LibreOffice Impress
`.docx`	✅	✅	Microsoft Word
`.xlsx`	✅	✅	Microsoft Excel
`.pptx`	✅	—	Microsoft PowerPoint
`.txt`	✅	✅	Plain text
`.csv`	✅	✅	Comma-separated values
`.pdf`	✅	✅	Read via pdf-parse; write via pdf-lib
`.html`	—	✅	HTML conversion output

Available MCP Tools

Tool	Description
`get_document_info`	Get file metadata (size, format, modified time)
`read_document_text`	Extract plain text from a document
`read_spreadsheet_data`	Read spreadsheet data as a 2D array
`create_document`	Create a new document with content
`insert_text_at_position`	Insert text at start, end, or replace content
`list_documents`	Find all supported documents in a directory
`search_documents`	Search document contents for a query string
`get_document_statistics`	Word count, character count, sentence count, etc.
`convert_document`	Convert between formats
`merge_text_documents`	Merge multiple documents into one

MCP Resources

documents:// — Lists all discoverable documents as JSON
document://{path} — Reads a document's text content

Requirements

Node.js >= 18.17.0
No LibreOffice or other external tools needed

License

MIT

Available Tools

11 tools

convert_documentD

ParametersJSON Schema

Name	Required	Description	Default
`source_path`	Yes
`target_path`	Yes
`target_format`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_documentD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`content`	No
`doc_type`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_document_infoD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the document

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_document_statisticsD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

insert_table_docxD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the .docx file (created if it does not exist)
`rows`	Yes	Table data as a 2D array; the first row is typically the header
`position`	No		end

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

insert_text_at_positionD

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`text`	Yes
`position`	No	end

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_documentsD

ParametersJSON Schema

Name	Required	Description	Default
`search_path`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

merge_text_documentsD

ParametersJSON Schema

Name	Required	Default
`separator`	No	---
`output_path`	Yes
`document_paths`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_document_textD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the document

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_spreadsheet_dataD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`max_rows`	No
`sheet_name`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_documentsD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`search_path`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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. Dates show when Glama detected each change.

11 tool updatesv1.5.2Aug 13, 2026
- First observedconvert_document
- First observedcreate_document
- First observedget_document_info
- First observedget_document_statistics
- First observedinsert_table_docx
- First observedinsert_text_at_position
- First observedlist_documents
- First observedmerge_text_documents
- First observedread_document_text
- First observedread_spreadsheet_data
- First observedsearch_documents

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.8/5.0

Disambiguation3/5

Most tools have distinct targets (e.g., read_document_text vs. read_spreadsheet_data), but get_document_info and get_document_statistics could be confused, and insert_text_at_position and insert_table_docx are both insertion operations with unclear boundaries. Without descriptions, an agent might struggle to pick the right tool for metadata vs. statistics.

Naming Consistency4/5

All tools follow a verb_noun pattern (get, read, create, insert, list, search, convert, merge), which is consistent. Minor deviations include mixing 'read' and 'get' for similar actions, and suffixes like 'at_position' vs. 'docx' are not uniform, but the overall pattern is readable.

Tool Count5/5

11 tools is within the ideal 3-15 range and each tool seems to serve a distinct function in document processing. The count feels well-scoped and not bloated.

Completeness3/5

The surface covers reading, creating, inserting, converting, and merging documents, but lacks obvious operations like deleting or updating documents, and spreadsheet write capabilities are absent. This may force an agent to work around missing functionality for typical office document workflows.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

stagenth · 文档生成 A
com.stagenth
Generate PDF, Word (.docx) and PowerPoint (.pptx) documents from Markdown over MCP.
File Systems Workplace & Productivity
33
powerpoint-engineOAuth
io.powerpointengine
Generate, edit, merge, translate and PDF-convert PowerPoint (.pptx) over MCP. 8 tools.
Workplace & Productivity File Systems
2
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
agentdocsOAuth
io.github.dancourse
An agent-first office suite Claude & ChatGPT read and write over one MCP URL.
Workplace & Productivity Documentation Access
2

Related MCP Servers

Office MCP Server
File Systems Workplace & Productivity
Alex-eng-ux
F
license
A
quality
C
maintenance
MCP server for Microsoft Office file operations. Read, write, and create Excel, Word, and PowerPoint files directly from your local filesystem.
Updated 3 months ago (2026-06-03 13:02 UTC)
12
-
office-mcp
Workplace & Productivity File Systems App Automation
gawirable
A
license
A
quality
B
maintenance
MCP server for reading, writing, editing, formatting, and exporting Microsoft Office documents (Word, Excel, PowerPoint) via stdio JSON-RPC, with 47 tools and cross-platform support.
Updated 3 months ago (2026-06-18 12:32 UTC)
47
MIT
animus-document-engine
Workplace & Productivity Developer Tools
launchapp-dev
F
license
A
quality
C
maintenance
MCP server for rendering, parsing, converting, and editing Office documents (Excel, PowerPoint, Word) from a structured JSON spec, using LibreOffice WASM for conversion and preview.
Updated 2 months ago (2026-07-16 21:54 UTC)
5
1
-
Office-MCP-Server
Workplace & Productivity File Systems
stoyantsiparov
A
license
B
quality
A
maintenance
Provides MCP tools for working with Microsoft Word documents, enabling reading, editing with tracked changes, formatting, table manipulation, comments, and PDF conversion via direct OOXML manipulation.
Updated a month ago (2026-08-05 14:14 UTC)
37
MIT

Appeared in Searches

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/as7722314/mcp-office-parser'

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