Skip to main content
Glama
leanzero-srl

MCP Document Processor

Official
by leanzero-srl
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

MCP Document Processor

An MCP (Model Context Protocol) server for reading, creating, and managing PDF, DOCX, and Excel documents. Built for AI agents that need to process documents with professional styling, automatic categorization, and intelligent document management.

Part of the LeanZero ecosystem.

Features

  • Read any document -- PDF, DOCX, and Excel with OCR support for image-based PDFs

  • Create polished documents -- DOCX, Markdown, and Excel with 8 style presets (including a "claude-like" modern professional look), proper rendering of bullet/numbered lists, blockquotes, hyperlinks, code blocks, and tables embedded in markdown content

  • Generic read & upload bridges -- both read-doc and the create tools accept an HTTPS URL + Bearer auth so any Forge app, Cloudflare Worker, AWS Lambda, Express server, or other backend can plug in. doc-processor speaks one wire contract; you build the receiver however you like. CogniRunner's Jira-attachment bridge is the reference implementation, but the pattern is generic. Existing local-file callers are unaffected.

  • Polished or verbose output -- clientHint parameter lets host applications request a concise human-facing message or the full agent metadata response.

  • Document DNA -- project-level identity system that automatically applies styling, headers, and footers

  • Auto-categorization -- classifies documents into 6 categories (contracts, technical, business, legal, meeting, research) and organizes them into subfolders

  • Blueprint system -- structural templates extracted from existing documents or auto-learned from recurring patterns

  • Drift detection -- monitor documents for structural changes over time with fingerprint-based comparison

  • Lineage tracking -- automatic provenance chains that record which source documents informed each created document

  • Duplicate prevention -- atomic file locking and registry-based title matching to prevent overwrites

  • Document registry -- searchable index of all created documents with category, tag, and title filtering

Related MCP server: PDF Reader MCP Server

Tools

The server exposes 13 tools via the MCP protocol. Each tool uses an action or mode parameter for sub-operations where applicable.

Tool

Actions / Modes

Description

read-doc

summary, indepth, focused

Read and analyze PDF, DOCX, or Excel files. Summary gives an overview; indepth extracts full text and metadata; focused answers specific queries. Source can be a local filePath OR a remote url + authHeader -- see Reading from remote URLs.

detect-format

--

Recommend document format and tone (markdown / docx / excel) based on user query, title, and optional content preview. Call before create-* when the format is not specified.

create-doc

--

Create a Word DOCX with paragraphs, tables, headers, footers, and styling. Supports dry run preview.

create-markdown

--

Create a Markdown document.

create-excel

--

Create an Excel XLSX workbook with multiple sheets and styling.

edit-doc

append, replace

Edit existing DOCX files. Append preserves formatting via XML patching; replace overwrites content.

edit-excel

append-rows, append-sheet, replace-sheet

Edit existing Excel workbooks.

list-documents

--

Search and filter the document registry by category, tags, or title.

list-templates

--

List available blueprint templates that create-doc can validate against.

dna

init, get, evolve, save-memory, delete-memory

Manage Document DNA -- the project's automatic styling and identity system.

blueprint

learn, list, delete

Manage structural blueprints. Auto-learned during dna evolve or manually extracted from existing documents.

drift-monitor

watch, check

Register documents for monitoring and detect structural changes over time.

get-lineage

--

Trace the provenance chain for any document -- which sources informed it and what was derived from it.

Note: All old tool names from previous versions (get-doc-summary, get-doc-indepth, get-doc-focused, init-dna, get-dna, evolve-dna, save-memory, delete-memory, learn-blueprint, list-blueprints, watch-document, check-drift, search-registry) are accepted as backward-compatible aliases.

Polished output for human-facing UIs (clientHint)

create-doc, create-markdown, and create-excel accept an optional clientHint parameter:

  • "interactive" → response message is a single line (Created: <path>); chatty fields like enforcement, styleConfig, lineage, memoriesApplied are omitted. Use this when an end-user reads the response directly (e.g. CogniRunner showing the result in a Jira comment).

  • "agent" → verbose response with all metadata for AI consumption. This is the default behaviour.

  • "auto" → run a heuristic on the input shape, fall back to MCP_CLIENT_TYPE env var, then to "agent".

Set MCP_CLIENT_TYPE=interactive in the MCP server's environment to make "auto" resolve to interactive across all calls.

Generic remote-read bridge — read files from any authenticated endpoint

read-doc works on local files OR on a remote HTTPS URL guarded by a Bearer header. The remote shape is the mirror image of the upload bridge below — same wire contract, same security guarantees, same generic philosophy. doc-processor doesn't care what's on the other side; any HTTPS endpoint that returns the JSON envelope works.

Reference implementation: CogniRunner — Forge web trigger that exposes Jira attachments to local LM Studio inference, behind a one-shot capability. Use it as a template for your own bridge.

Decision: when does it activate?

The remote-read path fires if and only if BOTH url and authHeader are passed (and filePath is not). Otherwise read-doc works on the local path as before. Existing local-file callers are 100% unaffected.

Calling shape

{
  "url": "https://your-receiver.example/attachments/123?t=<token>",
  "authHeader": "Bearer <bearer>",
  "mode": "summary"
}

Wire contract

The endpoint is expected to return HTTP 200 with Content-Type: application/json and a body of:

{
  "data":     "<base64-encoded file content>",
  "filename": "invoice.pdf",
  "mimeType": "application/pdf",
  "size":     256832
}

read-doc decodes the base64 payload, writes it to a unique per-call temp directory under os.tmpdir(), runs the existing PDF/DOCX/XLSX extraction pipeline, and cleans up the temp dir afterward (even if the pipeline throws).

Security guarantees

Same as the upload bridge — see the next section for the full list. In short:

  • HTTPS only, no redirects, no auto-retry on 4xx, auth header never logged, URL token redacted in logs, 30-second timeout, payload size capped by READ_DOC_MAX_BYTES (default 50 MB).

Build your own remote-read source

It's the inverse of the upload receiver, so the same Forge / Express skeletons in the next section apply. For Forge, instead of POSTing to /rest/api/3/issue/{key}/attachments, GET from /rest/api/3/attachment/content/{id} and base64-encode the response into the JSON envelope shape above. The CogniRunner repo has the full pattern.

mcp.json example

{
  "mcpServers": {
    "doc-processor": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-doc-processor/src/index.js"],
      "env": {
        "READ_DOC_MAX_BYTES": "52428800",
        "WRITE_DOC_MAX_BYTES": "26214400",
        "MCP_CLIENT_TYPE": "agent"
      }
    }
  }
}

The application that hosts the model (CogniRunner, your own Forge app, Claude Desktop with extra context, an internal post-function, etc.) injects the per-call url/authHeader for read OR uploadUrl/uploadAuthHeader for write into the model's prompt. doc-processor never sees the application — it just speaks the wire contract.

Generic upload bridge — attach files to any authenticated endpoint

create-doc, create-markdown, and create-excel can OPTIONALLY upload the file they just wrote to any HTTPS endpoint that implements a small, well-defined contract. Use this to:

  • Attach a generated document to a Jira issue (Atlassian Forge)

  • Drop a generated workbook into a Slack channel via a Slack-bot lambda

  • Push a generated markdown file to a GitHub issue via a tiny proxy

  • Send a generated PDF to a Cloudflare R2 / S3 signed-URL receiver

  • Hook into your internal document-management system

doc-processor doesn't know or care what's on the other side. It just speaks one well-defined wire contract; you build the receiver however you like.

Reference implementation: CogniRunner — a Forge app that exposes a per-issue, single-use upload capability so an LM Studio model can attach generated docs back to Jira tickets. The CogniRunner web trigger is ~150 lines and worth reading if you're building your own receiver.

Decision: when does it activate?

The upload bridge fires if and only if BOTH uploadUrl and uploadAuthHeader are present in the call. Otherwise the tool behaves exactly as before — writes the file locally, returns the path, no upload-related fields in the response. Existing callers and "normal" agent flows are 100% unaffected.

Caller passes

Behavior

Neither uploadUrl nor uploadAuthHeader

Local write only. Response has no upload-related fields. (default)

Both

Local write then upload. Response gains uploaded, uploadAttachment, uploadStatus, uploadError.

Only one

Local write succeeds. Response has uploaded: false, uploadError: "uploadUrl and uploadAuthHeader must be provided together". fetch is never called.

The model decides per-call. If your application injects upload credentials into the model's context (system prompt or per-tool extra args), the model uses them. If you don't, the model ignores those fields — there's nothing for it to fill in.

Wire contract

Request (doc-processor → your receiver)

POST <uploadUrl>
Authorization: <uploadAuthHeader>
Content-Type: application/json
Accept: application/json

{
  "data":     "<base64-encoded file bytes>",
  "filename": "q1-2026-strategy.docx",
  "mimeType": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
  "size":     27834
}

Success response (your receiver → doc-processor)

HTTP 200, Content-Type: application/json:

{
  "success": true,
  "attachment": {
    "id":       "<your-target-id>",
    "filename": "q1-2026-strategy.docx",
    "size":     27834,
    "mimeType": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
    "content":  "<URL or pointer the user can use to access the uploaded file>"
  }
}

The attachment.content field is what gets shown in the model's interactive-mode response message — it should be a usable URL (e.g. the Jira attachment content URL) so end-users get a working link.

doc-processor tolerates any 2xx JSON shape — if attachment is missing it uses the whole body, but the strict shape above is recommended.

Failure responses

doc-processor surfaces these verbatim as uploadError and does not auto-retry:

Status

Meaning

400

malformed envelope

401

bearer mismatch

404

token expired / consumed (single-use)

413

payload too large for receiver

415

disallowed mimeType / extension

502

receiver's upstream (e.g. Jira) failed

500

unexpected receiver error

Receivers MUST NOT respond with 3xx — fetch is configured with redirect: "error" and aborts on any redirect.

Security guarantees the SENDER (doc-processor) provides

  • HTTPS only. Non-https:// URLs are rejected before fetch is called.

  • No redirects. redirect: "error" — receiver must respond directly.

  • No auto-retry on any 4xx/5xx. Single-use semantics are honored end-to-end.

  • uploadAuthHeader is never logged at any level.

  • URL ?t= token is redacted in log output — only host+path are emitted.

  • No caching. Bytes, URL, auth header live only for the duration of one call.

  • Bounded payload size. Capped by WRITE_DOC_MAX_BYTES env var (default 25 MB).

  • 60-second timeout on the upload fetch.

  • Local file is kept on upload failure — your caller can retry or fall back to the local path.

What your RECEIVER should provide

  • HTTPS endpoint with a valid certificate.

  • One-shot capability semantics if you're using URL+bearer pairs (mint per request, store with TTL, delete-on-consume, constant-time bearer compare).

  • Don't 3xx — return 4xx/5xx with a JSON body.

  • Validate filename extension on the receiver side; don't trust the envelope's mimeType field as authoritative.

  • Audit-log the upload event (caller, target, filename, bytes).

Build your own receiver

Atlassian Forge web trigger (the CogniRunner pattern)

Receives the JSON envelope, validates a one-shot capability, forwards to Jira's attachment endpoint via api.asApp().requestJira(). Skeleton (~50 lines):

import api, { route } from "@forge/api";
import storage from "@forge/kvs";
import FormData from "form-data";
import { timingSafeEqual } from "node:crypto";

export async function serveAttachmentUpload(request) {
  const token = request.queryParameters?.t?.[0];
  if (!token) return { statusCode: 404, body: "" };

  const auth = request.headers?.authorization?.[0] || "";
  if (!auth.startsWith("Bearer ")) return { statusCode: 401, body: "" };
  const bearer = auth.slice(7);

  const cap = await storage.get(`uploadcap:${token}`);
  await storage.delete(`uploadcap:${token}`);   // single-use: consume BEFORE any work
  if (!cap || cap.expiresAt < Date.now()) return { statusCode: 404, body: "" };

  const a = Buffer.from(cap.bearer, "utf8");
  const b = Buffer.from(bearer, "utf8");
  if (a.length !== b.length || !timingSafeEqual(a, b)) return { statusCode: 401, body: "" };

  const envelope = JSON.parse(request.body);
  if (typeof envelope.data !== "string") return { statusCode: 400, body: '{"error":"missing data"}' };

  const buf = Buffer.from(envelope.data, "base64");
  if (buf.length > 25 * 1024 * 1024) return { statusCode: 413, body: "" };

  const allowed = new Set([".pdf", ".docx", ".xlsx", ".md", ".txt", ".csv"]);
  const ext = (envelope.filename.match(/\.[^.]+$/) || [""])[0].toLowerCase();
  if (!allowed.has(ext)) return { statusCode: 415, body: "" };

  const form = new FormData();
  form.append("file", buf, { filename: envelope.filename, contentType: envelope.mimeType, knownLength: buf.length });

  const jiraResp = await api.asApp().requestJira(
    route`/rest/api/3/issue/${cap.issueKey}/attachments`,
    { method: "POST", body: form, headers: { Accept: "application/json", "X-Atlassian-Token": "no-check" } },
  );
  if (!jiraResp.ok) return { statusCode: 502, body: '{"error":"jira upstream failed"}' };

  const created = (await jiraResp.json())[0];
  return {
    statusCode: 200,
    headers: { "Content-Type": ["application/json"] },
    body: JSON.stringify({
      success: true,
      attachment: {
        id: created.id,
        filename: created.filename,
        size: created.size,
        mimeType: created.mimeType,
        content: created.content,
      },
    }),
  };
}

Express server (for local testing or non-Forge use cases)

import express from "express";
import { randomUUID } from "node:crypto";

const app = express();
app.use(express.json({ limit: "30mb" }));

const TOKEN = "test-token-123";
const BEARER = "Bearer test-bearer-456";

app.post("/upload", (req, res) => {
  if (req.query.t !== TOKEN) return res.status(404).end();
  if (req.headers.authorization !== BEARER) return res.status(401).end();

  const { data, filename, mimeType, size } = req.body;
  if (!data) return res.status(400).json({ error: "missing data" });

  const buf = Buffer.from(data, "base64");
  if (buf.length > 25 * 1024 * 1024) return res.status(413).end();

  // Persist the file or forward it somewhere — your call.
  console.log(`Received ${filename} (${mimeType}, ${size} bytes)`);

  res.json({
    success: true,
    attachment: {
      id: randomUUID(),
      filename,
      size: buf.length,
      mimeType,
      content: `https://your-storage.example/files/${filename}`,
    },
  });
});

app.listen(8443);

(For production, terminate TLS in front via a real cert — doc-processor refuses non-HTTPS.)

Calling shape (what you put in the model's tool args)

{
  "title": "Q1 2026 Engineering Strategy",
  "paragraphs": ["..."],
  "uploadUrl": "https://your-receiver.example/upload?t=<one-shot-token>",
  "uploadAuthHeader": "Bearer <one-shot-bearer>",
  "uploadFilename": "q1-2026-strategy.docx",
  "clientHint": "interactive"
}

The uploadFilename is optional and overrides the default (the local file's basename). Useful when duplicate prevention auto-suffixes the local filename and you still want a clean name on the receiver side.

Response shape (when upload was attempted)

The handler appends four fields to its normal response only when an upload was attempted (when both upload params were supplied). For "normal" agent calls without upload params, none of these fields appear.

Field

Type

Description

uploaded

boolean

true if 2xx, false if any error path

uploadAttachment

object | null

Whatever the receiver returned in attachment

uploadStatus

number | null

HTTP status code from the receiver

uploadError

string | null

Error message if the upload failed

In clientHint: "interactive" mode the response message collapses to one line:

  • Success: Created and uploaded: <path> → <attachment-content-url>

  • Failure: Created locally at <path>; upload failed: <error>

Quick Start

Installation

npm install

MCP Configuration

Add to your MCP client configuration (e.g., mcp.json, cline_mcp_settings.json, or equivalent):

{
  "mcpServers": {
    "doc-processor": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-doc-processor/src/index.js"],
      "env": {}
    }
  }
}

With Vision OCR (cloud)

{
  "mcpServers": {
    "doc-processor": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-doc-processor/src/index.js"],
      "env": {
        "Z_AI_API_KEY": "your-api-key"
      }
    }
  }
}

Running

npm start

The server communicates over stdio using the MCP JSON-RPC protocol. It is designed to be launched by an MCP client, not run interactively.

Style Presets

Eight built-in presets control document typography, spacing, and table formatting. The default for general-purpose create-doc calls is claude-like.

Preset

Font

Body Size

Key Traits

claude-like

Calibri

11pt

Default. Modern blue accents, generous whitespace, proper bullet/numbered lists, blockquotes, hyperlinks, inline tables — looks like a polished Claude chat answer rendered as a document

minimal

Arial

11pt

Clean, Swiss-style, subtle borders, light zebra striping

professional

Garamond

11pt

Serif, justified, small caps title, double-spaced headings

technical

Arial / Segoe UI

11pt

Left-aligned, strong hierarchy, high-contrast tables

legal

Times New Roman

12pt

Double-spaced, underlined headings, no decorative elements

business

Calibri / Calibri Light

11pt

Blue accent palette, centered title with bottom border

casual

Verdana / Trebuchet MS

12pt

Warm orange accents, friendly newsletter style

colorful

Segoe UI

11pt

Purple-teal gradient accents, vibrant table headers

Categories auto-select an appropriate preset when none is specified:

Category

Auto-Selected Preset

contracts

legal

legal

legal

technical

technical

business

business

meeting

professional

research

professional

Enhanced Styling System

The enhanced styling system provides advanced typography and formatting capabilities through the src/tools/styling.js module:

Color Constants

The system includes 20+ named color constants for consistent styling:

Color Name

Hex Code

Usage

WHITE

FFFFFF

Backgrounds, primary text

BLACK

1A1A1A

Primary text, dark elements

BLUE

2563EB

Primary accent, links

GREEN

22C55E

Success states, positive indicators

RED

EF4444

Error states, warnings

YELLOW

EAB308

Highlights, attention

ORANGE

F97316

Warm accents

PURPLE

A855F7

Creative accents

TEAL

14B8A6

Secondary accents

INDIGO

6366F1

Professional accents

GRAY_50

F9FAFB

Light backgrounds

GRAY_100

F3F4F6

Subtle backgrounds

GRAY_200

E5E7EB

Borders, dividers

GRAY_300

D1D5DB

Light borders

GRAY_400

9CA3AF

Secondary text

GRAY_500

6B7280

Tertiary text

GRAY_600

4B5563

Secondary content

GRAY_700

374151

Primary content

GRAY_800

1F2937

Dark content

GRAY_900

111827

Darkest elements

Page Layout Helpers

Helper

Purpose

PAGE_WIDTH

Standard page width in inches (8.5")

CONTENT_WIDTH

Content area width (6.5")

MARGIN_TOP

Top margin (1")

MARGIN_BOTTOM

Bottom margin (1")

MARGIN_LEFT

Left margin (1")

MARGIN_RIGHT

Right margin (1")

Heading Helpers

Helper

Purpose

heading1(text)

Main document title (Heading 1 style)

heading2(text)

Section headings (Heading 2 style)

heading3(text)

Subsection headings (Heading 3 style)

Text Formatting Helpers

Helper

Purpose

para(text)

Standard paragraph

bold(text)

Bold text

normal(text)

Normal text with optional styling

spacer(height)

Vertical spacing

divider()

Horizontal rule

List Helpers

Helper

Purpose

bulletItem(text)

Bullet list item

subBulletItem(text)

Nested bullet list item

Table Helpers

Helper

Purpose

infoTable(data)

Information table with professional styling

gapTable(data)

Table with spacing between rows

statusBadge(text, status)

Status indicator badge

Page Setup Helpers

Helper

Purpose

createHeader(text, alignment)

Document header

createFooter(text, alignment)

Document footer

createPageProperties()

Page layout properties

Document DNA

Document DNA (.document-dna.json) is a project-level configuration file that automatically applies consistent styling across all documents created by this server.

How It Works

  1. Initialize -- Run dna with action init to create the DNA file with your company name, preferred style, header, and footer defaults.

  2. Automatic application -- Every create-doc call checks for DNA and applies its defaults for any fields not explicitly provided (header, footer, style preset).

  3. Usage tracking -- Each document creation records the category, style, and any overrides to build a usage profile.

  4. Evolve -- Run dna with action evolve to analyze usage patterns. The system suggests mutations when it detects strong trends (e.g., "80% of your documents use the business preset"). Use apply: true to auto-apply the top suggestion.

  5. Auto-learned blueprints -- During evolution, recurring document structures are detected and saved as blueprints automatically. Future documents with matching patterns get a blueprintMatch suggestion in the response.

Memory System

Use dna with action save-memory to store document preferences (e.g., "Always use 1-inch margins for contracts"). Memories persist in the DNA file and are available to AI agents for context.

Inheritance

DNA supports three-level inheritance: System defaults (hardcoded) < Project DNA (.document-dna.json) < User DNA (.document-user.json). Missing fields fall through to the next level.

Environment Variables

Variable

Default

Description

Z_AI_API_KEY

--

API key for vision OCR service (also checks ZAI_API_KEY, ANTHROPIC_AUTH_TOKEN)

Z_AI_BASE_URL

Auto-detect

Override base URL for vision API

Z_AI_VISION_MODEL

glm-4.6v

Vision model name

Z_AI_TIMEOUT

300000

Request timeout in milliseconds

SKIP_TABLE_EXTRACTION

true

Skip table extraction from images during PDF processing

READ_DOC_MAX_BYTES

52428800 (50 MB)

Maximum decoded payload size accepted by the read-doc URL-fetch path. Requests with larger bodies are rejected before the file is materialized.

WRITE_DOC_MAX_BYTES

26214400 (25 MB)

Maximum file size the create-* tools will POST to a remote uploadUrl. Half of the read cap because Forge web trigger payload limits are tighter.

Testing

npm test                    # Markdown format router (custom-assert)
npm run test:read-doc       # read-doc URL-fetch — 14 tests (node:test)
npm run test:schemas        # MCP schema invariants + detect-format E2E — 6 tests (node:test)
npm run test:render         # parseMarkdownToDocx + create-doc round-trip — 15 tests (node:test)
npm run test:upload         # uploadFileToTarget + create-doc upload integration — 18 tests (node:test)
npm run test:all            # Run all five suites in sequence
npm run lint:no-console-log # Fail if any src/ file uses console.log (corrupts MCP stdio)

Generated Files

The server generates several configuration and data files:

.document-dna.json

Document DNA configuration file that stores:

  • Project-level styling defaults (style preset, category, header/footer)

  • Usage statistics (categories, styles, document counts)

  • Memory system (saved document preferences)

  • Auto-learned document structures

This file is automatically managed by the dna tool and should not be manually edited.

.document-blueprints.json

Blueprint repository that stores:

  • Extracted document structures

  • Section patterns and requirements

  • Style preset associations

  • Creation timestamps

Blueprints are created via blueprint action:'learn' or auto-learned during dna evolve.

docs/registry.json

Document registry containing:

  • All created documents with metadata

  • Category, tags, and descriptions

  • Lineage tracking information

  • Timestamps for creation and updates

.document-user.json (optional)

User-level DNA that inherits from project DNA. Allows personal overrides without affecting team settings.

Architecture

mcp-doc-processor/
  src/
    index.js                 # MCP server entry, tool definitions, dispatch
    tools/                   # Tool handlers (one file per tool)
    services/                # Business logic (lineage, drift, blueprints, OCR)
    parsers/                 # File-type parsers (PDF, DOCX, Excel)
    utils/                   # Shared utilities (logger, registry, DNA, categorizer)
  docs/                      # Generated documents (organized by category)
  test/                      # Test suites
  logs/                      # Server logs
  .document-dna.json         # Document DNA configuration
  .document-blueprints.json  # Blueprint repository
  docs/registry.json         # Document registry
  .document-user.json        # Optional user-level DNA

Dependencies

Package

Purpose

@modelcontextprotocol/sdk

MCP server SDK

docx

DOCX generation

jszip

ZIP/DOCX XML manipulation

mammoth

DOCX text extraction

marked

Markdown tokenization for inline formatting

pdf-parse

PDF text extraction

xlsx

Excel reading

xlsx-js-style

Excel writing with styling

License

See LICENSE for details.

Available Tools

17 tools
blueprintA

Manage structural blueprints — section/heading templates extracted from real documents. Actions: 'learn' (extract from a DOCX or PDF you already have), 'list' (show stored blueprints), 'delete' (remove by name). Blueprints are also auto-learned during 'dna evolve' when recurring structures are detected. Use a blueprint by passing { blueprint: '' } to create-doc — the tool will validate that your paragraphs match the structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNoBlueprint name (required for learn and delete).
actionYesBlueprint action.
filePathNoPath to source DOCX/PDF (REQUIRED for 'learn'; ignored otherwise).
descriptionNoOptional description (learn only).

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description must fully cover behavior. It explains the actions and that learn extracts from existing documents, but does not discuss error scenarios (e.g., missing file, duplicate names) or side effects when deleting a blueprint that is in use. More behavioral details would improve transparency.

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 three sentences long, with no wasted words. The first sentence provides the core purpose, the second enumerates actions compactly, and the third gives essential context about integration with create-doc. Information is front-loaded and easy to parse.

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 the main usage scenarios and connects to a sibling tool (dna) for auto-learning. It explains the purpose of each action and parameter. Minor gaps include lack of information on naming constraints, error handling, and whether blueprints are global or workspace-specific. Nonetheless, the description is sufficient for most use cases.

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 adds minimal value beyond the schema; it repeats the required conditions for parameters (e.g., name required for learn/delete, filePath required for learn). However, it does provide context like 'extract from a DOCX or PDF you already have', which clarifies the filePath parameter's intent.

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 defines the tool's purpose: managing structural blueprints extracted from documents. It lists the specific actions (learn, list, delete) and differentiates itself from sibling tools by explaining how blueprints are used with create-doc via the 'blueprint' parameter.

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 explicitly states when to use each action: learn for extracting from DOCX/PDF, list for showing stored blueprints, delete for removal. It also notes that blueprints are auto-learned during 'dna evolve', providing a clear alternative and context for use.

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

create-docA

Create a styled, EDITABLE Word DOCX. USE for stakeholder/business/legal/research deliverables the user will keep editing in Word, or when they say 'Word / .docx / editable / draft / template'. NOT for: a final/print/send-as-PDF deliverable (→ create-pdf), code/API/README docs (→ create-markdown), or tabular/numeric data (→ create-excel). The most full-featured tool: Document DNA defaults, 8 style presets, headers/footers with page numbers, margins, blueprint validation, and real tables. ALWAYS format the body with markdown — never a wall of plain text. Simplest: put the whole body in the content string. Supported markdown: '# H1' '## H2' '### H3' headings; 'bold'; 'italic'; 'code'; '- ' or '1. ' lists; '> ' blockquotes; '---' horizontal rule; fenced code blocks; '| a | b |' GitHub tables (with a '|---|---|' separator row); 'text' links. EXAMPLE content: "## Overview\nThis report covers Q2 results.\n\n### Highlights\n- Revenue up 18%\n- Two new markets\n\n| Metric | Value |\n|---|---|\n| MRR | $42k |\n| Churn | 1.2% |\n\n> Next review: July." Title MUST be specific. Duplicate → { duplicate: true, existingPath } (switch to edit-doc). Response includes formattingQuality and formatSuggestion — if formatSuggestion is set, the content fits another format better, so heed it. Use dryRun: true for preview.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoTags for registry search and discovery.
styleNoAdvanced: fine-grained style overrides merged on top of stylePreset.
titleYesSpecific descriptive title (rejected: 'Document', 'Untitled', etc.). Becomes the document H1.
dryRunNoReturn a preview without writing the file (default: false).
footerNoPage footer: { text, alignment?, color? }. Use {current}/{total} placeholders for page numbers.
headerNoPage header: { text, alignment?: 'left'|'center'|'right', color?: '#hex' }. Applies to every page.
tablesNoOptional tables as 2D arrays. First row is the header.
contentNoPREFERRED. The entire document body as ONE markdown string. Supported markdown: '# H1' '## H2' '### H3' headings; '**bold**'; '*italic*'; '`code`'; '- ' or '1. ' lists; '> ' blockquotes; '---' horizontal rule; ```fenced code blocks```; '| a | b |' GitHub tables (with a '|---|---|' separator row); '[text](https://url)' links. The title is added as the document H1 automatically, so start the body at '## '. EXAMPLE content: "## Overview\nThis report covers **Q2** results.\n\n### Highlights\n- Revenue up *18%*\n- Two new markets\n\n| Metric | Value |\n|---|---|\n| MRR | $42k |\n| Churn | 1.2% |\n\n> Next review: July." Use this instead of `paragraphs` unless you need per-paragraph style objects.
docTypeNoTone and depth of the documentation.
marginsNoPage margins in twips (1440 = 1 inch). Defaults: top/bottom 720 (or 1440 if header/footer set), left/right 1080.
categoryNoDocument category for subfolder organization.
blueprintNoOptional blueprint name to validate the structure against (see list-templates).
uploadUrlNoOPTIONAL. HTTPS URL of a receiver that will accept a JSON envelope `{data:base64, filename, mimeType, size}` POSTed with this Bearer auth. If you have NOT been given an uploadUrl in your context, OMIT this field and the tool just writes the file locally. Single-use semantics — do not retry on 4xx. Works with any compliant receiver (CogniRunner attachment-upload web trigger is the reference implementation, but the contract is generic).
clientHintNoHow the response should be shaped. 'interactive' = polished one-line message for end-users (no chatty registry/lineage notes). 'agent' = verbose response with all metadata for AI consumption. 'auto' (default) = detect from input shape or MCP_CLIENT_TYPE env var, falling back to 'agent'.
outputPathNoOptional. Default: derived from title, placed under docs/<category>/.
paragraphsNoALTERNATIVE to `content`. Document body as an array — each entry a markdown string OR { text, headingLevel: 'heading1'|'heading2'|'heading3' }. Prefer the single `content` string.
descriptionNoBrief description stored in the registry.
stylePresetNoStyle preset. 'claude-like' (modern blue-accented professional) is the default for general-purpose docs. 'professional' is the executive serif look. Auto-selected from category if omitted.
uploadFilenameNoOPTIONAL. Filename to put in the upload envelope. Defaults to the local file's basename. Useful when the local file got auto-suffixed (e.g. duplicate prevention) and you want a clean name on the receiver side.
backgroundColorNoOptional page background hex color, e.g. '#FFFFFF'.
tableHeaderFillNoOptional override for table header cell fill color (hex).
uploadAuthHeaderNoOPTIONAL. Authorization header value for uploadUrl (e.g. 'Bearer abc123'). REQUIRED when uploadUrl is set; ignored otherwise. Never logged.
enforceDocsFolderNoIf false, allow output outside docs/. Default: true (recommended).
preventDuplicatesNoIf false, allow same-title duplicates. Default: true (recommended).

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description covers behavioral traits comprehensively: duplicate detection, response fields (formattingQuality, formatSuggestion), dry-run, upload semantics, and style auto-selection. Lacks explicit statements on idempotency or reversibility, but is very thorough.

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

Conciseness3/5

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

The description is verbose (~400 words) with some redundancy (markdown syntax repeated in description and parameter description). However, it is well-structured with clear sections and examples. Given the tool's complexity, the length is partially justified but could be more concise.

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?

No output schema, but the description mentions response fields (formattingQuality, formatSuggestion) and covers error cases (duplicate), preview, and upload. Lacks full success response format, but is sufficient for an agent to understand the tool's behavior and expectations.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds substantial value beyond schema: it explains preferred usage of `content` vs `paragraphs`, gives detailed markdown syntax, default margin behavior, stylePreset auto-selection, uploadUrl semantics, and provides an example. This far exceeds the baseline.

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 styled, editable Word DOCX, specifies target use cases (stakeholder/business/legal/research deliverables), and explicitly distinguishes from sibling tools like create-pdf, create-markdown, and create-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?

The description provides explicit when-to-use and when-not-to-use guidance, names sibling tools for alternatives, and includes actionable instructions like using markdown for body, duplicate handling, and dry-run preview.

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

create-excelA

Create a styled Excel XLSX (or CSV). USE for ANY tabular/numeric data — budgets, trackers, datasets, KPIs, price lists, schedules; even a table inside a 'report' belongs here, not in a doc. EXCEL SUPERPOWERS: a cell whose string starts with '=' becomes a LIVE formula (e.g. "=SUM(B2:B9)", "=B2C2") that Excel computes on open; columns whose header looks like money ($/price/cost/revenue) or percent (%) auto-format; the header row gets autofilter dropdowns; columns auto-fit. The first row of each sheet is the header (auto-styled bold/filled), body rows get zebra striping — you only supply values. Set outputFormat: "csv" for a plain CSV (first sheet only; no styling/formulas). EXAMPLE: sheets: [{ name: "Q2 Revenue", data: [["Month","Units","Price","Revenue"],["Apr",120,9.99,"=B2C2"],["Total","=SUM(B2:B2)","","=SUM(D2:D2)"]] }]. Sheet names MUST be specific (rejects 'Sheet1', 'Data', etc.). Use dryRun: true for preview.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoTags for registry search and discovery.
styleNoOptional fine-grained overrides merged on top of stylePreset.
titleNoWorkbook title (used for filename, registry, and auto-categorization).
dryRunNoReturn a preview without writing (default: false).
sheetsYesArray of sheet definitions. At least one is required. A cell string starting with '=' becomes a live formula (e.g. "=SUM(B2:B9)").
docTypeNoTone and depth of the documentation.
categoryNoDocument category for subfolder organization.
uploadUrlNoOPTIONAL. HTTPS URL of a receiver that will accept a JSON envelope `{data:base64, filename, mimeType, size}` POSTed with this Bearer auth. If you have NOT been given an uploadUrl in your context, OMIT this field and the tool just writes the file locally. Single-use semantics — do not retry on 4xx. Works with any compliant receiver (CogniRunner attachment-upload web trigger is the reference implementation, but the contract is generic).
clientHintNoHow the response should be shaped. 'interactive' = polished one-line message for end-users (no chatty registry/lineage notes). 'agent' = verbose response with all metadata for AI consumption. 'auto' (default) = detect from input shape or MCP_CLIENT_TYPE env var, falling back to 'agent'.
outputPathNoOptional. Default: derived from title.
descriptionNoBrief description stored in the registry.
stylePresetNoStyle preset. 'claude-like' (modern blue-accented professional) is the default for general-purpose docs. 'professional' is the executive serif look. Auto-selected from category if omitted.
outputFormatNo'xlsx' (default — full styling, formulas, autofilter) or 'csv' (plain text, first sheet only).
uploadFilenameNoOPTIONAL. Filename to put in the upload envelope. Defaults to the local file's basename. Useful when the local file got auto-suffixed (e.g. duplicate prevention) and you want a clean name on the receiver side.
uploadAuthHeaderNoOPTIONAL. Authorization header value for uploadUrl (e.g. 'Bearer abc123'). REQUIRED when uploadUrl is set; ignored otherwise. Never logged.
enforceDocsFolderNoIf false, allow output outside docs/. Default: true.
preventDuplicatesNoIf false, allow same-name duplicates. Default: true.

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries full responsibility for behavioral transparency. It extensively details behaviors: auto-formatting of money/percent columns, live formulas via '=', autofilter on headers, zebra striping, sheet name validation (rejects generic names), dry run for preview, upload URL semantics with single-use and non-retry advice, and default behavior for outputFormat. No contradictions exist, and the coverage is thorough.

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 detailed and includes an embedded example, which adds value but also length. It is well-structured with bold key terms and bullet-like exposition. While it could be slightly more concise, every sentence serves a purpose, and the front-loaded summary ('Create a styled Excel XLSX (or CSV).') immediately conveys the core function.

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 17 parameters, only one required, and no output schema, the description covers all critical aspects: core operation, superpowers, sheet constraints, upload mechanics, style options, dry run, and filing defaults. It leaves no obvious gaps for an agent to misunderstand how to select or invoke the tool.

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

Parameters5/5

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

Although schema description coverage is 100%, the description goes far beyond the schema by explaining how the data parameter works (first row as header, '=' for formulas), how style presets are auto-selected, the effect of dryRun, and the uploadUrl contract (single-use, generic receiver). It adds significant operational context that the schema alone cannot provide.

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 a clear verb and resource: 'Create a styled Excel XLSX (or CSV).' It explicitly states the tool is for tabular and numeric data, listing concrete examples (budgets, trackers, KPIs). It also distinguishes from sibling tools by asserting that tabular content belongs here rather than in a doc, effectively differentiating itself from 'create-doc' and similar tools.

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 clear when-to-use guidance: 'USE for ANY tabular/numeric data' with examples. It also gives a specific negative example: 'even a table inside a report belongs here, not in a doc.' However, it does not explicitly state when NOT to use the tool or mention alternative tools beyond the doc reference. A clear exclusion statement would elevate this to a 5.

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

create-markdownA

Create a Markdown (.md) file for technical/code content that lives in a repo. USE for READMEs, API docs, specs, runbooks, changelogs, integration guides, code-heavy content — anything for GitHub/developers. NOT for stakeholder-facing or printable deliverables (→ create-doc / create-pdf) or tabular data (→ create-excel). MARKDOWN SUPERPOWERS: set toc: true to auto-generate an anchor-linked Table of Contents from the H2/H3 headings; pass frontmatter: {...} to emit YAML frontmatter (title, date, tags[]) for static-site generators (Hugo/Jekyll/Astro). Simplest usage: put the whole body in the content string. Supported markdown: '# H1' '## H2' '### H3' headings; 'bold'; 'italic'; 'code'; '- ' or '1. ' lists; '> ' blockquotes; '---' horizontal rule; fenced code blocks; '| a | b |' GitHub tables (with a '|---|---|' separator row); 'text' links. The title becomes the H1, so start content at '## '. Title MUST be specific. Response includes formattingQuality. Use dryRun: true for preview.

ParametersJSON Schema
NameRequiredDescriptionDefault
tocNoAuto-generate an anchor-linked Table of Contents from the H2/H3 headings, inserted under the title. Great for long READMEs/guides.
tagsNoTags for registry search and discovery.
titleYesSpecific descriptive title (becomes H1; rejected if generic).
dryRunNoReturn a preview without writing (default: false).
contentNoPREFERRED. The entire document body as ONE markdown string. Supported markdown: '# H1' '## H2' '### H3' headings; '**bold**'; '*italic*'; '`code`'; '- ' or '1. ' lists; '> ' blockquotes; '---' horizontal rule; ```fenced code blocks```; '| a | b |' GitHub tables (with a '|---|---|' separator row); '[text](https://url)' links. The title is added as the document H1 automatically, so start the body at '## '. EXAMPLE content: "## Overview\nThis report covers **Q2** results.\n\n### Highlights\n- Revenue up *18%*\n- Two new markets\n\n| Metric | Value |\n|---|---|\n| MRR | $42k |\n| Churn | 1.2% |\n\n> Next review: July." Use this instead of `paragraphs` unless you need per-paragraph style objects.
docTypeNoTone and depth of the documentation.
categoryNoDocument category for subfolder organization.
uploadUrlNoOPTIONAL. HTTPS URL of a receiver that will accept a JSON envelope `{data:base64, filename, mimeType, size}` POSTed with this Bearer auth. If you have NOT been given an uploadUrl in your context, OMIT this field and the tool just writes the file locally. Single-use semantics — do not retry on 4xx. Works with any compliant receiver (CogniRunner attachment-upload web trigger is the reference implementation, but the contract is generic).
clientHintNoHow the response should be shaped. 'interactive' = polished one-line message for end-users (no chatty registry/lineage notes). 'agent' = verbose response with all metadata for AI consumption. 'auto' (default) = detect from input shape or MCP_CLIENT_TYPE env var, falling back to 'agent'.
outputPathNoOptional. Default: derived from title, placed under docs/<category>/.
paragraphsNoALTERNATIVE to `content`. Body as markdown strings or { text, headingLevel } objects. Prefer the single `content` string.
descriptionNoBrief description stored in the registry.
frontmatterNoOptional YAML frontmatter emitted at the very top, e.g. { title, date, tags: [...] } — for static-site generators (Hugo/Jekyll/Astro).
uploadFilenameNoOPTIONAL. Filename to put in the upload envelope. Defaults to the local file's basename. Useful when the local file got auto-suffixed (e.g. duplicate prevention) and you want a clean name on the receiver side.
uploadAuthHeaderNoOPTIONAL. Authorization header value for uploadUrl (e.g. 'Bearer abc123'). REQUIRED when uploadUrl is set; ignored otherwise. Never logged.
enforceDocsFolderNoIf false, allow output outside docs/. Default: true.
preventDuplicatesNoIf false, allow same-title duplicates. Default: true.

TDQS

A4.7/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. Discloses features (toc, frontmatter), markdown syntax, dryRun preview, upload semantics (single-use, no retry), and response includes formattingQuality. Lacks explicit statement on side effects beyond file creation, but overall transparent.

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?

Purpose is front-loaded. Description is thorough but somewhat lengthy; however, each sentence adds value. Could be slightly more concise in listing markdown syntax, but overall well-structured and efficient.

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 17 parameters with 100% schema coverage and no output schema, the description covers all aspects: usage, features, parameter semantics, examples, upload handling, and response content (formattingQuality). Complete and self-contained.

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

Parameters5/5

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

Schema coverage is 100%, but description adds significant value beyond schema: explains relationships (toc with headings, frontmatter for static-site generators), usage patterns (simplest usage with content string, title becomes H1 so start at '## '), and provides a detailed example. Enriches understanding of each parameter.

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?

Explicitly states 'Create a Markdown (.md) file for technical/code content' and distinguishes from siblings by specifying what it is NOT for (stakeholder-facing, printable deliverables, tabular data) and naming alternative tools (create-doc, create-pdf, create-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?

Provides explicit when-to-use (READMEs, API docs, etc.) and when-not-to-use scenarios with clear references to sibling tools (→ create-doc / create-pdf / create-excel).

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

create-pdfA

Create a FINAL, fixed-layout PDF to read / print / send / sign. USE when the user says PDF / print / 'send to the client' / official / invoice / flyer / resume / cover letter / 'read-only' / 'final version'. NOT for content they'll keep editing (→ create-doc) or code/repo docs (→ create-markdown). Rendered from markdown with the same 8 presets as create-doc, via headless Chromium. PDF SUPERPOWER: set toc: true for a clickable Table of Contents (with heading anchors) at the top. Supports headers/footers with {current}/{total} page numbers and margins. ALWAYS format the body with markdown. Easiest: put the whole body in the content string. Supported markdown: '# H1' '## H2' '### H3' headings; 'bold'; 'italic'; 'code'; '- ' or '1. ' lists; '> ' blockquotes; '---' horizontal rule; fenced code blocks; '| a | b |' GitHub tables (with a '|---|---|' separator row); 'text' links. EXAMPLE content: "## Overview\nThis report covers Q2 results.\n\n### Highlights\n- Revenue up 18%\n- Two new markets\n\n| Metric | Value |\n|---|---|\n| MRR | $42k |\n| Churn | 1.2% |\n\n> Next review: July." Title MUST be specific. Response includes formattingQuality and formatSuggestion. Use dryRun: true for preview. (To READ a PDF, use read-doc.)

ParametersJSON Schema
NameRequiredDescriptionDefault
tocNoAdd a clickable Table of Contents (with heading anchors) at the top of the PDF.
tagsNoTags for registry search and discovery.
styleNoAdvanced: fine-grained style overrides merged on top of stylePreset.
titleYesSpecific descriptive title (rejected: 'Document', 'Untitled', etc.). Rendered as the top H1.
dryRunNoReturn a preview without writing the file (default: false).
footerNoPage footer: { text, alignment?, color? }. Use {current}/{total} placeholders for page numbers.
headerNoPage header: { text, alignment?: 'left'|'center'|'right', color?: '#hex' }. Applies to every page.
tablesNoOptional tables as 2D arrays. First row is the header. Rendered as styled tables after the body.
contentNoPREFERRED. The entire document body as ONE markdown string. Supported markdown: '# H1' '## H2' '### H3' headings; '**bold**'; '*italic*'; '`code`'; '- ' or '1. ' lists; '> ' blockquotes; '---' horizontal rule; ```fenced code blocks```; '| a | b |' GitHub tables (with a '|---|---|' separator row); '[text](https://url)' links. The title is added as the document H1 automatically, so start the body at '## '. EXAMPLE content: "## Overview\nThis report covers **Q2** results.\n\n### Highlights\n- Revenue up *18%*\n- Two new markets\n\n| Metric | Value |\n|---|---|\n| MRR | $42k |\n| Churn | 1.2% |\n\n> Next review: July." Use this instead of `paragraphs` unless you need per-paragraph style objects.
docTypeNoTone and depth of the documentation.
marginsNoPage margins in twips (1440 = 1 inch). Defaults: top/bottom 720 (or 1440 if header/footer set), left/right 1080.
categoryNoDocument category for subfolder organization.
uploadUrlNoOPTIONAL. HTTPS URL of a receiver that will accept a JSON envelope `{data:base64, filename, mimeType, size}` POSTed with this Bearer auth. If you have NOT been given an uploadUrl in your context, OMIT this field and the tool just writes the file locally. Single-use semantics — do not retry on 4xx. Works with any compliant receiver (CogniRunner attachment-upload web trigger is the reference implementation, but the contract is generic).
clientHintNoHow the response should be shaped. 'interactive' = polished one-line message for end-users (no chatty registry/lineage notes). 'agent' = verbose response with all metadata for AI consumption. 'auto' (default) = detect from input shape or MCP_CLIENT_TYPE env var, falling back to 'agent'.
outputPathNoOptional. Default: derived from title, placed under docs/<category>/.
paragraphsNoALTERNATIVE to `content`. Body as an array of markdown strings or { text, headingLevel } objects. Prefer the single `content` string.
descriptionNoBrief description stored in the registry.
stylePresetNoStyle preset. 'claude-like' (modern blue-accented professional) is the default for general-purpose docs. 'professional' is the executive serif look. Auto-selected from category if omitted.
uploadFilenameNoOPTIONAL. Filename to put in the upload envelope. Defaults to the local file's basename. Useful when the local file got auto-suffixed (e.g. duplicate prevention) and you want a clean name on the receiver side.
uploadAuthHeaderNoOPTIONAL. Authorization header value for uploadUrl (e.g. 'Bearer abc123'). REQUIRED when uploadUrl is set; ignored otherwise. Never logged.
enforceDocsFolderNoIf false, allow output outside docs/. Default: true (recommended).
preventDuplicatesNoIf false, allow same-title duplicates. Default: true (recommended).

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. Discloses key traits: uses headless Chromium, supports headers/footers with page numbers, margins, dryRun preview, and that response includes formattingQuality and formatSuggestion. Could mention error handling but is thorough overall.

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 long but well-structured: starts with purpose, then usage guidelines, then features, then markdown details, then example. Every sentence adds value; it is front-loaded with key information for agent decision-making. Slightly verbose but not wasteful.

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 22 parameters and no output schema, the description provides a comprehensive overview: main usage patterns, markdown syntax, an example, and output hints. It covers enough context for an agent to select and invoke the tool correctly without additional clarification.

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?

Input schema has 100% description coverage, so baseline 3. Description adds significant value: explains TOC as a 'superpower', recommends content over paragraphs, describes page number placeholders, and details the uploadUrl contract. This justifies a score above baseline.

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 it creates a FINAL, fixed-layout PDF for reading/printing/sending/signing. It explicitly distinguishes from create-doc (editable content) and create-markdown (code/repo docs).

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 when-to-use (e.g., 'PDF / print / send to the client / official / invoice') and when-not-to-use (e.g., 'NOT for content they'll keep editing' with named alternatives). Includes usage tips like putting body in content string and using TOC.

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

create-pptxA

Create an EDITABLE PowerPoint presentation (.pptx) you can open in PowerPoint / Keynote / Google Slides. USE when the user asks for slides / a deck / a presentation / a pitch deck / 'powerpoint' / 'keynote'. NOT for a flowing document (→ create-doc / create-pdf), code/repo docs (→ create-markdown), or pure tabular data (→ create-excel). SLIDE STRUCTURE: the title becomes a centered title slide; EACH '## ' heading starts a NEW slide whose body is the markdown beneath it. Inside a slide, '### ' is a sub-heading, '- '/'1. ' are bullets, '| a | b |' GitHub tables render as native slide tables, a chart fenced block (first line 'type: bar|column|line|pie|doughnut|area', optional 'title:', then a markdown table whose first column is the category and each other column is a data series) becomes a NATIVE editable chart, and fenced code blocks render as monospace. Keep each slide focused — a few bullets, not a wall of text. Styled from the same 8 presets as create-doc (colors/fonts map onto the slides). Supported markdown: '# H1' '## H2' '### H3' headings; 'bold'; 'italic'; 'code'; '- ' or '1. ' lists; '> ' blockquotes; '---' horizontal rule; fenced code blocks; '| a | b |' GitHub tables (with a '|---|---|' separator row); 'text' links. EXAMPLE content: "## Problem\n- Manual steps are slow\n- Errors slip through\n\n## Our Solution\n- One-click automation\n- Built-in checks\n\n## Results\n| Metric | Before | After |\n|---|---|---|\n| Time | 2h | 5m |". Title MUST be specific. Use dryRun: true to preview the slide breakdown. (To make a fixed, non-editable deck use create-pdf instead.)

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoTags for registry search and discovery.
styleNoAdvanced: fine-grained style overrides merged on top of stylePreset.
titleYesSpecific descriptive title (rejected: 'Document', 'Untitled', etc.). Becomes the title slide.
dryRunNoReturn a preview (title, slide count, section headings) without writing the file (default: false).
tablesNoOptional tables as 2D arrays. First row is the header. Rendered as native slide tables, appended after the body.
contentNoPREFERRED. The entire document body as ONE markdown string. Supported markdown: '# H1' '## H2' '### H3' headings; '**bold**'; '*italic*'; '`code`'; '- ' or '1. ' lists; '> ' blockquotes; '---' horizontal rule; ```fenced code blocks```; '| a | b |' GitHub tables (with a '|---|---|' separator row); '[text](https://url)' links. The title is added as the document H1 automatically, so start the body at '## '. EXAMPLE content: "## Overview\nThis report covers **Q2** results.\n\n### Highlights\n- Revenue up *18%*\n- Two new markets\n\n| Metric | Value |\n|---|---|\n| MRR | $42k |\n| Churn | 1.2% |\n\n> Next review: July." Use this instead of `paragraphs` unless you need per-paragraph style objects.
docTypeNoTone and depth of the documentation.
categoryNoDocument category for subfolder organization.
uploadUrlNoOPTIONAL. HTTPS URL of a receiver that will accept a JSON envelope `{data:base64, filename, mimeType, size}` POSTed with this Bearer auth. If you have NOT been given an uploadUrl in your context, OMIT this field and the tool just writes the file locally. Single-use semantics — do not retry on 4xx. Works with any compliant receiver (CogniRunner attachment-upload web trigger is the reference implementation, but the contract is generic).
clientHintNoHow the response should be shaped. 'interactive' = polished one-line message for end-users (no chatty registry/lineage notes). 'agent' = verbose response with all metadata for AI consumption. 'auto' (default) = detect from input shape or MCP_CLIENT_TYPE env var, falling back to 'agent'.
outputPathNoOptional. Default: derived from title, placed under docs/<category>/.
paragraphsNoALTERNATIVE to `content`. Body as an array of markdown strings or { text, headingLevel } objects. Prefer the single `content` string. Each '## ' heading starts a new slide.
descriptionNoBrief description stored in the registry; also used as the title-slide subtitle when the body has no preamble.
stylePresetNoStyle preset. 'claude-like' (modern blue-accented professional) is the default for general-purpose docs. 'professional' is the executive serif look. Auto-selected from category if omitted.
uploadFilenameNoOPTIONAL. Filename to put in the upload envelope. Defaults to the local file's basename. Useful when the local file got auto-suffixed (e.g. duplicate prevention) and you want a clean name on the receiver side.
uploadAuthHeaderNoOPTIONAL. Authorization header value for uploadUrl (e.g. 'Bearer abc123'). REQUIRED when uploadUrl is set; ignored otherwise. Never logged.
enforceDocsFolderNoIf false, allow output outside docs/. Default: true (recommended).
preventDuplicatesNoIf false, allow same-title duplicates. Default: true (recommended).

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description fully carries the burden. It details slide structure (title slide, ## for new slides), markdown support, native chart creation, style presets, and dry-run behavior. Does not mention rate limits or auth, but those are not critical for this tool. The description is transparent about what the tool produces and how it behaves.

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

Conciseness3/5

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

The description is comprehensive but somewhat lengthy. It front-loads the core purpose and usage, then details slide structure and markdown. Every sentence adds value, but some redundancy (markdown lists repeated) could be trimmed. It balances completeness with readability.

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 18 parameters and no output schema, the description covers key behavior: slide generation, markdown rendering, chart creation, styling, dry run. It lacks information on return format (but no output schema needed) and pagination. Sufficient for an agent to use the tool correctly.

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 description coverage is 100% (all 18 parameters have descriptions), so the baseline is 3. The description adds significant value beyond schema by explaining how headings map to slides, how to structure content, the chart syntax, and the relationship between content and paragraphs. This helps the agent use parameters effectively.

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 an editable .pptx presentation and distinguishes from siblings like create-doc, create-pdf, create-markdown, create-excel by specifying use cases (slides/decks) and output format.

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?

Explicitly says 'USE when the user asks for slides... NOT for flowing document...' and lists alternatives (create-doc/create-pdf/create-markdown/create-excel). Also mentions dryRun for preview, providing clear when-to-use and when-not guidance.

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

detect-formatA

PLAN the best output format BEFORE creating. Call this FIRST whenever the user didn't explicitly name a format. It weighs explicit format words, what the user wants to DO with the file, topic, and content shape — then returns a ready-to-use creation plan. Nuance it captures: 'README / API / spec / for the repo' → markdown; 'budget / tracker / dataset / table' → excel (CSV if they say csv); 'editable / draft / template / in Word' → docx; 'print / send to the client / official / invoice / resume / final / sign' → PDF. DOCX = editable Word; PDF = final, fixed-layout, print/sign/send. Returns { format (markdown|docx|excel|pdf), suggestedTool, stylePreset, category, docType, confidence, reason, alternativeFormat, outputFormat? ('csv'), unsupported? ('pptx'), note? }. Pass these straight into the create-* tool. There is no native slides/PowerPoint tool yet — it recommends the closest fit (usually PDF) and flags unsupported:'pptx'.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoDocument title if already chosen.
contentNoContent preview if available — the more context, the better the routing.
userQueryYesThe user's original request, verbatim if possible.

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It explains the analysis logic (weighs words, intent, topic) and return fields comprehensively. However, it omits details about error handling or edge cases (e.g., ambiguous input).

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?

Front-loaded with key instruction, then detailed examples. Every sentence adds value, though slightly verbose. Well-organized with logical flow from usage to return structure.

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 no output schema, the description fully explains all return fields and logic. Covers format detection rules, unsupported formats, and integration with creation tools. Complete for a planning 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% with good descriptions. The description adds minimal extra meaning beyond 'the more context, the better' for content. Does not significantly enhance parameter understanding beyond 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 tool's verb ('PLAN') and resource ('best output format'), with specific examples of format detection logic. It distinguishes itself from sibling creation tools by emphasizing it should be called FIRST to determine format.

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?

Explicitly says 'Call this FIRST whenever the user didn't explicitly name a format', providing clear when-to-use guidance. Also implies when-not-to-use (if format is named). Describes context-dependent format selection with examples.

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

dnaA

Manage the project's Document DNA — header/footer/style defaults that auto-apply to every create-doc call. Actions: 'init' (one-time setup with companyName/header/footer/stylePreset), 'get' (current config + project profile), 'evolve' (analyze usage trends; with apply:true, MUTATES dna config and may auto-create blueprints — irreversible without manual cleanup), 'save-memory'/'delete-memory' (project-wide preferences keyed by string).

ParametersJSON Schema
NameRequiredDescriptionDefault
keyNoMemory key (save-memory: optional, auto-generated; delete-memory: required).
applyNoevolve only: when true, AUTO-MUTATES the dna config based on top suggestion. Off by default — review suggestions first.
actionYesDNA action.
memoryNosave-memory only: a short preference statement (e.g. 'Always use 1-inch margins for contracts').
thresholdNoevolve only: minimum documents before suggesting a mutation (default 5).
footerTextNoDefault footer text (init only). Use {current}/{total} for page numbers.
headerTextNoDefault header text (init only).
companyNameNoCompany name (init only) — used as default header text.
stylePresetNoStyle preset. 'claude-like' (modern blue-accented professional) is the default for general-purpose docs. 'professional' is the executive serif look. Auto-selected from category if omitted.
footerAlignmentNoDefault footer alignment (init only).
headerAlignmentNoDefault header alignment (init only).

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description fully discloses key behaviors: 'evolve' with apply:true is irreversible, memory actions are project-wide, and DNA auto-applies to create-doc calls. No contradictions noted.

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 paragraph but well-organized by actions using semicolons. It is concise with no filler, though a bullet list could improve scannability. All sentences contribute 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?

Covers actions and warnings adequately for 11 params and no output schema. Missing details: init idempotency, return format for get/evolve. But remains largely complete for practical use.

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 useful context beyond schema: e.g., 'save-memory: optional, auto-generated' and 'evolve only: when true, AUTO-MUTATES'. This enhances understandability.

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 manages 'Document DNA' (header/footer/style defaults) and lists specific actions: init, get, evolve, save-memory, delete-memory. It differentiates from sibling tools like edit-pptx or create-doc by focusing on reusable defaults.

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?

Each action is explained with context: 'init' for one-time setup, 'evolve' for analyzing trends with a warning about apply:true being destructive. It does not explicitly list when not to use the tool, but the action-based structure provides clear guidance.

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

drift-monitorA

Monitor documents for structural drift over time. Actions: 'watch' (compute and store a fingerprint = SHA-256 + heading tree + word counts; capped at 500 paragraphs), 'check' (compare current state against the stored baseline; reports word-count delta, added/removed headings, category shifts, and a similarity score). Omit filePath on 'check' to compare all watched documents.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNoFriendly display name for the watched document (watch only).
actionYesDrift action.
filePathNoDocument path (REQUIRED for 'watch'; optional for 'check' — omit to check all watched docs).

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description effectively discloses key behavioral traits: the fingerprint components (SHA-256, heading tree, word counts), the 500-paragraph cap, and the reported metrics for 'check'. It omits some details like side effects or permissions, but overall provides sufficient transparency for the tool's actions.

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 highly concise—two sentences that front-load the purpose and enumerate actions with details. No wasted words; every sentence adds 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 (two actions, three parameters, no output schema), the description covers all key aspects: actions, parameters, output of 'check', and a constraint on 'watch'. It could elaborate on error handling or prerequisites, but it is largely complete for the agent to decide correct 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% with baseline 3, but the description adds significant meaning beyond raw schema: it specifies that 'name' is only for 'watch', explains 'filePath' requirement and optionality, and clarifies the action parameter's behavior. This enriches the schema information.

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 purpose: monitoring documents for structural drift. It defines two actions ('watch' and 'check') with specific details, distinguishing it from sibling tools which are centered on document creation/editing rather than analysis.

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 concrete guidance on when to use each action ('watch' for fingerprinting, 'check' for comparison) and notes optional behavior for 'filePath' on check. It implies a workflow (watch first, then check), but does not explicitly state when not to use the tool or direct users to alternatives.

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

edit-docA

Edit an existing DOCX. Actions: 'append' (XML-patches new content, PRESERVES original formatting/headers/footers/images), 'replace' (overwrites body but keeps section properties), 'style' (apply a stylePreset to existing paragraphs without changing text), 'preview' (show what would change). Always read-doc with mode 'indepth' first so you understand the existing structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoTags for registry search and discovery.
styleNoAdvanced fine-grained style overrides.
titleNoOptional new title (used by 'replace').
actionYesEdit action.
tablesNoTables as 2D arrays.
docTypeNoTone and depth of the documentation.
categoryNoDocument category for the registry update.
filePathYesAbsolute or project-relative path to the existing DOCX file.
useLegacyNoDANGER: when true, recreates the document via mammoth which DESTROYS all original formatting (fonts, colors, images, headers, footers). Only set this if XML patching fails. Default: false.
paragraphsNoParagraphs to append or replace with.
stylePresetNoStyle preset. 'claude-like' (modern blue-accented professional) is the default for general-purpose docs. 'professional' is the executive serif look. Auto-selected from category if omitted.
addSeparatorNoIf true (default for 'append'), insert a blank paragraph before the new content as a visual separator.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully carries the burden of disclosing behavior. It explains each action's effect: 'append' preserves formatting, 'replace' overwrites body but keeps section properties, 'style' applies preset without changing text, 'preview' shows changes. It also warns that useLegacy destroys original formatting when set to true.

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, front-loading the main purpose and actions, then providing usage guidance. Every sentence adds value; no redundant or extraneous text.

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 (12 parameters, nested objects, no output schema), the description covers the main actions and critical usage instruction. It doesn't explain return values or error handling, but the rules state output schema is not required. The description adequately prepares the agent for core 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 description coverage is 100%, so every parameter has a description. The description adds value by explaining the action parameter's effects and warning about useLegacy. However, it does not elaborate on all parameters beyond what the schema provides, but the baseline for high coverage is 3, and the additional context justifies a 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 clearly states the tool edits an existing DOCX file, listing specific actions (append, replace, style, preview) that each have distinct effects. It distinguishes from sibling tools like read-doc, create-doc, edit-pptx, etc., by specifying it modifies existing DOCX files.

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 a strong usage guideline: 'Always read-doc with mode indepth first so you understand the existing structure.' This tells the agent when to use a prerequisite sibling. However, it does not explicitly state when NOT to use this tool or compare with alternatives like create-doc for new documents.

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

edit-excelA

Edit an existing XLSX workbook. Actions: 'append-rows' (add rows to a sheet, preserves existing styles), 'append-sheet' (add a new sheet — fails if name exists), 'replace-sheet' (overwrite a sheet's data), 'preview' (show what would change). Use read-doc first if you don't know the sheet structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
rowsNoRows to append (required for append-rows).
tagsNoTags for registry search and discovery.
styleNoOptional style overrides (zebraColor, etc.).
actionYesEdit action.
docTypeNoTone and depth of the documentation.
categoryNoDocument category for registry update.
filePathYesAbsolute or project-relative path to the existing XLSX file.
sheetDataNoSheet definition (required for append-sheet and replace-sheet).
sheetNameNoTarget sheet name (required for append-rows and replace-sheet).
stylePresetNoStyle preset. 'claude-like' (modern blue-accented professional) is the default for general-purpose docs. 'professional' is the executive serif look. Auto-selected from category if omitted.

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are provided, so the description carries full responsibility. It discloses important behavioral traits: 'append-rows preserves existing styles,' 'append-sheet fails if name exists,' and 'preview shows what would change.' It also mentions style overrides and presets. This is substantial transparency for a mutation tool, though it lacks details on permission requirements or error handling.

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 extremely concise, under 100 words, and front-loads the core purpose. It uses a clear list format for actions, enclosing parenthetical details succinctly. Every sentence serves a purpose, and there is no redundancy or fluff.

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 10 parameters, no output schema, and no annotations, the description covers the essential operational context: actions, their effects, and a prerequisite hint. However, it does not explain the return value (e.g., success indicator or updated file info), nor does it mention error scenarios or validation of filePath format. It is sufficient for common use cases but could be more complete.

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 value beyond the schema by grouping actions and implicitly linking parameters (e.g., 'rows required for append-rows,' 'sheetData required for append-sheet and replace-sheet'). This context helps the agent understand parameter dependencies, which the schema alone does not fully convey.

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 'Edit an existing XLSX workbook' and lists four specific actions (append-rows, append-sheet, replace-sheet, preview). This goes beyond a simple verb+resource, providing a concrete scope. However, it does not explicitly distinguish itself from sibling edit tools (like edit-pptx) or the create-excel tool, though the context of editing existing XLSX files is implied.

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 explicitly instructs to 'Use read-doc first if you don't know the sheet structure,' which is clear contextual guidance. It also lists the available actions, hinting at when to use each. However, it does not provide explicit when-not-to-use scenarios (e.g., when to use create-excel instead) or mention prerequisites like file existence.

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

edit-pptxA

Edit an existing PowerPoint (.pptx). Actions: 'preview' (show the current slide outline), 'append-slides' (add new slides from markdown — one '## ' heading per slide), 'replace-slide' (replace one content slide by 1-based index with new markdown). IMPORTANT: edit-pptx REBUILDS the deck from the existing slides' extracted TEXT + speaker notes, normalized to a style preset — charts, images, and exact original formatting on pre-existing slides are NOT preserved (best for the text/bullet decks create-pptx makes). To author a brand-new deck use create-pptx; to read a deck use read-doc.

ParametersJSON Schema
NameRequiredDescriptionDefault
styleNoAdvanced style overrides merged on top of stylePreset.
titleNoOptional heading to use when replace-slide content has no leading '## '.
actionYesEdit action.
contentNoNew slide markdown ('## ' per slide). Required for append-slides and replace-slide.
filePathYesPath to the existing .pptx file.
uploadUrlNoOPTIONAL. HTTPS URL of a receiver that will accept a JSON envelope `{data:base64, filename, mimeType, size}` POSTed with this Bearer auth. If you have NOT been given an uploadUrl in your context, OMIT this field and the tool just writes the file locally. Single-use semantics — do not retry on 4xx. Works with any compliant receiver (CogniRunner attachment-upload web trigger is the reference implementation, but the contract is generic).
clientHintNoHow the response should be shaped. 'interactive' = polished one-line message for end-users (no chatty registry/lineage notes). 'agent' = verbose response with all metadata for AI consumption. 'auto' (default) = detect from input shape or MCP_CLIENT_TYPE env var, falling back to 'agent'.
outputPathNoOptional. Write the result here instead of overwriting the input file.
slideIndexNo1-based index among CONTENT slides (the title slide is excluded). Required for replace-slide.
stylePresetNoStyle preset. 'claude-like' (modern blue-accented professional) is the default for general-purpose docs. 'professional' is the executive serif look. Auto-selected from category if omitted.
uploadFilenameNoOPTIONAL. Filename to put in the upload envelope. Defaults to the local file's basename. Useful when the local file got auto-suffixed (e.g. duplicate prevention) and you want a clean name on the receiver side.
uploadAuthHeaderNoOPTIONAL. Authorization header value for uploadUrl (e.g. 'Bearer abc123'). REQUIRED when uploadUrl is set; ignored otherwise. Never logged.

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses critical behavioral traits: the tool REBUILDS the deck, extracts text and speaker notes, normalizes to a style preset, and does NOT preserve charts, images, or exact original formatting. This level of transparency is exemplary for a mutation tool.

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 efficiently structured: purpose first, then actions, then critical behavioral caveat (IMPORTANT), then sibling guidance. Every sentence provides necessary context without redundancy. It is appropriately sized for the tool's complexity.

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 tool's complexity (12 parameters, 3 actions, significant side effects), the description covers purpose, actions, behavioral implications, and tool selection guidance comprehensively. No output schema exists, but the description sufficiently explains what each action produces (preview shows outline, append/replace modifies file).

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 description coverage is 100%, so the schema already documents all parameters. The description adds action-specific context (e.g., 'one '## ' heading per slide' for content, '1-based index among CONTENT slides' for slideIndex) and explains the uploadUrl workflow. While the schema is clear, the description enhances understanding of how parameters interact with actions.

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 'Edit an existing PowerPoint (.pptx)' and enumerates three specific actions ('preview', 'append-slides', 'replace-slide'), clearly stating the tool's purpose. It distinguishes itself from siblings by explicitly naming create-pptx and read-doc, ensuring the agent understands the tool's scope.

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 when-to-use and when-not-to-use guidance: 'To author a brand-new deck use create-pptx; to read a deck use read-doc.' It also notes that the tool is best for text/bullet decks from create-pptx and warns about loss of charts/images, giving clear context for appropriate usage.

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

fact-checkA

Fact-check a document (or explicit claims) against the LIVE WEB. CROSS-MCP tool: doc-processor extracts the claims, then CALLS the web-search MCP (get-web-search-summaries) to gather sources per claim, and optionally writes a cited PDF report. Provide claims (an array of statements) OR a filePath/content to auto-extract factual claims from. Because this reaches the web-search MCP you MUST pass webSearchBearer (your web-search demo key) and serperKey (your Serper key); webSearchUrl defaults to the hosted web-search endpoint. Returns, per claim, the retrieved evidence + source URLs + a ROUGH keyword-overlap support score — NOT a verdict; read the evidence and decide support/refute yourself. Set generateReport: true for a downloadable cited PDF.

ParametersJSON Schema
NameRequiredDescriptionDefault
claimsNoExplicit statements to verify. If omitted, claims are auto-extracted from filePath/content.
contentNoRaw text to extract claims from. Use this OR claims OR filePath.
filePathNoA document (PDF/DOCX/Excel/PPTX) to read and extract claims from. Use this OR claims OR content.
maxClaimsNoMax claims to check (default 8, max 20).
serperKeyNoREQUIRED. Your Serper key — the web-search MCP is keyless and needs it to search.
uploadUrlNoOPTIONAL. HTTPS URL of a receiver that will accept a JSON envelope `{data:base64, filename, mimeType, size}` POSTed with this Bearer auth. If you have NOT been given an uploadUrl in your context, OMIT this field and the tool just writes the file locally. Single-use semantics — do not retry on 4xx. Works with any compliant receiver (CogniRunner attachment-upload web trigger is the reference implementation, but the contract is generic).
clientHintNoHow the response should be shaped. 'interactive' = polished one-line message for end-users (no chatty registry/lineage notes). 'agent' = verbose response with all metadata for AI consumption. 'auto' (default) = detect from input shape or MCP_CLIENT_TYPE env var, falling back to 'agent'.
reportTitleNoOptional title for the generated report.
webSearchUrlNoOptional. The web-search MCP /mcp URL. Defaults to the hosted endpoint (or the WEB_SEARCH_MCP_URL env var).
generateReportNoIf true, also write a cited PDF verification report (returned as a download link).
uploadFilenameNoOPTIONAL. Filename to put in the upload envelope. Defaults to the local file's basename. Useful when the local file got auto-suffixed (e.g. duplicate prevention) and you want a clean name on the receiver side.
webSearchBearerNoREQUIRED. A web-search MCP tenant bearer (your web-search demo key) — this tool calls that MCP.
uploadAuthHeaderNoOPTIONAL. Authorization header value for uploadUrl (e.g. 'Bearer abc123'). REQUIRED when uploadUrl is set; ignored otherwise. Never logged.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It explains the cross-MCP workflow, the need for API keys, the output structure (evidence, source URLs, keyword-overlap score), and the optional PDF report. It doesn't detail error handling or rate limits but covers essential behavioral aspects.

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

Conciseness3/5

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

The description is relatively long but well-structured, starting with the purpose and then detailing usage. Some sentences contain excessive details that could be streamlined, and the inclusion of both a summary and separated parameter descriptions makes it slightly verbose.

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 (13 parameters, no output schema, no annotations), the description covers the main input mechanisms, dependencies, output format, and optional report generation. It lacks details on error states and limitations but is sufficient for an agent to use the tool correctly.

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?

Although the schema already describes all 13 parameters (100% coverage), the description adds significant context: it explains the relationship between claims, filePath, and content, highlights required keys despite the schema listing them as optional, and clarifies the uploadUrl mechanics. This goes 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 tool's purpose: to fact-check a document or explicit claims against the live web. It uses specific verbs and resources and distinguishes from siblings as no other sibling tool offers fact-checking functionality.

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 clear guidance on when to use the tool, including the alternative input methods (claims array or filePath/content) and the requirement for external keys. However, it does not explicitly state when not to use it or compare with specific sibling tools.

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

get-lineageA

Trace the provenance chain of a document. Returns a tree { sources: [{filePath, ...}], derivatives: [{filePath, ...}] } showing which read documents informed this document (sources, traced upstream) and which created documents derived from it (derivatives, traced downstream). Lineage is recorded automatically when read-doc and create-doc are called within the same session.

ParametersJSON Schema
NameRequiredDescriptionDefault
depthNoTraversal depth in either direction (default: 3).
filePathYesDocument path to trace lineage for.

TDQS

A3.8/5.0
Behavior4/5

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

No annotations provided; description compensates by disclosing lineage recording behavior (automatically tracked when read-doc/create-doc called in same session). Does not cover auth, rate limits, or error scenarios.

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?

Two sentences plus output structure explanation; concise and front-loaded with purpose. Could be slightly more structured but 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?

Provides output format and condition for lineage existence, but missing error behavior, response details beyond tree structure, and explicit read-only nature.

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 covers both parameters with descriptions; description adds default value for depth (3), which is useful context. No additional meaning for filePath.

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 traces the provenance chain, specifies output structure (sources, derivatives), and differentiates from siblings like read-doc and create-doc.

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?

Implied usage for understanding document relationships, but no explicit when-to-use or alternatives against siblings like read-doc.

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

list-documentsA

Search the document registry. Filters compose with AND-logic: category match AND tag match AND title-substring match. Returns an array of registry entries with { id, title, filePath, category, tags, description, createdAt, updatedAt }. Use this before create-doc to check if a similar document exists.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoFilter by tags (matches if ANY tag overlaps).
titleNoSubstring match on title (case-insensitive).
categoryNoFilter by exact category match.

TDQS

A4.2/5.0
Behavior3/5

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

Discloses AND-logic for filters and return format, but lacks details on pagination, error handling, or performance implications. Without annotations, the description is adequate but not exhaustive.

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?

Two sentences, no wasted words, front-loaded with purpose and filter logic, then return format and usage hint. Exceptionally concise.

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, filters, return structure, and a usage hint. Lacks mention of pagination or sorting, but for a simple search tool with no output schema, it is fairly complete.

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?

Adds value beyond schema by explaining how filters combine (AND-logic) and clarifying case-insensitive substring matching for title, while schema already covers individual parameter descriptions.

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 searches the document registry and explicitly distinguishes from create-doc by suggesting its use before creation to avoid duplicates.

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 clear guidance to use before create-doc to check for similar documents, but does not explicitly state when not to use it or mention alternatives among siblings.

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

list-templatesA

List available document templates AND blueprints. Templates are static, named structures (e.g. 'claude-like', 'technical-docs', 'business-report') you can reference via tags on create-doc. Blueprints are auto-learned structures stored in .document-blueprints.json. Use the returned name as blueprint: in create-doc, or as a tag for create-doc tag-based style detection.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoOptional category filter (matches blueprints' learnedFrom category and templates' recommendedFor).

TDQS

A4.2/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 full burden. It adds behavioral context by defining templates and blueprints, but lacks disclosure on read-only nature, authentication needs, or side effects. Adequate but not comprehensive.

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?

Two sentences, no filler. First sentence states purpose, second provides usage context with clear examples. Every sentence earns its place.

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 no output schema and no annotations, the description explains the two result types and their application in create-doc. It could mention if the list is all available or filtered, but overall fairly complete for a list tool.

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 description coverage is 100% for the single parameter. The description adds value by linking the category filter to 'learnedFrom' and 'recommendedFor', enhancing 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?

Description clearly states the tool lists both document templates and blueprints, distinguishing between the two types. It also explains how the returned `name` is used with create-doc, providing specific verb and resource identification.

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 explicitly tells when to use the tool (to get names for referencing in create-doc) and what to do with the results. It does not explicitly state when not to use it, but the context is clear among siblings.

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

read-docA

Read and analyze PDF, DOCX, Excel, or PowerPoint (.pptx) files. Modes: 'summary' (overview with preview), 'indepth' (full text, structure, metadata), 'focused' (query-based search). For a .pptx it returns a per-slide transcript (titles, bullets, speaker notes) and the slide count. Source: either local filePath OR a remote https url whose response is {data:base64, filename, mimeType, size} JSON guarded by authHeader (used for one-shot capabilities like CogniRunner attachment fetches). Always read before editing; use 'indepth' before edit-doc.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoHTTPS URL whose response is {data:base64, filename, mimeType, size} JSON. Use this OR filePath.
modeNoRead mode (default: summary)
contextNoContext from previous questions. Only used with mode 'focused'.
filePathNoLocal file path. Use this OR url+authHeader.
filenameNoOptional filename hint used for the temp-file extension when the response omits one.
userQueryNoQuery for focused analysis. Only used with mode 'focused'.
authHeaderNoAuthorization header value (e.g. 'Bearer abc123'). Required when url is set.

TDQS

A4.4/5.0
Behavior4/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 discloses modes, pptx output format, source requirements (authHeader for URL), and suggests using indepth before editing. It does not mention side effects, but as a read tool, none are expected.

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 dense paragraph that front-loads the main purpose, then details modes, pptx behavior, sources, and usage advice. It is concise but could benefit from slight structuring (e.g., bullets) for clarity. Still, every sentence earns its place.

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 7 parameters and no output schema, the description adequately covers modes, sources, and usage hints. It does not describe return values, but that is acceptable given no output schema. The advice 'read before editing' adds useful context for workflow.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant context beyond schema: it explains modes (summary, indepth, focused) with examples, describes the remote source structure, clarifies that context and userQuery are only for focused mode, and notes that url requires authHeader. This is high 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 it reads and analyzes PDF, DOCX, Excel, or PowerPoint files, lists three modes, specifies behavior for pptx, and mentions two source types. It also differentiates from sibling edit-doc by advising to use 'indepth' before editing.

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 clear context for when to use each mode and hints at alternatives (use 'indepth' before edit-doc). It does not explicitly exclude other siblings, but the sibling list is dominated by creation tools, making this tool's purpose distinct.

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

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

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: creation tools are separated by format, editing tools by format, and management tools (dna, blueprint, drift-monitor, get-lineage, fact-check) are unique. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent lowercase-hyphenated verb-noun pattern (e.g., create-doc, edit-excel, list-templates). Even single-word tools like 'dna' and 'blueprint' fit the pattern as action-oriented names.

Tool Count5/5

17 tools cover reading, creating, editing, and managing documents across common formats (DOCX, XLSX, PPTX, PDF, Markdown) plus auxiliary features (detection, templates, lineage, fact-checking). No tool feels extraneous, and the scope is well-balanced.

Completeness4/5

Core CRUD operations are covered for most formats, but there is no tool for editing Markdown files (only create-markdown) and no deletion capability. Minor gaps, but the surface handles document lifecycle well overall.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

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/leanzero-srl/leanzero-mcp-doc-processor'

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