Turnpack
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TURNPACK_LOG | No | Log which Turnpack tools your agent calls. | |
| TURNPACK_ROOT | No | Pin the workspace root to a specific project folder. If unset, Turnpack uses the folders your app reports over MCP roots, then CLAUDE_PROJECT_DIR when the client is Claude, then the directory the server started in. | |
| TURNPACK_ALLOW_EXEC | No | Set to 1 to enable ctx.exec in batch scripts, turning off the read-only promise. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Turnpack folds multi-step file work into single calls.
Need 2+ files, or a search plus the code around what it finds? Call
packonce (query + context + files + globs + git_status together) instead of separate read/search calls.Changing 2+ files, or making any change that must pass a test or typecheck? Call
shiponce with every edit (search/replaceedits, or onepatchin apply_patch or unified-diff format) and averifycommand. If verify fails, all files are restored automatically and you get the failing output: fix the edit and ship again.Need a fact about many files (counts, outlines, which files match)? Call
batchwith a short script and return only the summary. For one small edit to a file you already have open, your normal edit tool is fine. This project's check:pnpm test(from package.json). Use it as ship's verify.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| packA | Read and search the project in ONE call instead of several: a regex search (with the lines around each hit if you ask), any number of files (whole, a line range, or one function), glob listings and git status together. Use it whenever you need 2+ files, or a search plus what it finds. Output is size-capped; .env files and keys are redacted. |
| shipA | Edit files and run the tests in ONE call. Applies search/replace edits or a patch, new files, moves and deletes across any number of files, then runs your verify command(s). If verify fails, every file is restored byte-for-byte and you get the failing output. If an edit cannot be applied, nothing is written and the reply shows the nearest text. Prefer it over separate edit calls (or apply_patch) plus a test run whenever a change spans files or must pass a check. |
| batchA | Run a short read-only JS script over the repo to answer a question that would otherwise take many reads (count usages, outline every file, filter files by content). The script gets ctx.files(glob), ctx.read(path, start, end), ctx.outline(path), await ctx.grep(pattern), await ctx.gitStatus(). Return a compact summary, not raw file contents. It cannot write files or run commands. |
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 3 tools
ship is clearly distinct (writes + verify with rollback), but pack and batch both read/search the repo — pack does regex search plus files/glob/git status, while batch does ctx.grep/ctx.read/ctx.outline/ctx.gitStatus. The descriptions offer heuristics ('2+ files' vs 'a question that would take many reads'), but the boundary between a multi-file read and a scripted read is fuzzy and an agent could easily pick either.
All three names are single lowercase words in a consistent, terse style with no case or separator mixing. The only weakness is that the words are metaphors (pack/ship/batch) that don't encode read vs. write vs. script, so the pattern is consistent but not self-describing.
Three tools is minimal but each is a deliberate composite covering a real workflow (read-many, write-and-verify, scripted analysis), so nothing feels redundant or padded. The count is slightly thin, since some actions only exist as sub-operations of a larger tool.
Reading, editing, file creation/move/delete, and running verification commands are covered, which handles core edit loops. Notable gaps remain: no standalone command execution (without an edit), no diff or log inspection beyond git status, and no git commit/branch/stage operations, which will force agents to leave the server for common repo tasks.