- **Version tested:** v2.0.24
- **License:** MIT
- **Where custom tools run:** an MCP server process declared in `opencode.jsonc` with `codemode: false` (the route used in this test), or inside an OpenCode plugin registered via `ctx.tool.transform` (per OpenCode 2's [Build plugins docs](https://opencode.ai/v2/docs/plugins))
- **How the app reaches the same tool:** the same separate script used for Pi, a plain HTTP call to the service with no shared code with the agent's MCP connection
- **How plugins are shared:** plugins install from npm or git and are listed in `opencode.json(c)`, per OpenCode 2's [Configure plugins docs](https://opencode.ai/v2/docs/plugins)
#### Why it stands out
A new MCP server entry took effect after `opencode reload`, confirmed via `opencode mcp list` showing the new server connected.
OpenCode also produced the only unexpected model behavior in the test. On the known-version prompt, the agent reached for its own built-in web search tool before the correctly configured `release-notes_get_release_notes` tool.
The web search errored (no search capability configured in the sandbox), and OpenCode then correctly fell back to the right tool and succeeded. Registering a tool doesn't guarantee the model picks it first.
#### Limitation
OpenCode 1 plugins do not run in OpenCode 2, per OpenCode 2's [Migrate from V1 docs](https://opencode.ai/v2/docs/migrate-v1).
#### Best for
Teams that want a complete agent and plan to iterate on its config or plugins during a live session, without restarting a background service. Follow [the iii install guide](https://iii.dev/docs/install) to start the AI Agent Harness and console on your machine.
- **Versions tested:** engine 0.24.4, AI Agent Harness 1.8.44
- **License:** engine and CLI under Elastic License 2.0 (not OSI-approved); SDKs, console, and published workers under Apache 2.0
- **Where custom tools run:** a process registered via `worker-compose.yaml`
- **How the app reaches the same tool:** `iii trigger release-notes::get`, calling the identical Function the AI Agent Harness exposes to the agent. Workers are added via `iii trigger compose::add` and pinned in `worker-compose.lock`. Functions can be [registered](https://iii.dev/docs/using-iii/functions) from the Node, Python, Rust, or Go SDK
#### Why it stands out
iii was the only option of the three where the "app call" and "agent call" tests used the same Function definition rather than a second hand-written script.
Both calls appeared side by side in one trace view in the console, filterable by function name, each with its own nested span for the outbound HTTP call to the release-notes service.
The console's Traces page showed the agent's call nested inside the AI Agent Harness turn and the app's call as its own top-level trace from `iii-node`, making the full call history of that Function visible in one place.
#### Limitation
Worker code changes require an explicit `iii trigger compose::restart worker=release-notes` before the new behavior is visible. On Windows, bundle Workers need WSL2 with `/dev/kvm`.
#### Best for
Teams building an application where agents and code share tools. In Pi and OpenCode, a custom tool is something the agent connects to. In iii, it's first-class functionality.
In iii, a Function is something the application already owns, and the agent is one more caller of it. Follow [the iii install guide](https://iii.dev/docs/install) to start the AI Agent Harness and console on your machine.
## What happened when the agent and the app shared one tool
### Where the tool runs and who else can call it
The MCP route (`.pi/mcp.json`, `exposure: direct`) is what the Pi agent uses. The application couldn't reuse that connection and needed its own code path that shares zero code with the MCP server.
The underlying HTTP call is identical either way, so we wrote it once and reused it for both Pi's and OpenCode's app path.
OpenCode's agent MCP config (`opencode.jsonc`, `codemode: false`) is agent-only. The application used the identical separate script Pi's app path used, making a plain HTTP call to the service.
With iii, the Worker registers `release-notes::get` once. The AI Agent Harness's allow list exposes it to the agent, and `iii trigger` exposes the exact same Function to the application. We confirmed this in the console's trace list, where both call paths appear under the same function name: one nested inside a `harness::send` trace (worker: `harness`), the other as its own top-level trace (worker: `iii-node`).
| Case | Pi | OpenCode | iii |
| --- | --- | --- | --- |
| Agent call works | Succeeded, with a correct one-sentence summary | Succeeded, after first trying (and failing at) its own built-in web search, then producing a correct summary | Succeeded, with a correct one-sentence summary nested inside the AI Agent Harness turn's trace |
| App call works | Succeeded via the app's own separate script (HTTP 200 + JSON) | Same separate script, same result | Succeeded via `iii trigger release-notes::get`, the same Function the agent calls |
| Service stopped | Clean "unreachable" error relayed to the user, no retry | Clean "unreachable" error relayed, with an alternative offered, no retry | Agent: clean one-sentence failure explanation. App: structured `{code, message, stacktrace}` error from the CLI |
| Unknown version | Clean "no release notes for version 9.9.9" relayed, no guessing | Same, with a typo/non-existent-version explanation, no guessing | Agent: clean failure explanation. App: same structured error shape as the service-stopped case |
| Where the failure shows up | The session JSONL or its HTML export | The session view in OpenCode's paired browser UI, or the JSON event stream at call time | The console's Traces page for that call, including the specific failed or 404'd outbound HTTP request |
### What you maintain after it works
With Pi, you hand-maintain one file, `.pi/mcp.json`, plus the application's own separate script. A change to the MCP server list is picked up by `/reload` inside an active session (documented, though not directly exercised in `--print` mode, which has no session to send `/reload` into).
With OpenCode, you maintain `opencode.jsonc`, plus the same separate application script. A new MCP server entry takes effect after `opencode reload`, with no service restart.
With iii, you maintain the `worker-compose.yaml` entry plus the worker's own directory (`worker.js`, `package.json`, `iii.worker.yaml`). A code change inside the worker did not take effect until `iii trigger compose::restart worker=release-notes` was run. Querying immediately after the edit, before the restart, still returned the old behavior. With additional configuration, iii does support file-watching in worker start scripts via `tsx watch` or equivalent.
_Table tested on 2026-10-13._
| Lifecycle | Pi | OpenCode | iii |
| --- | --- | --- | --- |
| Extension code you own | One MCP config entry + the app's own script | One MCP config entry + the same app script | A worker directory (`worker.js`, `package.json`, `iii.worker.yaml`) + one `worker-compose.yaml` entry |
| Where it is configured | `.pi/mcp.json` or extension | `opencode.jsonc` or plugin | `worker-compose.yaml` |
| How a change loads | `/reload` in an active session (documented, not directly exercised in `--print` mode) | `opencode reload`, confirmed live, no service restart | `iii trigger compose::restart worker=`, confirmed required, with no automatic hot reload for worker code without a file-watching start script |
| What the last major version broke | Move to 1.0 after MCP landed in v0.99.0 (not re-tested, per maker changelog) | V1 plugins do not run in V2 (not re-tested, per maker docs) | `iii worker add` removed in engine 0.23, replaced by `compose::add` |
| How a teammate installs it | Pi package or `.pi/mcp.json` | Plugin package or `opencode.jsonc` | `worker-compose.yaml` and lock |
## Process separation and security boundaries
Separate processes don't create security boundaries. All three tools behaved the same way in both failure and success cases, regardless of process isolation. The service being a separate process changed what crashed when we stopped it (the service alone, not the agent or the AI Agent Harness), but it didn't change what any of the three tools' own code could reach.
Pi's [docs](https://pi.dev/docs/latest/security) say extensions run with the same OS permissions as Pi itself and point to a container, VM, or sandbox for real isolation.
OpenCode's [docs](https://opencode.ai/v2/docs/permissions) warn that shell commands run with the host user's own filesystem, process, and network authority.
iii's rbac-proxy Worker decides which callers may invoke which Functions, but it is not an isolation boundary. Sandbox calls and Compose bundles run in VMs, but a local Worker like the one in this test runs on the host unless configured otherwise, per the [iii Sandboxes docs](https://iii.dev/docs/creating-workers/sandboxes).
Choose where a tool lives based on reuse and failure handling, which is what this test measured, then choose isolation separately. For approval gating and how to control what a coding agent can do before it does it, see [What stops your coding agent from doing something it can't undo?](https://iii.dev/blog/what-stops-your-coding-agent-doing-something-it-cant-undo/)
## Where iii fits
You can keep Pi or OpenCode and add iii around them. [The pi worker](https://github.com/iii-hq/workers/tree/main/pi) exposes Pi as `pi::run` and [the opencode worker](https://github.com/iii-hq/workers/tree/main/opencode) exposes OpenCode as `opencode::run`, mirroring each agent's lifecycle events into iii's engine so the console traces them alongside native AI Agent Harness turns.
[The mcp worker](https://github.com/iii-hq/workers/tree/main/mcp) can expose iii Functions to MCP clients, which now include Pi and OpenCode. We describe this as a compatibility path: tools already built as iii Functions can be surfaced to agents that connect via MCP.
iii supplies the framework and routes invocations across Workers, with inference coming from the provider you connect, whether Anthropic, OpenAI, or another.
## What else to know before you choose
### Does Pi support MCP servers now?
Yes. Pi added MCP with Codemode in [v0.99.0 on September 29, 2026](https://pi.dev/changelog), and Pi 1.0 ships it. Earlier reviews, including the AI Overview for the primary search term at research time, contrasted OpenCode's built-in MCP with Pi's extension-first core. That distinction is now historical, as both ship MCP as a first-class configuration path.
### Can I embed Pi or OpenCode in my own app?
Yes, in different shapes. Pi offers a [TypeScript SDK](https://pi.dev/docs/latest/sdk) and an [RPC mode](https://pi.dev/docs/latest/rpc) over stdin and stdout. OpenCode offers a client for its background service's HTTP API, per OpenCode 2's client docs. In iii, the AI Agent Harness is itself a Worker on the same engine as your application's Workers, so the integration boundary is a Function call rather than a separate protocol.
### How do I share an extension with my team?
Pi packages bundle extensions, skills, and prompt templates from npm or git, and versions can be pinned, per Pi's [Packages docs](https://pi.dev/docs/latest/packages). OpenCode plugins [install from npm or git](https://opencode.ai/docs/plugins) and are listed in `opencode.json(c)`. iii Workers come from the registry via `compose::add` and are pinned in `worker-compose.lock`.