Pimp My IDE / garage dispatchBack to dispatches
Pi / MCP / tool composition / 30 SEP 2026

Pick the tool route after you draw the work.

Pi changed its mind about MCP because the work around it changed. That is the useful part. Judge a tool interface by discovery, composition, execution, and the record it leaves behind.

The reversal is the signal

Architecture should follow the workload.

Pi once rejected built-in Model Context Protocol support. Pi 0.99.0 now ships MCP and Codemode as built-in extensions. The release adds tool search, structured outputs, several exposure modes, nested tool-call records, and MCP connections over standard input or streamable HTTP.

Pi's explanation matters more than the reversal. Its team says MCP improved, but the core change happened because the work needed for MCP also helped other tools. Deferred loading, richer metadata, structured results, and a JavaScript composition environment solved a broader harness problem.

The official MCP architecture draws a narrower line. MCP defines context exchange between hosts, clients, and servers. It covers discovery, protocol messages, and transport. It does not dictate how an AI application manages the context it receives. Composition, execution policy, and retained evidence still belong to the host.

Do not ask whether MCP, a command line, or an extension is best in the abstract. Draw the task. Then choose the route with the least translation and the clearest boundary.
01 / DISCOVER

Find the right operation

Compare shell help, host APIs, and protocol discovery. Count what enters model context before work starts.

02 / COMPOSE

Join calls where they belong

A shell pipeline, extension function, or sandboxed script should reduce round trips without hiding the route.

03 / EXECUTE

Name the trust boundary

Record where orchestration runs, where each tool runs, and which credentials or files cross the seam.

04 / RETAIN

Keep a replayable record

Save tool identities, inputs, structured results, errors, and the revision that received the change.

Interactive makeover / tool composition gearbox

Shift the interface. Keep the work visible.

A normal integration picker starts with product names. This gearbox starts with one task route. The selector changes the discovery and composition path. The review checks stay independent because no interface proves its own fit.

Choose a route

Use the native shifter or the labeled detents. The selected route remains the single source of truth.

Tool interface
Route-sheet sections
0 SECTIONS SELECTEDCOMMAND LINE

Use the shell when the task already speaks in streams and files.

The command line keeps composition legible, but you still need to record versions, exit status, and changed files.

What Pi actually changed

The new part is composition, not a logo swap.

Pi's changelog says tool_search can find tools that are not declared to the model and declare them when needed. Its tool API can mark a tool as direct, model-only, Codemode-only, deferred, or hidden. It also supports output schemas and structured content. Those are controls over discovery and result shape.

Codemode adds a separate composition path. Pi describes it as model-written JavaScript running in a QuickJS sandbox that can call Pi tools. The Earendil post says this orchestration runs on the harness side and keeps its state in the session transcript. That is a specific design choice in Pi, not a property guaranteed by MCP.

MCP still leaves room for weak servers. Earendil argues that servers should return structured data and support intelligent discovery instead of dumping many text-returning tools into context. The site's HN discussion is useful as reaction, but the release note and protocol documentation carry the factual claims here.

The sheet above is a review template. Selecting all sections does not test a server, command, extension, sandbox, or replay. Fill it with the real task and exercise the failure path before standardizing the route.