Skip to main content
Glama
Sign In
Typst Web MCP

Typst Web MCP

by caphefalumi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

typst_get_diagnostics

Retrieve Typst compiler errors, warnings, hints, and line/column details from a typst.app project using local CLI compilation or a cloud fallback.

Instructions

Retrieve compiler diagnostics (errors, warnings, line/column numbers, and hints) for a https://typst.app project. Supports both local Typst CLI compilation (fastest) and Typst Web cloud diagnostics (zero-binary fallback using typst.app cloud compiler).

Input Schema

NameRequiredDescriptionDefault
modeNoDiagnostics mode: 'auto' (prefers local Typst CLI if installed, falls back to Typst Web cloud compiler), 'cli' (requires local typst binary), or 'web' (uses Typst Web cloud compiler). Defaults to 'auto'.
mainFileNoOptional main .typ entry file override (defaults to project previewed file or main.typ)
projectIdYesThe Typst project ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.3.1
    • addedInput schema / properties / mode
      Added value: +{
+  "description": "Diagnostics mode: 'auto' (prefers local Typst CLI if installed, falls back to Typst Web cloud compiler), 'cli' (requires local typst binary), or 'web' (uses Typst Web cloud compiler). Defaults to 'auto'.",
+  "enum": [
+    "auto",
+    "cli",
+    "web"
+  ],
+  "type": "string"
+}
  2. First observedv1.0.2

TDQS

A4/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 disclose the key behavioral trait: two execution backends, with local CLI preferred for speed and a zero-binary cloud fallback. It does not mention that web mode may require authentication or what happens when neither backend is available, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the resource and the returned data, then the backend nuance. No filler or redundancy; every clause adds 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, the description compensates by naming the diagnostic fields returned (errors, warnings, line/column, hints) and explaining backend selection. Minor gaps remain around auth requirements for web mode and failure behavior, but an agent has enough to invoke it correctly.

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 coverage is 100%, so parameter documentation is already complete and 3 is the baseline. The description adds only marginal semantic value, echoing the local-vs-cloud tradeoff ('fastest', 'zero-binary fallback') that the mode enum description already explains.

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 ('Retrieve compiler diagnostics ... for a typst.app project') and enumerates the payload (errors, warnings, line/column numbers, hints). It is clearly distinct from siblings such as typst_read_file or typst_export_pdf, which read content or render output rather than report compilation problems.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the tool to call after editing to verify compilation, and the mode parentheticals hint at when local vs cloud applies. There is no explicit statement of when to prefer this over alternatives (e.g., read_file for inspecting source) or any prerequisites, so the guidance stays at the minimum-viable level.

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