Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 skipped with a reason), and selectionTruncated reports when relevant chunks did not fit the budget. Use read_file for a complete file.

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 status to know what happened. Each search must match the current text exactly once; failures come back as structured data (status: "edit_failed") — refine and retry.

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 status to know what happened; the whole set lands all-or-nothing. For edit ops each search must match that file's current text exactly once; failures come back as structured data — refine and retry. Delete is a recoverable soft-delete. Paths must be safe in-tree project paths (leading slash, no traversal, not under /.galley). For binary files you may either inline the bytes (create-binary, base64) or, when the source already lives on the machine running the Galley kernel, reference it by ABSOLUTE local path (create-binary-path) so no base64 transfer is needed — both publish the same content-addressed pointer. A single proposal is capped at 32 ops (with aggregate size limits); to change more files, split the work across multiple sequential propose_files calls — each is reviewed and lands independently (there is no import-group transaction spanning proposals).

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 8 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues