Skip to main content
Glama
Sign In
trahloff

Aldine

by trahloff
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Typeset the project

compile
Idempotent

Typesets a LaTeX project with latexmk, returning parsed errors with file and line plus a PDF link so users can review the result.

Instructions

Typeset the project with latexmk: parsed errors [{type,file,line,message,context?,source?}] (type "error" rows before "warning" rows, first 50; errorsTotal counts the errors and warningsTotal the warnings, whether or not the list was capped; box warnings are omitted; context is the source line the engine was reading, source the tool that raised a warning — latex, a package name, biber — and a biber row names the .bib and its line), on failure ≤4 KB of the log around the first error, pages, and a deep link into Aldine. With errors present the PDF is complete but the bibliography and cross-references are not rebuilt — say so. pdfUrl is a signed link to this run's PDF that anyone can open for 15 minutes — hand it to the user as the way to see the result, and call get_pdf_url for a fresh link later instead of recompiling. pdfStale:true means this run wrote no PDF: pdfUrl shows the previous one, or is null when that no longer exists. Takes up to ~2 minutes; progress notifications arrive while it runs. Compile after a coherent set of edits, not after each one, and never just to check syntax. On errors: fix and recompile at most 3 times, narrating each attempt ("attempt 2 of 3: added natbib"), then stop and ask the user, quoting the failing file:line. A project with no .tex file cannot be typeset: write the main document first. A compiler-not-responding, compiler-cannot-see-the-project, missing-package (hint), quota, or typeset-already-running error is for the user to act on — relay it, do not retry.

Input Schema

NameRequiredDescriptionDefault
branchNoBranch name (defaults to 'main'). Every result, error results included, echoes {branch, head} — head is the branch's current commit (after a write, the commit that write made). Pass the branch explicitly whenever you are not on main.
projectNoProject id. Optional when the access token is scoped to exactly one project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already establish that this is a non-read-only, idempotent, non-destructive operation. The description adds substantial behavioral context beyond annotations: parsed error structure, first-50 cap with totals, omitted box warnings, failure-log size, PDF completeness caveats, signed URL lifetime, pdfStale semantics, and job duration with progress notifications. It does not contradict any annotation.

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 description is dense but front-loaded, opening with the core operation before output and failure details. Nearly all content is useful for a complex compile tool with no output schema, though the long paragraph and nested parentheticals could be more scannable. It is not padded, but the structure is heavy.

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?

Because no output schema exists, the description carries the full burden of explaining return values and does so thoroughly: error rows, total counts, log excerpt, pages, deep link, PDF URL and staleness behavior. It also covers timing, progress, error recovery, and user-actionable failure modes, leaving little an agent needs unstated.

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?

With schema description coverage at 100%, the schema already documents the branch and project parameters in detail. The description mentions project context but does not add branch/project semantics beyond what the schema provides. Baseline 3 is appropriate because the schema carries parameter meaning.

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?

The description begins with a specific verb and resource: "Typeset the project with latexmk." It also distinguishes itself from sibling get_pdf_url by explaining that get_pdf_url should be used for a fresh link instead of recompiling. An agent can identify the operation and immediate purpose without opening the 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?

It gives explicit when-to-use guidance (after coherent edits, not after each edit or just to check syntax) and when-not-to-use guidance. It also specifies retry limits, narration requirements, escalation behavior, and alternatives such as get_pdf_url. A missing-main-document precondition and user-actionable errors are also clearly called out.

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

Deploy Server

Other Tools