What can you do with this server?

Use inclusio-mcp to drive the Inclusio accessibility-first publishing engine from MCP clients for document discovery, rendering, and PDF accessibility auditing. * list_docs — enumerate registered documents and metadata from data/meta.yaml. * doc_count — quickly count registered documents as a lightweight connectivity/health probe. * render — materialize a registered document into LaTeX, Markdown, JSON, or text source under build/.cache/rendered/ using draft, submission, or camera-ready mode. * audit_pdf — run veraPDF accessibility audits over built PDFs for PDF/UA-2, WTPDF, and PDF/A-4f conformance, optionally surfacing blocking failures in strict mode. * Read resources — inclusio://meta, inclusio://audit/latest, and inclusio://version. * Integrate with Claude Code, Cursor, Continue, or other MCP clients for agent-driven publishing workflows.

Which integrations are available for this server?

Enables LLM-augmented judges for ATS scoring and citation grounding using OpenAI's API.

inclusio-mcp

by sebastienrousseau

Overview Schema Source Related Servers Discussions Admin

Python

Local

Install — pip, optional extras, source
Quick Start — first tagged PDF in 60 seconds
Features — what the engine ships
Usage — common Python + CLI recipes
Tools — the MCP tool and resource surface
Architecture — the engine's package layout
Examples — six runnable scenarios
Documentation — quickstart, tutorials, reference
Publishing against an external content tree
Development — local validation gate
Security — signed commits, provenance, audit
License

Related MCP server: FastMCP LaTeX Server (tex-mcp)

Install

pip install inclusio                       # engine + CLI
pip install 'inclusio[mcp]'                # + FastMCP server
pip install 'inclusio[provenance]'         # + pyhanko (PAdES)
pip install 'inclusio[dev]'                # + pytest, ruff, sphinx, interrogate

Requires Python ≥ 3.11 and a LuaLaTeX toolchain on PATH. Linux, macOS, and WSL are supported (native Windows works for the Python surface; the LaTeX gate needs WSL or a TeX Live install).

Optional tool	Adds	Install
`verapdf`	The strict EAA / accessibility audit gate	verapdf.org/install
`pandoc` (≥ 3.0)	HTML5 / JATS XML / EPUB3 multi-format emission	`brew install pandoc` · `apt install pandoc`
`c2patool`	C2PA Content Credentials	contentauth/c2patool releases
`pyhanko` (via `[provenance]`)	PAdES B-T / B-LT / B-LTA signing	Pulled by the extra

Build from source

git clone https://github.com/sebastienrousseau/inclusio.git
cd inclusio
./bin/setup        # check toolchain + install dev extras
make test          # smoke suite
make coverage      # full suite (gate: 97 %)

Quick Start

A complete worked example you can paste into a fresh directory:

pip install inclusio

# Grab the minimal example, build + audit + emit + judge:
git clone --depth=1 https://github.com/sebastienrousseau/inclusio
cd inclusio/examples/01-hello-world && make

That single make produces build/hello.pdf (PDF/UA-2 + WTPDF + PDF/A-4f triple-conformance), runs veraPDF over it, and exits non-zero if any flavour fails.

Drive the same surface from Python:

# quickstart.py
import subprocess
from pathlib import Path

# 1. Render + build the bundled "hello" fixture — the CLI is the
#    canonical entry point for the LaTeX step.
subprocess.run(
    ["python", "-m", "inclusio.cli.build", "build", "--doc", "hello"],
    cwd="examples/01-hello-world",
    check=True,
)

# 2. Audit the produced PDF in-process — pure-Python, no subprocess.
from inclusio.cli import audit

pdfs = audit.collect_pdfs(
    target=Path("examples/01-hello-world/build"),
    build_dir=Path("examples/01-hello-world/build"),
    registry_stems={"hello"},
)
report = audit.audit(pdfs)
assert report["summary"]["fail"] == 0, "veraPDF reported a failure"
print(f'  PASS  {report["summary"]["pdfs"]} PDF(s), '
      f'{report["summary"]["pass"]}/{report["summary"]["total"]} checks')
# →   PASS  1 PDF(s), 3/3 checks

Features

Tagged PDF, by default. Every build emits a PDF/UA-2 + WTPDF + PDF/A-4f triple-conforming artefact via the LaTeX kernel's tagpdf integration. The veraPDF audit gate is wired into CI and exits non-zero on any FAIL.
Multi-format emission. The same LaTeX source produces HTML5 (WCAG-clean), JATS XML (1.3, JATS4R-ready), and EPUB3 via Pandoc.
LLM-augmented judges. ATS (Workday / Greenhouse / Lever heuristic), citation grounding, and JD-to-CV fit — local llama.cpp or BYO-key cloud (Anthropic / OpenAI), with heuristic-only fallback when the LLM is unreachable.
Content provenance. C2PA Content Credentials (via c2patool), PAdES B-T / B-LT / B-LTA signatures (via pyhanko), and SLSA L3 build attestation (via actions/attest-build-provenance).
MCP server. inclusio-mcp exposes list_docs, audit_pdf, render, and doc_count so Claude Code, Cursor, Continue, or any other MCP client can drive the engine.
JSON Resume importer. inclusio import-resume converts a jsonresume.org v1 document into the engine's CV YAML schema.
Brief-driven CV tailoring. ATS-clean variants tailored against a job description with British-English cleanup and consistency lint.

Usage

Build, audit, judge a registered document

inclusio build --doc cv --mode draft        # → build/cv.pdf
inclusio audit --strict                     # → veraPDF, non-zero on FAIL
inclusio judge --doc cv --judge ats         # → grade + findings

Score a CV against a job description

# score_cv.py — fully runnable: drop into a directory with brief.txt + cv.txt
from pathlib import Path
from inclusio.judge import jd_fit

jd_text = Path("brief.txt").read_text(encoding="utf-8")
cv_text = Path("cv.txt").read_text(encoding="utf-8")

report = jd_fit.score_jd_fit(jd_text, cv_text)
print(f"score:   {report.score}/100   grade: {report.grade}")
print(f"missing: {sorted(report.metrics['missing_required'])[:5]}")
# → score:   78/100   grade: B
# → missing: ['opentelemetry', 'rust']

Drive the engine over MCP

inclusio-mcp                          # stdio (Claude Code default)
inclusio-mcp --http --port 8765       # Streamable HTTP

Wire into Claude Code via ~/.claude/claude_desktop_config.json:

{
  "mcpServers": {
    "inclusio": {
      "command": "inclusio-mcp",
      "env": { "INCLUSIO_CONTENT_DIR": "/absolute/path/to/content" }
    }
  }
}

Embed C2PA Content Credentials

inclusio provenance --doc cv \
  --cert /path/to/cert.pem \
  --key  /path/to/key.pem \
  --output build/cv.c2pa.pdf

Tools

The inclusio-mcp server exposes four MCP tools:

list_docs — Enumerate documents registered in the content tree
doc_count — Quick count of available documents
render — Build a tagged, conformant PDF (and other formats) for a document
audit_pdf — Accessibility audit of a PDF (veraPDF)

Plus three read-only resources:

inclusio://meta — Project manifest (meta.yaml)
inclusio://audit/latest — Latest audit report
inclusio://version — Engine version card

Architecture

inclusio/                  # Python package
  cli/                     # build · audit · render · tailor · judge · emit · provenance · …
  judge/                   # ats · citations · jd_fit · local_llm · cloud_llm
  emit/                    # pandoc (HTML5 / JATS XML / EPUB3)
  provenance/              # c2pa (c2patool) · pades (pyhanko)
  mcp/                     # FastMCP server
  tools/                   # fix_semantic · stamp_pdfs · overlay
core/                      # LaTeX classes (.cls) and styles (.sty)
templates/                 # Jinja2 templates for the template-driven docs
benches/                   # pytest-benchmark micro-benchmarks
examples/                  # Six self-contained runnable scenarios
docs/                      # Sphinx documentation

External consumers supply their own content tree (LaTeX sources, YAML metadata, brand assets) and point the engine at it through INCLUSIO_CONTENT_DIR or --content-dir. The repo's own src/ and data/ directories double as the public-engine self-test fixtures.

Examples

#	Folder	What it teaches
1	`01-hello-world/`	Tagged-PDF build with the audit gate
2	`02-cv-from-jsonresume/`	JSON Resume → CV → ATS + JD-fit scoring
3	`03-paper-with-citations/`	Paper → PDF + HTML + JATS + EPUB + citation judge
4	`04-mcp-agent/`	`inclusio-mcp` + Claude Code skill
5	`05-c2pa-sign/`	C2PA Content Credentials
6	`06-pades-sign/`	PAdES B-T eIDAS signature

Each folder has its own Makefile (make help lists targets) and a README.md with the why + the how.

Documentation

Quickstart — five-minute walkthrough.
Tutorials — four end-to-end walkthroughs paired 1 : 1 with the examples.
Architecture — public-engine vs content-repo boundary, sprint history, decision log.
Tagged PDF — the conformance stack.
Multi-format — HTML / JATS / EPUB.
Judges — ATS, citations, JD-fit, LLM rerank contract.
Provenance — C2PA, PAdES, SLSA.
MCP server — tool + resource surface.

Publishing against an external content tree

make publish CONTENT_DIR=/absolute/path/to/your-content-repo

The content repo supplies its own data/meta.yaml (document registry) and src/**.tex (LaTeX sources). The engine reads no state from outside INCLUSIO_CONTENT_DIR once it's set.

Development

make test          # smoke (≤ 20 s)
make coverage      # full suite + 97 % gate (~3 min)
make docstrings    # 100 % interrogate gate
make benchmark     # pytest-benchmark micro-budgets
make audit-strict  # veraPDF, exits non-zero on any FAIL
make docs          # Sphinx

All commits to main are squash-merged via PR. Branch protection requires Lint (ruff) + Public Engine Checks (py3.11 / 3.12 / 3.13) + the Signed-commit gate to pass. See CONTRIBUTING.md.

Security

SSH-signed commits. Every commit on main is GitHub-verified.
Signed tags. Release tags are ED25519-signed.
SLSA L3 build provenance (gated on the repo being public or on a paid GitHub plan).
PyPI Trusted Publishing wiring (pypa/gh-action-pypi-publish) in release.yml; flip vars.PYPI_TRUSTED_PUBLISHING=true once the PyPI publisher is configured.
Cloud LLM keys are env-var only — inclusio never auto- discovers credentials from disk.

Report vulnerabilities per SECURITY.md.

Sibling MCP servers by the same author — each targets a different agent workflow:

Server	Purpose
`noyalib-mcp`	Lossless YAML 1.2 parsing, formatting & validation (Rust)
`rlg-mcp`	RustLogs log streams for on-call / SRE agent workflows
`pain001-mcp`	Generate & validate ISO 20022 pain.001 payment initiation files
`bankstatementparser-mcp`	Parse bank statements (BAI2, MT940/MT942, CAMT.053, OFX, CSV)
`camt053-mcp`	Parse & reconcile ISO 20022 camt.053 bank-to-customer statements
`acmt001-mcp`	Generate & validate ISO 20022 acmt.001 account management messages

MCP Registry

mcp-name: io.github.sebastienrousseau/inclusio-mcp

Install the MCP server with pip install 'inclusio[mcp]' (the mcp extra pulls in mcp[cli]>=1.27.0). Run with inclusio-mcp — stdio transport, exposes accessibility-publishing tools to Claude Desktop, Cursor, and other MCP clients.

License

Licensed under either of:

Available Tools

4 tools

audit_pdfAudit PDF accessibility (veraPDF)A

Read-onlyIdempotent

Audit built PDFs for accessibility conformance with veraPDF.

    Purpose:
    Verifies whether built PDFs satisfy PDF/UA-2, WTPDF, and PDF/A-4f triple-conformance
    accessibility and preservation standards using veraPDF.

    When to use:
    - When validating accessibility compliance of compiled PDF documents prior to publication.
    - When auditing batch PDFs under `build/` for regulatory standards (EAA, WCAG 2.2 AA).

    When NOT to use:
    - Do NOT use to generate or compile documents; use `render` and the build pipeline first.
    - Do NOT use if veraPDF is not installed or available on PATH.

    Behavioral transparency:
    Read-only audit. Shells out to veraPDF without modifying any PDF or source files.

    Returns:
    Audit report dictionary detailing summary, per-PDF results, and per-flavour passes/fails.

ParametersJSON Schema

Name	Required	Description	Default
`strict`	No	When true, every blocking-flavour FAIL is surfaced as `blocking_failure: true` in the response.
`target`	No	PDF file path or directory to audit; defaults to `build/` under INCLUSIO_CONTENT_DIR.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: it shells out to veraPDF, modifies no PDF or source files, and fails without veraPDF installed. It does not cover rate/cost or failure semantics of a missing binary.

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 one-line summary followed by clearly labelled sections; every block (purpose, when/when-not, behavior, returns) earns its place. The labelled formatting is slightly heavier than needed 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?

For a two-parameter, fully-annotated tool with an output schema, the description covers purpose, routing, prerequisite, and side-effect profile. The 'Returns' block is supplementary since an output schema exists, and nothing an agent needs to invoke it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so both `strict` and `target` are already documented in the schema; the baseline is 3. The description only echoes the default `build/` directory via the batch-audit example and adds no syntax or format detail 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?

States a specific verb (audit) and resource (built PDFs) plus the exact standards verified (PDF/UA-2, WTPDF, PDF/A-4f) and the engine (veraPDF). It is clearly distinguishable from siblings like render, which compiles documents rather than auditing them.

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' and 'When NOT to use' sections, names the alternative tool (`render` plus the build pipeline) and states a real prerequisite (veraPDF on PATH). Nothing about tool selection is left to inference.

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

doc_countCount registered documentsA

Read-onlyIdempotent

Count the documents registered in data/meta.yaml.

    Purpose:
    Fast, lightweight health and connectivity probe that counts registered documents in the manifest.

    When to use:
    - When verifying server availability and project manifest readability with minimal payload size.
    - When performing initial connectivity checks before deeper inspection.

    When NOT to use:
    - Do NOT use when full metadata (doc_id, class, title) is needed; use `list_docs` instead.

    Behavioral transparency:
    Read-only, instantaneous manifest header check.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered structurally. The description adds genuinely useful behavioral context beyond them: it is 'fast, lightweight', has 'minimal payload size', and is an 'instantaneous manifest header check', which tells the agent about cost and scope. It stops short of describing the return shape, but the output schema covers that.

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 a one-line summary, then cleanly sectioned into Purpose, When to use, When NOT to use, and Behavioral transparency. The section headers make it scannable, though the Purpose section partially restates the opening sentence, adding mild redundancy.

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 a zero-parameter, read-only probe with an output schema and rich annotations, the description covers everything an agent needs: what it counts, its cost profile, when to prefer it, and which sibling to use instead. Return values are correctly left to the output schema.

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?

The tool takes zero parameters, which is the baseline-4 case; there is no parameter semantics to document. The description correctly implies the tool requires no input by describing a manifest header read.

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?

Starts with a specific verb+resource ('Count the documents registered in data/meta.yaml') and frames the tool as a health/connectivity probe. It explicitly distinguishes itself from the sibling `list_docs`, so an agent can choose between them without opening either schema.

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' (availability checks, initial connectivity probes) and 'When NOT to use' (full metadata needed → use `list_docs`), naming the alternative tool directly. This is the strongest possible routing guidance.

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

list_docsList registered documentsA

Read-onlyIdempotent

List every document registered in data/meta.yaml with its metadata.

    Purpose:
    Enumerates all registered documents, returning their identifiers, classes, source paths,
    titles, and PDF/A flags.

    When to use:
    - When discovering valid `doc_id` values before calling `render` or `audit_pdf`.
    - When checking document classes (e.g. CV, paper, report, letter) registered in the workspace.

    When NOT to use:
    - Do NOT use if you only need a quick connectivity probe; use `doc_count` instead.
    - Do NOT use for raw YAML content; use the `inclusio://meta` resource instead.

    Behavioral transparency:
    Pure, read-only filesystem inspection. Reads `data/meta.yaml` without mutating any state.

    Returns:
    List of document specification dictionaries. Empty list when no manifest exists.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint. The description reinforces the read-only filesystem nature and adds a genuinely non-obvious behavior: an empty list is returned when no manifest exists. This adds value beyond the annotations, though the openWorld implication is not elaborated.

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?

Well-structured with labeled sections (Purpose, When to use, When NOT to use, Behavioral transparency, Returns), but the labeled-header format is more verbose than strictly necessary; the content itself is front-loaded and 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?

An output schema exists, so the description need not explain return shape, yet it helpfully summarizes the returned fields and the empty-manifest edge case. Comprehensive for a zero-parameter read tool; minor gap is that the openWorldHint implication (external path dependencies) is not addressed.

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?

Zero parameters, so baseline is 4. The description correctly documents the output field set, which is relevant since this call has no inputs.

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?

States a specific verb (lists every document) and resource (registered in data/meta.yaml), then enumerates exactly what is returned (identifiers, classes, source paths, titles, PDF/A flags). It clearly distinguishes itself from doc_count, render, and audit_pdf.

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' with two concrete triggering scenarios (discovering doc_id before render/audit_pdf; checking registered classes) and 'When NOT to use' naming two alternatives (doc_count for a probe; the inclusio://meta resource for raw YAML). Nothing is left to inference.

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

renderRender document to a fileA

Idempotent

Render a registered template-driven document to a file on disk.

    Purpose:
    Materializes document templates into concrete source files (LaTeX, Markdown, JSON, text)
    under `build/.cache/rendered/` applying the specified build mode.

    When to use:
    - When generating LaTeX source for PDF compilation and accessibility tagging.
    - When generating Markdown or text representations for review or downstream processing.

    When NOT to use:
    - Do NOT use without discovering valid `doc_id` values first using `list_docs`.
    - Do NOT use to compile PDFs directly; this tool produces rendered sources for compilation.

    Behavioral transparency:
    Non-destructive, idempotent cache writer. Regenerates files under `build/.cache/rendered/`
    without modifying template sources or `data/meta.yaml`.

    Returns:
    Dictionary containing doc_id, format, build mode, output_path, and byte size.

ParametersJSON Schema

Name	Required	Description	Default
`fmt`	No	Output format the document is rendered to. Must be exactly one of: 'json', 'latex', 'markdown', 'text' (see `render`'s docstring / `list_docs`).	latex
`mode`	No	Build mode / profile applied when rendering. Must be exactly one of: 'camera-ready', 'draft', 'submission'.	draft
`doc_id`	Yes	Registered template document id — see `list_docs`.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare idempotentHint, destructiveHint=false, and readOnlyHint=false; the description goes further by pinpointing the write target ('build/.cache/rendered/') and asserting template sources and data/meta.yaml are untouched. It adds real context beyond the annotations, though it restates the idempotency/non-destructiveness already encoded.

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?

Labelled sections make it easy to scan and the core action is front-loaded in the first sentence. It is somewhat long and the 'Returns' block is arguably redundant given the output schema, but no sentence is pure filler.

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?

For a 3-param write tool with an output schema already defined, the description covers purpose, prerequisites (discover doc_id via list_docs), exclusions, and side effects (cache-only writes). Nothing essential is missing, though the return-value section duplicates the output schema.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters (fmt, mode, doc_id) are already documented with enums and defaults in the schema. The description repeats the formats and mentions 'specified build mode' but adds no new syntax or constraint beyond the structured fields, matching the baseline of 3.

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?

States a specific verb and resource ('Render a registered template-driven document to a file on disk') and names the concrete outputs (LaTeX, Markdown, JSON, text) plus the destination directory. It is clearly distinguishable from siblings like list_docs, audit_pdf, and doc_count.

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?

Explicit 'When to use' and 'When NOT to use' sections name the sibling to consult first ('list_docs') and warn against using it for PDF compilation. Alternatives and exclusions are stated, not inferred.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 5, 2026

Changedrender4 fields changed

changedInput schema / properties / fmt / description

Previous value: -"Output format: one of `latex`, `markdown`, `json`, `text`."New value: +"Output format the document is rendered to. Must be exactly one of: 'json', 'latex', 'markdown', 'text' (see `render`'s docstring / `list_docs`)."

addedInput schema / properties / fmt / enum

Added value: +[
+  "json",
+  "latex",
+  "markdown",
+  "text"
+]

changedInput schema / properties / mode / description

Previous value: -"Render mode: one of `draft`, `submission`, `camera-ready`."New value: +"Build mode / profile applied when rendering. Must be exactly one of: 'camera-ready', 'draft', 'submission'."

addedInput schema / properties / mode / enum

Added value: +[
+  "camera-ready",
+  "draft",
+  "submission"
+]

2 tool updatesv0.0.9Jul 10, 2026

Changedaudit_pdf2 fields changed

addedInput schema / properties / strict / description

Added value: +"When true, every blocking-flavour FAIL is surfaced as `blocking_failure: true` in the response."

addedInput schema / properties / target / description

Added value: +"PDF file path or directory to audit; defaults to `build/` under INCLUSIO_CONTENT_DIR."

Changedrender3 fields changed

addedInput schema / properties / doc_id / description

Added value: +"Registered template document id — see `list_docs`."

addedInput schema / properties / fmt / description

Added value: +"Output format: one of `latex`, `markdown`, `json`, `text`."

addedInput schema / properties / mode / description

Added value: +"Render mode: one of `draft`, `submission`, `camera-ready`."

4 tool updatesv0.0.7Jul 10, 2026
- First observedaudit_pdf
- First observeddoc_count
- First observedlist_docs
- First observedrender

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.4/5.0

Scored 2026-10-05 22:45 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: list_docs enumerates documents, audit_pdf validates PDFs, doc_count provides a lightweight count, and render generates document sources. The descriptions explicitly state when to use each and cross-reference alternatives, eliminating ambiguity.

Naming Consistency5/5

Tool names follow a consistent snake_case verb_noun pattern: list_docs, audit_pdf, doc_count (verb_noun with doc as noun), and render (verb, though noun omitted but still clear). All are lowercase with underscores, maintaining a predictable style.

Tool Count4/5

With only 4 tools, the set is compact but covers essential operations for document management and audit. While the count is slightly low, each tool serves a distinct role, and the addition of doc_count as a lightweight probe is justified.

Completeness3/5

The tool surface covers listing, rendering, and auditing, but lacks operations for modifying the document manifest (e.g., create, update, delete) and direct PDF compilation. This creates notable gaps for a complete document lifecycle, though the server's scope may intentionally focus on read-only and rendering tasks.

Maintenance

ActivityActive

ResponsivenessWithin a week

Resources

Need Help?

Related Servers

Related MCP Connectors

pdfs.buildOAuth
build.pdfs
Design, publish and render PDF templates with Typst. Full template lifecycle over MCP.
Workplace & Productivity Developer Tools
1
makespdf A
com.makespdf
Compliant PDFs (PDF/A-2A + PDF/UA-1) from markdown or a compact DSL - fast, no headless browser.
Workplace & Productivity
111
blinkpdfOAuth
io.blinkpdf
Render Markdown and LLM output into accessible PDF/UA-1 PDFs. No headless Chromium.
Developer Tools
2
stagenth · 文档生成 A
com.stagenth
Generate PDF, Word (.docx) and PowerPoint (.pptx) documents from Markdown over MCP.
File Systems Workplace & Productivity
3

Related MCP Servers

doc-ops-mcp
Documentation Access Content Management Systems
Tele-AI
A
license
B
quality
D
maintenance
A universal MCP server for document processing, conversion, and automation. Handle PDF, DOCX, HTML, Markdown, and more through a unified API and toolset.
Updated 12 days ago (2026-09-26 04:33 UTC)
13
20 npm
140
MIT
FastMCP LaTeX Server (tex-mcp)
Developer Tools Command Line
devroopsaha744
A
license
Not graded
quality
D
maintenance
MCP server that renders LaTeX to PDF via pdflatex, supporting raw LaTeX and Jinja2 templates with artifact generation.
Updated a year ago (2025-11-09 11:43 UTC)
11
MIT
docwriter-mcp-server
Developer Tools Documentation Access
cyanheads
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server for programmatic creation, modification, and compilation of structured LaTeX documents.
Updated a year ago (2025-07-22 08:14 UTC)
14 npm
3
Apache 2.0
easyaccesspdf-mcp
Design Tools Developer Tools
luotwo
A
license
A
quality
B
maintenance
EasyAccessPDF is a production MCP server for PDF accessibility and document conversion. Five tools: convert documents (PDF/DOCX/PPT/XLS/HTML/EPUB/RTF/ODT/TXT) to clean Markdown; export PDFs to JSON/HTML/text/annotated-PDF; run veraPDF PDF/UA-1 (ISO 14289) accessibility audits with graded reports; auto-tag and remediate PDFs for WCAG 2.1/2.2, Section 508, ADA Title II and EAA/EN 301 549 compliance.
Updated 3 months ago (2026-07-22 02:30 UTC)
5
MIT

Contents

Install

Build from source

Quick Start

Features

Usage

Build, audit, judge a registered document

Score a CV against a job description

Drive the engine over MCP

Embed C2PA Content Credentials

Tools

Architecture

Examples

Documentation

Publishing against an external content tree

Development

Security

Related MCP Servers

MCP Registry

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers