Skip to main content
Glama
PeterHeick

odt-mcp-server

by PeterHeick
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript

ODT MCP Server

npm version License: MIT Node.js Version TypeScript

A Model Context Protocol (MCP) server for handling OpenDocument Text (.odt) files. This server enables AI assistants to read, analyze, and extract data from ODT documents.

Features

  • Read ODT text: Extract clean text from ODT documents

  • Get metadata: Retrieve document information like author, title, date, etc.

  • List archive contents: See all files contained in the ODT archive

  • Extract raw XML: Access the underlying XML files (content.xml, styles.xml, meta.xml)

Related MCP server: DOCX MCP Server

Prerequisites

  • Node.js v18.0.0 or later

  • npm (included with Node.js)

Installation

npm install
npm run build
npm link

Quick Start

🚀 Try the Interactive Demo

# Run the full-featured demo
cd examples
node demo.js

# Or test with your own ODT file  
node demo.js path/to/your/file.odt

As MCP Server

The server is designed to be used as an MCP server with AI assistants like Claude or other MCP-compatible clients.

# Run the server directly
./build/index.js

# Or after npm link, run globally
odt-mcp-server

Available Tools

1. read_odt

Reads and extracts clean text from an ODT file.

Input:

  • file_path (string): Path to the ODT file

Output: Clean text from the document

2. get_odt_metadata

Retrieves metadata from the ODT file's meta.xml.

Input:

  • file_path (string): Path to the ODT file

Output: JSON object with document metadata

3. list_odt_files

Lists all files in the ODT archive.

Input:

  • file_path (string): Path to the ODT file

Output: List of filenames in the archive

4. extract_odt_xml

Extracts raw XML content from a specific file in the ODT archive.

Input:

  • file_path (string): Path to the ODT file

  • xml_file (string): Name of the XML file (e.g., 'content.xml', 'styles.xml', 'meta.xml')

Output: Raw XML content

MCP Configuration

To use this server with an MCP client, add the following to your configuration:

{
  "mcpServers": {
    "odt": {
      "command": "odt-mcp-server"
    }
  }
}

Note: After running npm link, the odt-mcp-server command will be globally available.

Development

# Build the project
npm run build

# Build in watch mode
npm run watch

Technical Details

  • Runtime: Node.js with ES modules

  • Dependencies:

    • @modelcontextprotocol/sdk: MCP SDK

    • adm-zip: ZIP archive handling

    • xml2js: XML parsing

  • Type definitions: Full TypeScript support

About the ODT Format

OpenDocument Text (.odt) files are ZIP archives that contain:

  • content.xml: The document's main content

  • meta.xml: Metadata (author, title, etc.)

  • styles.xml: Formatting and styles

  • META-INF/manifest.xml: Archive manifest

  • Other resources (images, fonts, etc.)

This server provides structured access to all these components through the MCP protocol.

Contributing

Contributions are welcome! Here's how you can help:

  1. Report Issues: Found a bug or have a feature request? Open an issue

  2. Submit Pull Requests: Fork the repository, make your changes, and submit a pull request

  3. Improve Documentation: Help make the documentation clearer and more comprehensive

  4. Test with ODT Files: Test with various ODT files and report compatibility issues

Development Setup

git clone https://github.com/PeterHeick/odt-mcp-server.git
cd odt-mcp-server
npm install
npm run build
npm run watch  # For development with auto-rebuild

Please ensure your code follows the existing style and includes appropriate tests.

License

MIT - Feel free to use this project for any purpose, commercial or non-commercial. See the full license text for details.

Available Tools

3 tools
extract_odt_xmlA

Udtrækker rå XML fra en specifik fil i .odt arkivet (content.xml, styles.xml, meta.xml)

ParametersJSON Schema
NameRequiredDescriptionDefault
xml_fileYesNavn på XML fil (f.eks. 'content.xml', 'styles.xml', 'meta.xml')
file_pathYesSti til .odt filen

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations provided, the description carries full behavioral disclosure burden, yet only states the basic action. No details on side effects, permissions, or error conditions.

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

Conciseness5/5

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

The description is a single concise sentence that front-loads the action and context. No redundant or missing words.

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

Completeness3/5

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

For a simple 2-parameter tool with no output schema, the description adequately conveys the core function. However, it omits details about return format, error handling, or performance considerations.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains both parameters. The description adds example values (content.xml, styles.xml, meta.xml) but does not significantly enhance understanding beyond the schema.

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

Purpose5/5

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

The description clearly states the verb 'udtrækker' (extracts) and the resource 'rå XML fra en specifik fil i .odt arkivet', distinguishing it from siblings like get_odt_metadata and list_odt_files.

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

Usage Guidelines3/5

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

The description implies usage for extracting raw XML from specific ODT archive files, but lacks explicit when-to-use or when-not-to-use guidance and does not mention alternatives.

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

get_odt_metadataA

Henter metadata fra en .odt fil (forfatter, titel, dato, osv.)

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesSti til .odt filen

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It correctly implies a read-only operation ('Henter' = retrieves) and discloses the return type (metadata). However, it does not mention potential failure modes (e.g., file not found), performance characteristics, or any side effects. This is adequate but minimal.

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

Conciseness5/5

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

The description is a single sentence that conveys the essential purpose without extraneous words. It is front-loaded and efficient. Every word contributes meaning.

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 simple tool (one required parameter, no output schema, no nested objects), the description provides sufficient context: it names example metadata fields (author, title, date) to set expectations. While it could mention return format or error conditions, the current level is adequate for typical usage.

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% for the single parameter 'file_path', with a description in the schema. The tool description does not add extra meaning to the parameter itself but provides context about what metadata is returned (author, title, date). Per guidelines, with high schema coverage, baseline is 3, and the description does not exceed that.

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

Purpose5/5

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

The description clearly states the tool's action ('Henter metadata') and resource ('.odt fil'). It distinguishes from sibling tools by focusing on metadata retrieval vs file listing (list_odt_files) or XML extraction (extract_odt_xml). The verb and object are specific.

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

Usage Guidelines3/5

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

The description implies usage context (when you need metadata like author, title, date) but does not explicitly state when to use this tool over siblings or provide exclusions. With sibling tools present, more explicit guidance would help, but the purpose is clear enough for basic discrimination.

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

list_odt_filesB

Lister alle filer indeholdt i .odt arkivet

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesSti til .odt filen

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, permissions, side effects, or output format. Only lists files.

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?

Single sentence, zero waste, front-loaded with the core action. Highly concise.

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

Completeness3/5

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

For a simple listing tool with no output schema, the description is adequate but lacks details about the output format (e.g., list of filenames). Could be 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 coverage is 100%, so baseline is 3. The description does not add additional meaning beyond what the schema already provides for the single parameter file_path.

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 lists all files inside a .odt archive, which is a specific verb+resource. It distinguishes from sibling tools get_odt_metadata and extract_odt_xml by focusing on listing files.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or when not to use it.

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.

  1. 3 tool updatesv1.0.0
    • First observedextract_odt_xml
    • First observedget_odt_metadata
    • First observedlist_odt_files
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.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinctly different purpose: metadata retrieval, file listing, and XML extraction from ODT archives. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow the same verb_odt_noun pattern (get, list, extract) with consistent snake_case and meaningful verbs.

Tool Count4/5

Three tools is a reasonable size for a focused read-only ODT server. It covers core read operations without unnecessary bloat, though it could benefit from slightly more depth.

Completeness3/5

Covers metadata, file enumeration, and raw XML extraction, but lacks tools for extracting plain text or converting formats. The set is adequate for basic inspection but leaves agents to parse XML themselves.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • DOCX MCP Server

    zeph-gh
    F
    license
    A
    quality
    D
    maintenance
    A comprehensive Model Context Protocol server that processes Microsoft Word documents with full formatting support, enabling text extraction, HTML/Markdown conversion, structure analysis, and image extraction.
    5
    2
    -