Skip to main content
Glama
Sign In
@pressa/mcp

@pressa/mcp

by pressa-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

@pressa/mcp

MCP (Model Context Protocol) server for Pressa - LaTeX in, publication-quality PDF out. This server lets AI assistants compile documents through a standardized interface.

No API key required to start. Add the server, ask for a PDF, get one. A key raises the limits later.

Setup

Add this to your MCP client configuration (e.g. Claude Desktop, Cursor):

{
  "mcpServers": {
    "pressa": {
      "command": "npx",
      "args": ["-y", "@pressa/mcp"]
    }
  }
}

That is the whole configuration. The server starts in anonymous mode and exposes the compile tool and the public template gallery, which work with no credentials: 3 successful PDFs per day, and failed attempts do not count against that, so an assistant can iterate on its LaTeX for free.

To unlock the rest, add a key:

{
  "mcpServers": {
    "pressa": {
      "command": "npx",
      "args": ["-y", "@pressa/mcp"],
      "env": {
        "PRESSA_API_KEY": "pressa_your_key_here"
      }
    }
  }
}

Get a free key at pressa.dev. Takes about 30 seconds, no credit card. It raises the limit to 50 compilations per month and registers the template, asset and render tools.

Related MCP server: GoLatex MCP Server

Hosted server (no install)

The same tools are also served over Streamable HTTP at https://api.pressa.dev/mcp, so a client that supports remote MCP servers needs no Node.js and no local process:

claude mcp add --transport http pressa https://api.pressa.dev/mcp

Keyless, it exposes compile and the public template gallery (list_public_templates, get_public_template, render_public_template). Send an Authorization: Bearer <key> header to register the template, asset and render tools as well.

Environment Variables

Variable

Required

Default

Description

PRESSA_API_KEY

No

-

Pressa API key (starts with pressa_). Without it the server runs in anonymous mode and exposes only compile and the public template tools.

PRESSA_API_URL

No

https://api.pressa.dev

API base URL

Anonymous mode

With no PRESSA_API_KEY set, the server starts anyway rather than refusing to run, and registers only the tools that work without an account: compile, list_public_templates, get_public_template and render_public_template. Tools that need an account are not registered at all, because a tool that cannot succeed is worse than an absent one.

Anonymous limits: pdflatex only, up to 3 pages, 30 KB of source, no image assets, and PDF links that expire after 1 hour.

Error handling

Compilation failures return a structured diagnosis rather than a raw TeX log: the error class, the offending command, and a concrete suggested fix (often a missing \usepackage). An assistant is expected to apply the fix and retry on its own instead of showing the user a compiler log.

Tools

compile

Compile LaTeX source code into a PDF.

Input:

Parameter

Type

Required

Description

latex

string

Yes

Complete LaTeX source code. Must contain \documentclass, \begin{document}, \input{}, or \include{}. Plain text, markdown, or raw notes are rejected with not_latex_source (422). The AI agent should generate LaTeX itself, not bounce back to the user.

compiler

string

No

"pdflatex" (default), "xelatex", or "lualatex" (Pro and Business plans only)

Each plan has limits on pages per document, LaTeX source size, PDF output size, and compile timeout. If a compile exceeds your plan's page limit, the document does not count against your monthly quota and the MCP response includes the limit and an upgrade URL. Non-LaTeX input is rejected with a structured requirements list and an example_template so the LLM can self-correct without user intervention.

Output (success):

{
  "job_id": "ffc2bd62-3b67-45d6-be14-b529c4b9489f",
  "pdf_url": "https://api.pressa.dev/api/v1/pdfs/ffc2bd62...?sig=xxx&exp=xxx",
  "expires_at": "2026-04-09T20:44:55Z",
  "pages": 1,
  "compilation_time_ms": 359,
  "usage": {
    "plan": "free",
    "compilations_this_month": 9,
    "monthly_limit": 50
  }
}

Output (error): Compilation log and error line number.

list_public_templates, get_public_template, render_public_template

Pressa's public document templates (pressa.dev/templates): invoices, purchase orders, packing slips, delivery notes, receipts, reports, certificates, resumes and cover letters. No key needed.

  • list_public_templates: every template with a summary, a preview image URL and its colours. Designs of one document (document, e.g. five resume designs) take the same data.

  • get_public_template (template: slug): the fields (JSON schema), sample data and filling instructions.

  • render_public_template (template: slug, data: object shaped like the sample, optional color): fills the template and returns pdf_url. A field that is missing or of the wrong type comes back as a list to fix, at no cost.

Each template also has plain instructions for assistants at https://pressa.dev/templates/<slug>/agent.md.

usage

Get current API usage statistics.

Input: None.

Output:

{
  "user": {
    "email": "user@example.com",
    "username": "user",
    "plan": "free"
  },
  "usage": {
    "compilations_this_month": 9,
    "monthly_limit": 50,
    "remaining": 41,
    "resets_at": "2026-04-30T23:59:59Z"
  },
  "api_key": {
    "prefix": "pressa_a",
    "name": "my-key",
    "total_requests": 15,
    "last_used_at": "2026-04-08T20:44:55Z"
  }
}

save_template

Save or update a LaTeX template by name. Paid plans only. Upserts: a second call with the same name overwrites the first.

Parameter

Type

Required

Description

name

string

Yes

Template name (max 100 chars). Unique per user.

latex_content

string

For a new template

Full LaTeX source for the template body. May be omitted when converting the saved source with placeholder_engine: "liquid".

description

string

No

Short human-readable summary (max 500 chars). Shown in list_templates.

instructions

string

No

Agent playbook (prose markdown, max 50000 chars). Describes how to fill the template - defaults, workflow rules, edge cases, conditional logic. Optional but recommended for templates with dynamic parts. See note below.

placeholder_engine

string

No

"liquid": the source contains Liquid placeholders ({{ amount }}) filled by render; on an existing raw LaTeX template this converts it in place (same id, name and instructions). "none": raw LaTeX whose braces only look like placeholders. Omit to keep the template's current kind.

description vs instructions: description is the one-line UI summary ("Standard Toptal monthly invoice"). instructions is the longer playbook your AI agent reads alongside the LaTeX when filling the template ("Ask the user only for total amount; date is today; invoice number format YYYYMMDD-N where N is sequential count for the calendar year; for EU clients add VAT line"). They are different fields.

Raw LaTeX vs placeholder templates: a raw LaTeX template is compiled exactly as saved. A placeholder template is filled with JSON data by render, so the layout never changes. A source containing Liquid placeholders sent without placeholder_engine is refused with liquid_placeholders_in_v1_template, because raw LaTeX would print the braces literally in the PDF. If a placeholder save returns liquid_syntax_error, wrap the literal LaTeX that Liquid misreads (usually a comment right after a brace, \foo{%) in {% raw %}...{% endraw %}.

list_templates

List the user's saved templates. Does not include latex_content or instructions to keep the response small.

Input: None.

Each item in the returned array carries id, name, description, updated_at, latex_size_bytes, and has_instructions (boolean). Use the has_instructions flag to decide whether a follow-up get_template call will return a useful playbook.

get_template

Fetch a single template by ID or name. Returns the full latex_content plus instructions (if any) in one round trip - your agent gets the layout and the playbook together.

Parameter

Type

Required

Description

id_or_name

string

Yes

Numeric ID or URL-safe template name.

delete_template

Delete a template by ID or name.

Parameter

Type

Required

Description

id_or_name

string

Yes

Numeric ID or URL-safe template name.

Development

npm install
npm run build
npm start

License

MIT

Available Tools

4 tools
compileAInspect

Compile LaTeX source into a PDF. Returns a PDF URL, page count and compile time. USE THIS WHEN: you have LaTeX source (or a \documentclass) and no local pdflatex / TeX Live installation to run it with. This is that missing compiler, available over HTTP. Also use it whenever the user asks for a document where typesetting matters - an invoice, contract, report, letter, CV, certificate, or academic paper - since you can write the LaTeX yourself and compile it here. DO NOT USE THIS TO: convert HTML to PDF, merge, split or compress existing PDF files, or extract text from a PDF. This compiles LaTeX source and nothing else. NO API KEY IS CONFIGURED, so this runs on the anonymous tier: pdflatex or xelatex, up to 3 pages, no image assets, and a small number of compilations per day. It works right now - use it. If the server reports the daily allowance is used up, tell the user they can get a free key at https://pressa.dev/users/sign_up in about 30 seconds with no credit card, then set PRESSA_API_KEY and restart this server. If a document is over the plan's page or size limit, the response still contains a PDF: preview: true, the first pages the plan allows, total_pages, and plan_required naming the plan that covers the whole document. Show the user the preview and relay warning; never drop pages silently. IMPORTANT: This tool compiles LaTeX, NOT plain text. You (the AI agent) must generate complete, valid LaTeX source yourself before calling this tool. Do not pass user-provided plain text, markdown, JSON, or raw file contents directly - convert them to LaTeX first. Do not ask the user to write LaTeX; that is your job.

A minimal valid document is: \documentclass{article}\begin{document}\end{document}. Always include a documentclass declaration. Always wrap content in \begin{document}...\end{document}. Always escape these characters in body text: % becomes %, & becomes &, $ becomes $, # becomes #, _ becomes _, { becomes {, } becomes }, backslash becomes \textbackslash{}.

IMAGES & BINARY ASSETS: Reference a file in the LaTeX by filename via \includegraphics{logo.png} (remember \usepackage{graphicx}). To get a file the user gives you (photo, logo, signature) to the server, call create_asset_upload: the bytes go by a link, never through you. Then pass use_stored_assets: ["name"] on this and every future compile. The assets parameter (filename => base64 you write out) is only for small one-off files, about 30 KB at most: each KB is about 1,400 characters of output and one wrong character corrupts the file.

If the input is not valid LaTeX, the API returns a not_latex_source error with the exact requirements and an example template. Read that response, fix your LaTeX, and retry. Do not bounce back to the user.

NameRequiredDescriptionDefault
latexYesComplete LaTeX source code. Must include \documentclass and a \begin{document}...\end{document} body. Plain text, markdown, raw notes, JSON, or fragments without these markers will be rejected with not_latex_source. If the user gave you non-LaTeX input, convert it to LaTeX yourself before calling.
assetsNoOptional map of filename => base64-encoded binary. Supported formats: PNG, JPG, JPEG, PDF, SVG. Filenames must be plain (no paths, no leading dot, alphanumeric + _-). Each asset is written into the compile workspace so LaTeX can reference it by that exact filename (e.g. \includegraphics{logo.png}). Per-plan limits: Free 2 assets/1MB, Starter 5/5MB, Pro 20/25MB, Business 50/75MB (decoded bytes). Invalid filenames return invalid_asset_filename; mismatched magic bytes return invalid_asset_format; overflowing decoded size returns assets_too_large (413); too many entries returns too_many_assets.
compilerNoLaTeX compiler to use (default: pdflatex). pdflatex and xelatex are available on every plan. lualatex requires Pro or Business; on Free or Starter it returns compiler_not_available.
use_stored_assetsNoNames of assets in the user's persistent library to inject into this compile. Put a file there with create_asset_upload (any size) or save_asset (small base64), then reference it by name here. Cannot collide with names in the ephemeral `assets` map - asset_name_collision (422) if a name appears in both.

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: anonymous-tier constraints (pdflatex/xelatex, 3-page cap, no image assets, daily quota), what happens on overflow (preview:true, total_pages, plan_required, warning), and the upgrade path with env var. It stops short of stating idempotency or caching behavior across repeat compiles, which keeps it off a 5.

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 front-loaded and signposted with headers (USE THIS WHEN, DO NOT USE, IMAGES & BINARY ASSETS), so an agent can skim. It is long, though, and a few lines repeat schema content (the escaping list, the minimal document template) and restate 'don't ask the user' twice.

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?

No output schema exists, yet the description still describes the response shape (PDF URL, page count, compile time) and the overflow variant's fields. Combined with the error-code guidance (not_latex_source, invalid_asset_filename, assets_too_large), nothing an agent needs to call this correctly or recover from failure is missing.

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 the baseline is 3; the description earns above that by adding operational meaning the schema lacks — the practical ~30 KB ceiling on inline `assets` ('1,400 characters per KB, one wrong character corrupts the file') and the create_asset_upload → use_stored_assets workflow. It doesn't explain when to pick xelatex vs lualatex beyond the plan gate, which is a minor remaining gap.

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?

Opens with a precise verb+resource+output: 'Compile LaTeX source into a PDF', and immediately names the return values. It clearly distinguishes itself from the template siblings by being the raw compiler rather than a template renderer.

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 'USE THIS WHEN' and 'DO NOT USE THIS TO' blocks name both the positive trigger (no local TeX install, typesetting-sensitive documents like invoices/CVs) and the exclusions (HTML-to-PDF, merge/split/compress, text extraction). An agent can route to or away from this tool without inference.

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

get_public_templateA
Read-onlyIdempotent
Inspect

Get a public template's fields (JSON schema), sample data, filling instructions and LaTeX source. Read the instructions before collecting data from the user. To make the PDF, pass the data to render_public_template; to change the layout itself, edit the source and use compile. Works without an API key.

NameRequiredDescriptionDefault
templateYesTemplate slug from list_public_templates, e.g. invoice or classic-resume.

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, and non-destructive behavior, so the safety profile is covered. The description adds genuinely new context: it works without an API key (auth requirement) and itemizes the returned artifacts, which matters since there is no output schema. It does not say what happens for an unknown slug, keeping it just short of a 5.

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?

Three short sentences, zero filler, and the payoff (what you get back) is front-loaded ahead of the prerequisite and sibling routing. Every clause carries actionable information.

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 single-parameter read tool with no output schema, the description compensates by enumerating return contents, stating the no-API-key requirement, and naming the correct next tools. Nothing an agent needs to call it correctly and act on the result 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% and the single 'template' parameter is documented there with a slug example and its source tool. The description mentions 'public template' but adds no slug syntax, format, or validation detail beyond the schema, so the baseline of 3 applies.

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 ('Get a public template') and enumerates exactly what comes back: JSON schema fields, sample data, filling instructions, and LaTeX source. This is clearly separable from render_public_template (produces a PDF) and compile (rebuilds layout), so an agent can pick it without opening a 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?

Gives explicit sequencing guidance ('Read the instructions before collecting data from the user') and routes to both alternatives with the conditions that select them: render_public_template for output, compile after editing source for layout changes. No inference required.

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

list_public_templatesA
Read-onlyIdempotent
Inspect

List Pressa's public, professionally designed document templates (invoices, purchase orders, packing slips, delivery notes, receipts, reports, certificates, resumes, CVs, cover letters), each with a one-line summary, a preview image URL and the colours it comes in. Several designs of one document (document, e.g. five resume designs) take the same data. Use this when the user wants one of these documents and has no layout of their own, or asks to see designs to choose from. Works without an API key.

NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

Goes beyond the annotations (readOnly/idempotent/non-destructive) by disclosing auth behaviour ('works without an API key') and the shape of each returned item: one-line summary, preview image URL, and available colours. It also explains the data-sharing contract across designs of the same document type. Pagination and item counts remain unstated, which keeps it short of a 5.

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 the verb and resource, then usage guidance, then structural nuance about shared data across designs. The long parenthetical document-type list is dense but functional for matching user vocabulary; every remaining sentence carries information.

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 no output schema and no annotations describing return content, the description correctly carries the burden by naming the fields of each result (summary, preview URL, colours). The only gap is result volume/ordering, which is minor for a catalogue-listing 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate and it correctly avoids inventing filter options.

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 ('List Pressa's public, professionally designed document templates') and enumerates the concrete document families covered, which lets an agent match a user request without opening any schema. The singular sibling get_public_template is implicitly distinguished by the enumerating 'List' verb plus the note that several designs exist per document type.

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?

Gives an explicit selection condition: use it when the user wants one of these documents and has no layout of their own, or asks to see designs to choose from. That is a clear use trigger, though no sibling (get_public_template, render_public_template) is named as the alternative for the post-selection step.

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

render_public_templateAInspect

Fill a public template with the user's data and return a PDF link. Data must match the template's schema (see get_public_template); a missing field comes back as a list of what to ask for, and costs nothing. The designs of one document take the same data (the five resume designs, as do the packing slip and the delivery note), so switching design is the same call with a different slug, and color prints a design in another of its colours. Works without an API key within the daily free limit.

NameRequiredDescriptionDefault
dataYesValues for the template's fields, shaped like its sample data.
colorNoOptional: one of the template's colours (list_public_templates), e.g. navy. Left out, the default.
templateYesTemplate slug, e.g. invoice or modern-resume.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), yet the description adds real context beyond them: the return is a PDF link, an incomplete payload returns a list of missing fields and 'costs nothing', and there is a daily free limit without an API key. The quota statement is vague about the actual limit, which keeps this just short of a 5.

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 purpose and return value are front-loaded in the first sentence, and every later sentence carries operational information. The parenthetical listing designs ('the five resume designs, as do the packing slip and the delivery note') is denser than needed and could be compressed.

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?

Covers what an agent needs for a mutation-shaped call with a nested free-form object: where the shape comes from, what a bad payload yields, how to vary design or colour, and the auth/quota boundary. No output schema exists, but the description states the return (a PDF link).

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 the baseline is 3. The description still adds meaning the schema does not: `template` accepts sibling designs that share one data shape, and `color` reprints a design in another of its colours, which tells the agent these are interchangeable variants rather than distinct payloads.

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, resource and outcome: fill a public template with user data and return a PDF link. It is clearly separable from get_public_template (fetch the schema) and list_public_templates (discover slugs/colours) 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?

Explicitly routes the agent: data must match the schema 'see get_public_template', and the design-switching case is spelled out ('same call with a different slug'). It also names the precondition for free/keyless use, so an agent knows when this call will succeed versus be rejected.

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. 4 tool updatesv0.11.4
    • Changedcompile1 field changed
      • changedInput schema / properties / use_stored_assets / description
        Previous value: -"Names of assets in the user's persistent library to inject into this compile. Use this instead of re-sending the same bytes in `assets` every time when a file (logo, signature, letterhead) will be reused across many compiles. Save the file once via save_asset, then reference it by name here. Cannot collide with names in the ephemeral `assets` map - asset_name_collision (422) if a name appears in both."New value: +"Names of assets in the user's persistent library to inject into this compile. Put a file there with create_asset_upload (any size) or save_asset (small base64), then reference it by name here. Cannot collide with names in the ephemeral `assets` map - asset_name_collision (422) if a name appears in both."
    • Addedget_public_template
    • Addedlist_public_templates
    • Addedrender_public_template
  2. 1 tool updatev0.7.2
    • First observedcompile
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation4/5

The four tools have reasonably clear boundaries: list/get/render form a template pipeline and compile handles raw LaTeX. The only mild overlap is compile vs render_public_template, both producing PDFs, though descriptions distinguish them (own LaTeX source vs filling a template). The compile description, however, tells the agent to call `create_asset_upload`, a tool that does not exist, which injects confusion into the set.

Naming Consistency4/5

Three tools follow a clear verb_object pattern scoped to templates (list_public_templates, get_public_template, render_public_template). `compile` is a bare verb that deviates from the pattern, but it is unambiguous for its distinct LaTeX-compilation role.

Tool Count4/5

Four tools is a lean, well-scoped surface for a LaTeX/PDF template service covering discovery, schema retrieval, rendering, and raw compilation. It is slightly thin given that the compile description references an asset-upload tool that is not present.

Completeness3/5

The template lifecycle (list → get schema → render) plus raw compile is covered, but compile explicitly instructs calling `create_asset_upload` for user-supplied images, and no such tool exists, leaving a hard dead end. There is also no way to manage or list stored assets across calls.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers