Skip to main content
Glama
Sign In
Typst Web MCP

Typst Web MCP

by caphefalumi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

typst_read_file

Read Typst project text files in bounded line/byte pages or images as native image blocks, returning source content, continuation offsets, and content hashes for safe edits.

Instructions

Read project text in bounded pages (default 200 lines/16 KiB) or images as native image blocks. content contains source only; use nextOffset for continuation. contentHash covers the entire raw text file: pass it as expectedHash to typst_edit_file. Compact file metadata by default; output='full' adds metadata, not extra source lines. Use grep to locate relevant lines before reading large files.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum complete lines to read (default: 200). Use nextOffset to continue.
offsetNoLine number to start reading from (1-indexed)
outputNocompact (default): minimal file metadata; full: all file metadata. Both use offset/limit/maxBytes pagination.
filePathYesFile path/name (e.g. 'main.typ') or file ID
maxBytesNoMaximum returned source bytes, including line number prefixes (default: 16384, maximum: 1 MiB). Increase for unusually long lines.
projectIdYesThe Typst project ID
lineNumbersNoWhether to prefix each line with its 1-indexed line number (e.g. '1 | ')

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.3.1
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Maximum complete lines to read (default: 200). Use nextOffset to continue.",
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / lineNumbers
      Added value: +{
+  "description": "Whether to prefix each line with its 1-indexed line number (e.g. '1 | ')",
+  "type": "boolean"
+}
    • addedInput schema / properties / maxBytes
      Added value: +{
+  "description": "Maximum returned source bytes, including line number prefixes (default: 16384, maximum: 1 MiB). Increase for unusually long lines.",
+  "maximum": 1048576,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Line number to start reading from (1-indexed)",
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / output
      Added value: +{
+  "description": "compact (default): minimal file metadata; full: all file metadata. Both use offset/limit/maxBytes pagination.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  2. First observedv1.0.2

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose real behavior: default 200-line/16 KiB paging, continuation via offset, image files returned as native image blocks, and that contentHash covers the whole raw file. It doesn't say what happens on missing files or non-text assets, 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?

Four dense sentences, front-loaded with the core capability, then pagination, hash, and output-mode details. Slightly terse in places but no filler sentences.

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?

Covers what content contains, what contentHash is for, what compact/full change, and how pagination behaves, which is enough to call a read tool with no annotations and no output schema. Error handling and image-specific paging limits are the only notable omissions.

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 the baseline is 3; the description adds useful meaning about pagination continuation and the compact-vs-full metadata distinction. However, it refers to 'nextOffset' when the actual parameter is 'offset', which can mislead an agent about the parameter name.

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 ('Read project text ... or images as native image blocks') plus scope ('in bounded pages'), and explicitly routes large-file lookups to grep, so it is distinguishable from typst_grep_project and the write siblings.

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 concrete guidance: use grep to locate lines before reading large files, use nextOffset to continue, and pass contentHash as expectedHash to typst_edit_file. It lacks an explicit 'when not to use' or a note on how it differs from typst_list_files, but the intended workflow is clear.

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