Skip to main content
Glama
Sign In
document-mcp

document-mcp

by ExaDev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Render .odb report

odb_render_report

Resolve and render an .odb database's embedded report to DOCX, ODT, or PDF. The report's data-bound SQL query runs, formulas are evaluated, and bands are laid out before output.

Instructions

Resolves one of an .odb database's own reports -- its data-bound command run through the bounded SQL engine, its rpt: formulas evaluated, its bands laid out -- and renders the result to docx, odt, or pdf.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "source": "<source>",
      "targetFormat": "<targetFormat>"
    },
    "name": "odb_render_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
fontsNoExtra font faces to make available, for a family the rendered report's own text otherwise falls back on. Only consulted when targetFormat is 'pdf' -- docx and odt output is genuine editable text with no font-embedding step of its own, so fonts is ignored for those two targets.
outputNoWhere to write the rendered report. Omit entirely (or omit outputPath within it) to receive the bytes inline instead.
reportNoThe name of the report to render. Required only when the .odb declares more than one report -- omitting it when exactly one is declared renders that one automatically.
sourceYes.odb database to render a report from. 'path' points at the .odb file on disk -- its extension is never used to infer a document format, since documents.js deliberately excludes 'odb' from DocumentFormat (an embedded database front end has no single natural target format -- tables, saved queries, and reports are three unrelated output shapes -- see that package's own README). 'bytesBase64' carries the .odb bytes inline; its 'format' field is required by the shared hybrid input shape but unused by this tool.
targetFormatYesThe format to render the report into.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.8
    • changedInput schema / 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

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the transparency burden. It adds useful internal context by describing the data-bound command execution through the bounded SQL engine, formula evaluation, and band layout. However, it does not explicitly state whether the operation is read-only or whether the source .odb is modified, leaving side effects unaddressed.

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 a single, information-dense sentence that front-loads the core action ('Resolves') and resource, then adds internal detail and output formats. It is not overly verbose, though the internal parenthetical elements make it slightly dense.

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 plus the extensive input schema and output schema cover report selection, source input (path or bytes), output destination (path or inline), and format-specific nuances (fonts only for pdf). Given the tool's complexity, the combined context is nearly complete, though an explicit statement on side effects would make it comprehensive.

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 schema already provides 100% parameter descriptions, including conditional requirements, source handling, output options, and format-specific notes. The tool description itself does not add significant parameter-level meaning, so a baseline score 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 opens with the specific verb 'Resolves' and names the resource ('one of an .odb database's own reports'), then enumerates the output formats (docx, odt, pdf). This clearly distinguishes it from sibling tools like odb_reports, which likely only list reports, and odb_query, which executes queries.

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 and schema give clear context for when to use the tool: to render an .odb report to a document format. It details conditional behavior (e.g., 'report' optional when only one exists, fonts only for pdf). However, it does not explicitly name alternatives or state when not to use this tool (e.g., for tables/queries), so it falls short of the top score.

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

Deploy Server

Other Tools