> The only three tools your AI sees from Delta MCP: delta, delta_read and delta_apply. What each one does, and when your AI uses which. # The three tools The only three tools your AI sees from Delta MCP: delta, delta\_read and delta\_apply. What each one does, and when your AI uses which. Your AI doesn’t see the tools of your connectors one by one. Whatever you connect, Delta MCP shows it three tools. Every tool of every connector is still there: your AI calls it by name from inside a program. Your AI reads three short descriptions instead of every tool definition. What a long tool list costs when it is loaded in full: [How to reduce MCP token usage](https://www.mcpdelta.com/guides/reduce-mcp-token-usage). ## The three tools | Tool | What it does | | --- | --- | | `delta` | Runs a whole task as one program. Reads run now; changes are checked, then made together at the end. | | `delta_read` | Reads without changing anything, or plans a program’s changes without making them. | | `delta_apply` | Applies a plan that is waiting, undoes a finished task, or keeps work as a shortcut. | Your AI app may show them as “Do it”, “Read” and “Apply or undo”. Below is the description your AI reads for each tool, word for word, wrapped to fit. ``` delta: One program does the whole task; its API is the description of the code argument. Reads run now; changes are checked, then made together at the end, within the user's permissions: the minimal calls, all or nothing, read back, undoable (delta_apply { undo }). dryRun, or delta_read { code }: plan only. delta_read: Read without changing anything. refs: "" (all its tools), "." (exact types and description), "search:", "result:[.path|[a:b]]", "delta:", "services" (what is connected now; a service the user names may be new), "journal", "guide". Or code: a program whose reads run and whose changes are only planned, to be made by delta_apply { delta }. delta_apply: Apply a pending delta (dryRun, or waiting for the user's approval): { delta: "d_…" }. Undo an applied one: { undo: "d_…" }. Keep this conversation's programs that changed something as a recipe: { keep: { name, about, params } }, params: each input → the value used this time. ``` Each task gets an id like `d_…`. Activity keeps the task under it, and your AI uses it to apply or undo that task. ## When your AI uses which | Your AI wants to… | It calls | | --- | --- | | Do a task, in one step or many | `delta { code }` | | Learn a connector’s API, search for a tool, read a long result again | `delta_read { refs }` | | See what a program would change first | `delta { code, dryRun: true }` or `delta_read { code }` | | Make a plan that was waiting for you | `delta_apply { delta: "d_…" }` | | Take a task back | `delta_apply { undo: "d_…" }` | | Keep a task that worked | `keep` on `delta`, or `delta_apply { keep }` | In a mode that asks, `delta` shows you a card and returns “Waiting for the user’s approval”. Once you answer, your AI calls `delta_apply { delta }`. See [Modes](https://www.mcpdelta.com/docs/modes). ## One call for a whole task The program below is the `code` argument of one `delta` call. It reads a ticket, changes three things on it, and returns its title. ``` const t = await tickets.ticket.get ( "T-1" ); t.status = "closed" ; t.labels.push ( "late" ); t.comments.push ({ body: "Closed: fixed in 2.3" }); return t.title; ``` Delta MCP answers once. Here are the first lines, with the ids and timings left out. ``` Returned: Login broken Applied d_… · 2 call(s) · … · read back ✓ ``` Two calls, because this connector has one tool to update a ticket and another to add a comment. [Writing a task](https://www.mcpdelta.com/docs/writing-a-task) shows how Delta MCP gets there. ## Where the connectors’ tools went Each connector’s API is the description of the `code` argument of `delta`: its collections, and every tool with its arguments. Nothing is left out. A connector with hundreds of tools is named in full, and only the long signatures are shortened. `delta_read { refs: ["."] }` then gives the exact types. Apps cut a server’s instructions at a fixed length (Claude Code: 2,048 characters) but not an argument’s description. So Delta MCP keeps its instructions short and puts the API in `code`. If an app doesn’t show it, `delta_read { refs: [""] }` gives it. ## What else passes through - **Resources and prompts** of your connectors are still offered, under their own names. On a clash between two connectors, a resource becomes `mcpdelta:///` and a prompt `.`. - **What a connector asks** you, your AI’s model or your workspace (a question, a sampling request, the workspace roots) reaches your AI app as if the connector spoke to it directly. Nothing is left hanging: an app that can’t answer gives the connector an error at once. - **A connector served as documents** adds its own few tools beside these three. See [Documents](https://www.mcpdelta.com/docs/documents). ## Stable on purpose The text your AI reads stays the same from one conversation to the next, so its app can keep it in its cache. A connector that lists the same tools in another order changes nothing: known tools keep their place, new ones come after. When something changes during a conversation, the next answer carries a short note under “Since this conversation began:”. A new connector works at once, and is declared from the next conversation. In Claude Code, Delta MCP’s entry loads the three tools at once. Your AI doesn’t spend a step searching for them.