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.

The three tools

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: "<service>" (all its tools),
"<service>.<tool>" (exact types and description), "search:<words>",
"result:<id>[.path|[a:b]]", "delta:<id>", "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

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.

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 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: ["<service>.<tool>"] } then gives the exact types.

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://<service>/<uri> and a prompt <service>.<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.

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.

Updated 7 October 2026 Something missing or wrong? Open an issue