Skip to main content
Glama
ExaDev

document-mcp

by ExaDev
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Convert ODM master document to PDF

odm_to_pdf

Convert .odm master documents to PDF by resolving each external chapter from explicit mappings or a directory, failing if any chapter is missing.

Instructions

Converts a .odm (ODF master document) to PDF. A .odm never carries its own chapters' content inline -- every text:section is a bare external reference to a standalone .odt file -- so each chapter the master document declares must resolve through chapters (an explicit href -> document override) and/or chaptersDir (a directory searched by the href's own basename), checked in that order. A chapter left unresolved by both fails the whole conversion, naming every unresolved href.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outputNoWhere to write the resulting PDF. Omit to receive the bytes inline, base64-encoded.
sourceYesThe .odm master document to convert.
chaptersNoExplicit href -> chapter document overrides. Checked before chaptersDir for a given href.
chaptersDirNoDirectory to search for each unresolved chapter href, matched by the href's own basename. Checked after chapters.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv2.1.8
    • changedInput schema / properties / chapters / items / properties / source / anyOf
      Previous value: -[
-  {
-    "properties": {
-      "path": {
-        "description": "Filesystem path to the document to read. The document format is inferred from the file extension.",
-        "type": "string"
-      }
-    },
-    "required": [
-      "path"
-    ],
-    "type": "object"
-  },
-  {
-    "properties": {
-      "bytesBase64": {
-        "description": "Base64-encoded document bytes.",
-        "type": "string"
-      },
-      "format": {
-        "description": "The document format of bytesBase64 -- required, since inline bytes carry no filename to infer it from.",
-        "enum": [
-          "docx",
-          "pptx",
-          "xlsx",
-          "odt",
-          "odp",
-          "ods",
-          "odg",
-          "odf",
-          "markdown",
-          "pdf"
-        ],
-        "type": "string"
-      }
-    },
-    "required": [
-      "bytesBase64",
-      "format"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "properties": {
+      "path": {
+        "description": "Filesystem path to the document to read. The document format is inferred from the file extension.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "path"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "bytesBase64": {
+        "description": "Base64-encoded document bytes.",
+        "type": "string"
+      },
+      "format": {
+        "description": "The document format of bytesBase64 -- required, since inline bytes carry no filename to infer it from.",
+        "enum": [
+          "docx",
+          "pptx",
+          "xlsx",
+          "odt",
+          "odp",
+          "ods",
+          "odg",
+          "svg",
+          "odf",
+          "csv",
+          "markdown",
+          "pdf"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "bytesBase64",
+      "format"
+    ],
+    "type": "object"
+  }
+]
  2. Addedv1.1.6

TDQS

A4.3/5.0
Behavior4/5

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

Since no annotations are provided, the description carries the full burden. It discloses the failure condition (unresolved chapters abort the conversion and list the missing hrefs) and the resolution order, which is non-obvious. It does not mention side effects or permissions, but the conversion context implies non-destructive behavior.

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, well-structured paragraph that leads with the core purpose, then explains the critical ODM quirk, and finally details resolution logic and failure mode. Every sentence contributes essential information with no filler, and the structure is logical and front-loaded.

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?

Given the complexity of the tool (nested parameters, chapter resolution), the description fully addresses the key non-obvious behavior—chapter resolution—which is essential for correct usage. With a comprehensive input schema and an output schema present, the description does not need to elaborate on return formats or parameter details, making it 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?

The input schema already provides detailed descriptions for all parameters, including the resolution order and defaults, achieving 100% coverage. The tool description adds value by summarizing the overall flow and failure consequence, but it does not introduce new parameter-level semantics beyond what the schema already conveys.

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 begins with 'Converts a .odm (ODF master document) to PDF,' clearly stating the specific verb and resource. It further explains the unique structure of ODM files, distinguishing this tool from generic conversion tools like convert_document by emphasizing the chapter resolution mechanism.

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 clearly indicates this tool is for ODM to PDF conversion by explaining the ODM-specific chapter handling. However, it does not explicitly mention alternatives like convert_document or state when not to use it, so it lacks explicit exclusion guidance.

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

Install Server

Other Tools

Latest Blog Posts

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/ExaDev/document-mcp'

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