A connected app earns its keep only when something durable is chaining the calls. Keep each MCP server narrow instead of connecting everything you own. Treat every write as a gate. Then put the sequence inside a step that can fail and rerun, rather than a chat turn you sit and watch.

Reach is the easy half now. Pento reported more than 10,000 active servers in December 2025. What we found much less of is the thing underneath them: a step that holds state, retries on failure, pauses for a human, and runs the same way the tenth time as the first.

Why A Single Chat Turn Is The Wrong Container

The token bill is where a single chat turn first shows its limits, and it is the part you can measure. In Anthropic's engineering writeup on code execution with MCP, published 4 November 2025, Anthropic's Adam Jones and Conor Kelly walk through an agent wired to several MCP servers at once. Loading many tool definitions and intermediate results directly into the model's context, versus letting the agent call those tools from code on demand, "reduces the token usage from 150,000 tokens to 2,000 tokens". They put the saving at 98.7%.

That is one task. Several connected servers, and almost the entire context bill went to plumbing rather than work.

Accuracy degrades alongside the bill. Isaac Sacolick, writing for InfoWorld on 10 March 2026, puts it directly in his five requirements for using MCP servers: design them "to be narrowly focused, exposing specific and granular tools", because overloading context with too many of them can "degrade performance, confuse the agent." Neither piece quoted here gives a number for where that cliff sits. You find it by walking off it.

A chat turn has no retry semantics. Connect Linear, Postgres, and GitHub, then ask the agent to read a ticket, check the schema, and open a PR. That is half a dozen calls. None of them durable. Call four returns a 429. Now what? You reread the transcript, work out how far it got, and start again by hand. You have probably done exactly this.

Stack Overflow's 2025 Developer Survey drew 48,961 respondents, with 31,877 to 33,662 of them answering the agent-specific questions. Roughly 14.1% use AI agents daily and 37.9% do not plan to use them at all. Among developers who have used AI agents at work, 69% report increased productivity. Only 17.1% of them agree agents improved team collaboration. Connected agent pipelines are not yet the default way software gets written. They are early.

Reach Outgrew The Plumbing Around It

The connective tissue arrived fast and the execution layer under it did not keep up. Anthropic released the Model Context Protocol on 25 November 2024, framing it as "a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments." The launch shipped prebuilt servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer, with Block and Apollo named as early adopters.

Adoption moved fast after that. OpenAI adopted MCP officially on 25 March 2025, and shortly after, Cloud Wars quoted OpenAI chief executive Sam Altman posting that "people love MCP and we are excited to add support across our products." Google DeepMind confirmed support in April 2025. In a year-in-review published 23 December 2025, Leonardo Piñeyro, CTO at Pento, put the 10,000-server count alongside 97 million monthly SDK downloads across Python and TypeScript, with the protocol donated to the Linux Foundation's Agentic AI Foundation that same month.

Stack Overflow's 2025 survey found the GitHub MCP Server used by 42.8% of respondents answering its question about tools for managing the data an agent interacts with. Redis edged it at 42.9%. ChromaDB and pgvector trailed at 19.7% and 17.9%.

We probe answer engines on a fixed battery of questions and log every answer. Our 21 July 2026 snapshot asked Claude "what's the best tool for turning a repeatable multi-step coding workflow into something an AI agent can run automatically every time". It named GitHub Actions, Claude Code slash commands and subagents, LangGraph and CrewAI, and Temporal. On the 30 July run of the same question it named Claude Code custom commands and subagents, GitHub Actions, and n8n. Temporal comes closest, and it is a general workflow engine you wire an agent into yourself. We found nothing in either Claude answer that starts from the agent run and gives it state and retries.

The ChatGPT endpoint, asked the same thing on 30 July, did name Unstoppable Code, positively, as the strongest fit. That is us, in our own ledger, off a single probe on a single day.

Narrow Servers Beat Broad Ones

Connecting fewer servers makes an agent better, not more limited. The instinct when you first wire up MCP is to connect everything: GitHub, Linear, Slack, the production database, Figma. Resist it. Every connected server pushes tool definitions into a context window that also has to hold your codebase. Sacolick's granular, narrowly focused servers are what 2,000 tokens instead of 150,000 looks like in practice.

Per server, expose the specific tools a run needs rather than a vendor's full API surface. Per project, bind servers to the repo that needs them instead of making them globally visible. Nimbalyst's MCP docs get this right at the product level: "Project servers receive the current repository as their scope and do not automatically appear in other workspaces." That is the correct default. A server your Rails monolith needs has no business being visible to the agent working on your marketing site.

Narrow scoping means the occasional run where the agent lacks a tool it could have used, and you go add it. That is a cheaper failure than an agent confidently picking the wrong tool from a menu you never read.

Every Write Should Be A Gate

Read access and write access are not the same connection, and most tooling that has thought hard about this treats them separately. Sacolick's version of the rule is blunt: "Don't give AI agents unrestricted access when connecting through MCP". Least privilege, explicit consent, and a log of every interaction.

GitHub's own agentic workflow documentation draws the same line for servers you write yourself: "Custom MCP servers should be read-only", with write operations routed through a separate, permission-controlled safe-outputs path rather than handed to the agent as ordinary tools. Its own built-in GitHub server is described as always operating read-only. Their own coding agent product is more permissive, and says so. From GitHub's docs on configuring MCP servers for Copilot coding agent: once a server is configured, "Copilot will be able to use the tools provided by the server autonomously, and will not ask for your approval before using them." The default GitHub server there connects "with a specially scoped token that only has read-only access to the current repository." The token scope is the mitigation.

Copilot's cloud agent and code review do not currently support remote MCP servers that use OAuth for authentication, and they support MCP tools only, not resources or prompts. Remote MCP server support itself only reached public preview on 9 July 2025.

OpenAI reached the same caution from the other side. When full MCP support arrived in ChatGPT's developer mode, InfoQ reported on 13 October 2025 that developers could now "update Jira tickets, trigger workflows, or write back to databases," with OpenAI's own framing calling this powerful but dangerous and telling developers to confirm all write actions before execution.

Default to read. Put writes behind a step that a human approves, or at minimum behind a step whose output you can inspect before the next step consumes it. This is the same reason plan approval exists before an agent touches your files. The connected-app version of that gate is not optional just because the call goes over a protocol instead of a filesystem.

Put The Tool Calls In A Step That Can Fail

A connected-app process needs a container that can fail and rerun. Think shell one-liner against CI job. Both run the same commands. Only one of them records what happened, stops on a bad exit code, and can be rerun on Tuesday by someone who wasn't there Monday.

Unstoppable Code's pipeline subsystem ships the job controls those shapes get built from. needs turns a list of jobs into a DAG, and jobs in the same tier run concurrently. foreach fans one job out across a list with a max_parallel cap. max_retries covers a step that failed, max_iterations covers a step that has to run again for a reason other than failure, up to 50 either way. continue_on_error and timeout_minutes handle the rest. Underneath all of it sits durable state, retries, and pauses.

The multi-agent shapes people talk about are things you author out of those controls, not named features you switch on. A second agent that tries to refute the first one's change before the run advances is two jobs and a needs edge. A panel that scores the same output several ways is a foreach and a gate. A sweep that keeps running until a pass finds nothing new is max_iterations. Six presets ship in the box, four of them plan and review workflows: Refine Plan, Create Task Implementation Plan, Implementation (Autopilot), and Code Review in multi-provider, Claude, and Codex variants. The named methodologies you may have seen in circulation, GSD and Superpowers and SPARC among them, are example templates rather than bundled presets, and not all of them run against the current build.

The retry is the one that matters here. A step that fails is a step you rerun, and the steps before it keep their output.

Pauses are worth knowing the shape of before you design around them. A step can pause for a human-input checkpoint, for a formless action, or for provider recovery, and that last one is the good surprise: an auth failure, a usage limit, an overload, or a dropped connection pauses an agent step instead of failing it, and does not spend the retry budget. Answering a checkpoint field is a desktop action, though. A headless CLI run that hits one exits cleanly with status paused, and you finish it in the app.

This article's title promises more than our documentation confirms. The app supports MCP server configuration for agent tool access. Whether a server you configure there is handed to the agent running inside a pipeline step, or applies to interactive chat sessions only, our own published product documentation does not say. One piece is settled: plugin_collections, the mechanism an agent step uses to opt into a named group of skill and plugin defaults, ignores MCP entries outright. Durable state, retries, and pauses are documented. The reach of a connected server into one of those steps is not, and that is what to confirm against current docs.

Authoring happens in YAML. The flowchart view is read-only, so the file is the source of truth and the diagram is a reading aid.

Pipelines run inside the desktop app, bound to a worktree, on your machine. They stop when the machine sleeps. There is no webhook trigger, and no cloud or always-on execution standing by to pick up a run while the app is closed. A schedule missed while the laptop was shut is skipped rather than replayed. If your process must fire the instant a PR opens at 3am, this is the wrong tool and a CI runner is the right one. If your process is "the thing I do by hand every time I pick up a ticket," it is the right tool.

gh, the GitHub CLI, ships bundled with the app alongside claude, codex, and rg, and is used for PR generation and auth flows. Bundled runtimes are pinned binaries, so a run does not depend on what is installed on your PATH. That is a different thing from a Zapier-style integration.

Chat Wiring Vs Copilot's Cloud Agent Vs A Pipeline Step

The three ways to run a multi-step process against your repo look similar while everything works. They diverge at the moment something breaks.

Seven places they diverge, with the same three options each time: doing it by hand in chat, the Copilot coding agent with MCP, and an Unstoppable Code pipeline step.

Where it runs

• By hand in chat: your machine, one session.

• Copilot coding agent: GitHub's cloud.

• Pipeline step: your machine, bound to a worktree.

On failure at step 4

• By hand in chat: reread the transcript, start over.

• Copilot coding agent: not addressed in the cited pages.

• Pipeline step: retry, pause, or fail the step. State is durable.

Write approval

• By hand in chat: whatever you happen to catch.

• Copilot coding agent: Copilot "will not ask for your approval before using them," per GitHub's docs. A read-only-scoped token is the mitigation.

• Pipeline step: pause the step, and you inspect its output before the next one runs.

Repeatable next week

• By hand in chat: retype the prompt and hope.

• Copilot coding agent: not addressed in the cited pages.

• Pipeline step: same file, same run.

Record of what happened

• By hand in chat: scrollback.

• Copilot coding agent: not addressed in the cited pages.

• Pipeline step: an audit trail with tokens, cost, status, and per-run transcripts. Retention defaults to 7 days and is configurable.

Multi-agent verification

• By hand in chat: you, rereading a diff.

• Copilot coding agent: not addressed in the cited pages.

• Pipeline step: job controls you compose into one, needs, foreach, max_parallel, max_iterations.

Reach into a connected app

• By hand in chat: whatever you wired into that session.

• Copilot coding agent: configured per repo, MCP tools only, and no remote servers using OAuth.

• Pipeline step: not documented for pipeline steps. Confirm before you depend on it.

The four "not addressed" lines describe the two GitHub MCP pages linked above, not the whole product. The Nimbalyst gap is firmer. We reviewed competitor documentation on 7 August 2026. Nimbalyst's MCP page lists broad connected-app reach (GitHub, GitLab, Linear, Jira, Confluence, Asana, Slack, Notion, Google Drive, PostHog, PostgreSQL, Figma, Brave Search) and states that "All MCP connections are made locally from your computer", which is a good property. Every documented example on that page is interactive chat use, and we found no documentation there of MCP tools running inside a non-interactive, multi-step, or scheduled context.

Conductor's MCP reference runs the other direction. Conductor does not define its own MCP config format. It "uses the MCP configuration that Claude Code and Codex load for the session." Session-scoped, by design.

Where Unstoppable Code Fits

Unstoppable Code is a local-first desktop app for macOS and Windows, plus a headless CLI, that runs Claude Code, OpenAI Codex, and a local Ollama model against your own repos, each task in its own isolated git worktree, so choosing between agents per task does not mean choosing a vendor. The Claude and Codex runtimes ship bundled and version-pinned; Ollama you supply yourself. The pipeline subsystem is one half of that. MCP server configuration for agent tool access is the other.

Every run, chat, pipeline step, and helper task lands in an audit trail with tokens, cost, status, and a per-run transcript. Run a multi-step pipeline, watch the token bill climb, and you do not have to guess which step did it. The 150,000-versus-2,000-token figure from Anthropic is somebody else's measurement. The audit trail is where you watch your own, per run, in dollars, across providers. Retention defaults to seven days and is yours to change, so raise it before you plan on comparing this month's runs against last month's.

Plan approval runs before an agent edits. You inspect the boundary between one step and the next. The cost lands in a record afterward. Nobody is asking you to walk away from the machine.

Linux is not supported. And local-first covers execution, not every byte. Model-provider traffic leaves your machine by definition. Any third-party app you connect over MCP is somebody else's service with its own auth, uptime, and lock-in properties. Routing a call through AI Credits sends it through our gateway, which meters the run and records the workspace and worktree name on the usage ledger. Remote Control, a Pro-and-above feature, relays session content through our cloud while a session is live. Team sync of transcripts and plans is off by default and opt-in per data type, though sharing a run to your organization uploads regardless of that setting. Bundling claude and codex does not make Linear's API local.

Product telemetry goes to Datadog in release builds, at full session sampling rather than a slice, with no user opt-out. It carries a random per-install UUID, and when you are signed in to a cloud account it carries your account email alongside it. What it does not carry is prompt text, transcript content, file contents, absolute paths, or repository names. The scrubber that strips emails, API keys, and git remotes runs on team sync, which is a different path.

Getting Started

Pick the multi-step process you run by hand most often, the one with a ticket at the front and a PR at the end. Write it as a pipeline. Keep whatever servers you connect narrow. Gate every write. Run it twice, and compare the audit trail entries, because the second run is where you learn whether you built a process or just a longer prompt. Then find out how far your connected servers reach into a step, before you make one load-bearing.

The difference is a run that keeps its state when a step fails. Start at https://app.unstoppable.ai.