Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
INCLUSIO_CONTENT_DIRNoAbsolute 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_docsA

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.
    
audit_pdfA

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.
    
renderA

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.
    
doc_countA

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.
    

Prompts

Interactive templates invoked by user choice

NameDescription
generate_accessible_template_wizardGuide 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

NameDescription
meta_resourceReturn the raw text of data/meta.yaml (project manifest).
audit_latest_resourceReturn the last audit report JSON (build/.audit/latest.json). Empty JSON object when no audit has run yet.
version_resourceReturn the engine version and MCP Server Card metadata.

TDQS

A4.4/5.0

Scored 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