Galley MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| galley_pingB | Liveness check. Returns 'pong' with the kernel version. |
| read_documentA | Returns the current text of the session's target file from the live shared project. |
| list_filesA | Lists the live (non-deleted) files of the shared project — exact path + size (UTF-8 bytes when sizeExact, else a cheap lower bound), deterministic order; duplicate-path conflicts are flagged per entry. BINARY files (images/PDFs) appear too, carrying a { kind:"binary", hash, mime } pointer descriptor with an exact sizeBytes — pass that path to read_file to get the pointer. Read-only context: edits still go through propose_edit and target only the session's file. |
| read_fileA | Returns the live replicated text of any project file by EXACT path (as listed by list_files — no normalization, no globbing). Read-only. Files over 2097152 UTF-8 bytes are refused with an error, never truncated. A BINARY file (image/PDF) returns structured metadata { kind: "binary", path, hash, size, mime } instead of text — its bytes are not available through this tool. |
| project_contextA | Returns the most RELEVANT excerpts across ALL the project's live files for a query (lexical ranking over structural chunks), each with provenance: file path, 1-based line range, and Typst heading path. Budget-limited and read-only: files with duplicate-path conflicts or over the per-file cap are skipped (listed in |
| propose_editA | Applies search/replace edits to a scratch copy of the session's file and publishes the result as a proposal. It never edits the document directly: the change is published for review — if this project has agent auto-accept armed it may apply automatically (the response says status "applied"), otherwise it awaits a human Accept in Galley. Inspect the returned |
| propose_filesA | Proposes a change set across MULTIPLE files as ONE atomic proposal — create new files, edit existing ones, rename/move them (rename also moves into a folder), or delete them (e.g. add chapters/intro.typ and #include it from main.typ). It never changes the project directly: the set is published for review — if this project has agent auto-accept armed it may apply automatically (the response says status "applied"), otherwise it awaits a human Accept in Galley. Inspect the returned |
| compileA | Type-checks the shared project and returns its diagnostics (errors/warnings + page count); never modifies the document. Uses the configured loopback compile service when one is set (--compile-url); otherwise falls back to the paired browser's live preview compiler. Call this after propose_files/propose_edit to confirm the change set type-checks before asking the human to Accept. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Tools map to distinct actions: ping, read, list, search, propose, compile. The close pairs read_document/read_file and propose_edit/propose_files are separated clearly by session-target convenience vs exact-path reads and single-file vs atomic multi-file proposals.
Most tools follow a readable snake_case verb_noun pattern (read_document, list_files, propose_edit), but project_context is a noun phrase, compile is a bare verb, and galley_ping uses a server prefix unlike the others. These are minor deviations rather than chaotic naming.
8 tools is well-scoped for a collaborative document editing server. Each tool earns its place and the count sits comfortably within the ideal 3-15 range.
The surface covers the main workflow: inspect files, search the project, propose single or multi-file changes, and compile to verify. Minor gaps like no proposal history or binary byte retrieval don't create dead ends because statuses are returned and binary pointers are provided.