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
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_docsA

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

    Use this first to discover the ``doc_id`` values and document
    classes available before calling ``render`` or ``audit_pdf``. For
    just the document count (a connectivity probe) call ``doc_count``
    instead; to read the raw manifest text use the ``inclusio://meta``
    resource. Reads ``data/meta.yaml`` under ``INCLUSIO_CONTENT_DIR``
    (or the packaged content root); it writes nothing.

    Returns one dict per document with id, class, src, title, and
    any `pdf_a` / `note` flags. Empty list when no manifest exists.
    
audit_pdfA

Audit built PDFs for accessibility conformance with veraPDF.

    Use this to check whether a rendered PDF meets PDF/UA-2, WTPDF, and
    PDF/A-4f before publishing; it shells out to ``verapdf`` read-only
    and never modifies the PDF or the manifest. To produce a document's
    source first call ``render``; to see which documents exist call
    ``list_docs``. This inspects existing PDFs only — it does not build
    them.

    Args:
        target: PDF path or directory. Defaults to `build/` under
            INCLUSIO_CONTENT_DIR.
        strict: When True, every blocking-flavour FAIL is surfaced
            in the response (`blocking_failure: True`); the caller
            decides whether to treat this as an error.

    Returns the audit report dict (summary, by_pdf, by_flavour).
    Requires `verapdf` on PATH; the report contains
    `verapdf_present: False` when it is not.
    
renderA

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

    Use this to materialise a document's source (LaTeX, Markdown, JSON,
    or text) into ``build/.cache/rendered/`` before compiling or
    auditing it. This writes the rendered output file but never mutates
    ``data/meta.yaml``. Discover valid ``doc_id`` values with
    ``list_docs`` first; audit the resulting PDF afterwards with
    ``audit_pdf``. This is the only write tool on this server — the
    others are read-only.

    Args:
        doc_id: registered template id (see `list_docs`).
        fmt: one of `latex`, `markdown`, `json`, `text`.
        mode: one of `draft`, `submission`, `camera-ready`.

    Returns `{"doc_id": …, "format": …, "output_path": …, "bytes": int}`.
    
doc_countA

Count the documents registered in data/meta.yaml.

    Use this as a cheap connectivity/health probe to confirm the server
    sees a valid manifest without transferring the full document list.
    When you need each document's id, class, and flags, call
    ``list_docs`` instead.

    Cheap probe for clients that just want to verify connectivity
    and that the engine sees a valid manifest.
    

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

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

list_docs and doc_count are the only near-overlap pair, but their descriptions clearly separate a full metadata listing from a cheap count probe. render and audit_pdf target distinct stages of the workflow with no ambiguity.

Naming Consistency3/5

list_docs and audit_pdf follow a verb_noun pattern, but doc_count reverses the pattern and render is a bare verb without an object. The names are readable and all snake_case, but the imperative convention is not applied consistently.

Tool Count5/5

Four tools is a well-scoped size for a focused document rendering and PDF auditing server. Each tool serves a distinct step or lightweight probe, and doc_count does not feel like unnecessary padding.

Completeness2/5

The set covers discovery, counting, rendering source, and auditing existing PDFs, but there is no tool to compile rendered LaTeX or Markdown into a PDF, so after render an agent cannot produce the PDF that audit_pdf expects. Document registration/update may be intentionally external, but the missing build/compile step is a significant workflow gap.

Maintenance

ActivityActive
ResponsivenessWithin a week