inclusio-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| INCLUSIO_CONTENT_DIR | No | Absolute path to the content directory containing LaTeX sources, YAML metadata, and brand assets. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_docsA | List every document registered in data/meta.yaml with its metadata. |
| audit_pdfA | Audit built PDFs for accessibility conformance with veraPDF. |
| renderA | Render a registered template-driven document to a file on disk. |
| doc_countA | Count the documents registered in data/meta.yaml. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| generate_accessible_template_wizard | Guide the user through building an accessible document with inclusio. Produces a step-by-step wizard that teaches the correct tool order — ``list_docs`` to discover registered templates, ``render`` to materialise a document's source, then ``audit_pdf`` to check PDF/UA-2, WTPDF, and PDF/A-4f conformance — alongside accessible-template best practices (tagged structure, alt text, reading order, embedded fonts, high contrast, document language). Faithful to what inclusio actually does: it renders registered LaTeX-first templates and audits PDFs; it does not design documents from scratch. Args: document_type: the kind of document to build (e.g. `cv`, `paper`, `report`, `letter`). Known kinds are steered toward the matching registered class; any other value receives generic guidance. Returns the wizard guidance string for the requested document type. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| meta_resource | Return the raw text of data/meta.yaml (project manifest). |
| audit_latest_resource | Return the last audit report JSON (build/.audit/latest.json). Empty JSON object when no audit has run yet. |
| version_resource | Return the engine version and MCP Server Card metadata. |
TDQS
Scored across 4 tools
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.
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.
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.
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.