Letting Claude, and other agents, drive your work: open-sourcing the Ikenga iyke MCP bridge

We published @ikenga/mcp-iyke to npm on 10 May 2026 and wrote the launch post the same afternoon. Then we never shipped the post.

It sat in draft for three months while the package kept moving — six releases, a repo migration, and a tool surface that grew from 8 to 76. So this is not an announcement. It's the post we meant to publish in May, corrected by what actually happened after.

Who "we" means here

The ideas in this project are mine. Claude did the thinking alongside me and wrote effectively all of the code, including the first draft of this post. Adaugo Ugwu and I take the last look before anything ships.

That arrangement is worth stating up front rather than disclosing in a footer, because it is half the subject. A tool that lets agents drive your work, built almost entirely by an agent, is either a good argument or a warning, and you can't evaluate which without knowing how it was made.

The shape of the problem

Most Model Context Protocol servers fetch data. They wrap a database, an API, a filesystem. The AI asks; the server answers.

Ikenga needed something different. It's a Tauri 2 desktop app — a multi-agent orchestration and workflow environment where the actual work of running a business happens. Music-industry operations is where it started and still the example we reach for first, but nothing in the shell is specific to it. Every workflow is a webview hosted in the same window. Local-first, no browser tab to lose.

Claude Desktop and ChatGPT's desktop app can already drive a computer, which is the first objection a technical reader raises and the right one to answer early. Computer use drives a desktop from the outside: it screenshots the screen and guesses at pixels. iyke makes one workspace addressable from the inside — named tools, typed arguments, a documented protocol, a real trust boundary — and it does that for any client that speaks MCP rather than for one vendor's.

Point an agent at a browser and it gets a browser. Point it at Ikenga and it gets the place the work already lives: the panes, the sessions, the state a human built up over a week.

The friction was mundane. We'd be mid-conversation and want to ask what the receivables tab was showing, or click a row and see what happened. Claude couldn't, because the app on screen wasn't anything Claude could touch. Screenshots and descriptions don't scale to working alongside someone.

MCP is the right shape for this. iyke implements it for one surface: a running Ikenga session.

What the bridge does

While Ikenga runs, it exposes a localhost HTTP server. The MCP server reads a control.json the app drops in its platform app-data directory — port, bearer token, owning PID — and talks to nothing else.

1npm install -g @ikenga/mcp-iyke
2claude mcp add iyke -s user -- iyke-mcp
Copy

Or skip the install:

1claude mcp add iyke -s user -- npx -y @ikenga/mcp-iyke
Copy

For Cursor or any other client, the generic stdio config works:

1{
2  "mcpServers": {
3    "iyke": {
4      "command": "npx",
5      "args": ["-y", "@ikenga/mcp-iyke"]
6    }
7  }
8}
Copy

The tools use underscores, not hyphens. A representative handful:

• iyke_state — current mode, focused route, full pane tree. The "where am I" answer.
• iyke_dom — accessibility-tree snapshot with Playwright-style refs. The "what's on screen" answer.
• iyke_go, iyke_click, iyke_type, iyke_key — navigation and input.
• iyke_wait — block until text appears or an element goes. The one that makes the rest reliable.
• iyke_logs, iyke_network, iyke_query_cache — console, fetches, TanStack cache.
• iyke_screenshot — visual context for the model.

stdio transport. Node 20+. macOS, Windows, Linux. Apache 2.0.

If the app isn't running, every call fails with a structured error rather than hanging. The agent reads the failure and reports it instead of waiting forever. That was deliberate, and it's the one thing we'd tell anyone building an MCP server against a local process.

Two directions, not one

Two things here sound alike and aren't, so it's worth separating them.

Outward. Ikenga can dispatch to other agents from inside. iyke_chi_run starts a run against an engine — claude-code, gemini, codex — so a session can hand work to a different model without anyone leaving the workspace.

Inward. Because iyke is an MCP server rather than a feature of one client, anything that speaks MCP over stdio can drive Ikenga: Claude Desktop, Cursor, ChatGPT's desktop app, Devin, or a client written this afternoon. None of them needs to know Ikenga exists beyond the tool list. To be exact about what we've actually done versus what the protocol allows — we've driven it from Claude Code and from a raw JSON-RPC handshake, and the rest follows from the spec rather than from our testing.

The inward direction is the one that changes the picture. This isn't one vendor's agent driving one company's tool. It's any agent client, any industry, one workspace — and the workspace, not the client, is where the state lives. Switch models and the panes, sessions and history are still there.

Ninety-seven minutes, three releases

The launch itself was a comedy of registry mechanics: 0.1.0, 0.1.1 and 0.1.2 all shipped on 10 May, inside ninety-seven minutes.

Two lessons, both still true if you're about to publish to the MCP registry.

The mcpName field has to be in the published package.json. Not the repo's copy — the one inside the npm tarball. The registry reads it to verify the npm package is owned by whoever claims the namespace. We shipped 0.1.0 without it. That cost 0.1.1.

GitHub-org namespaces are case-sensitive. io.github.Royalti-io/* is a different namespace from io.github.royalti-io/*. The match is byte-exact against the GitHub URL slug, and getting it wrong returns a confident-looking 403 that says nothing about casing. That cost 0.1.2.

One more, which cost no version but an afternoon: the registry needs your GitHub org membership to be publicly visible before it will authorise an org-namespace publish. If you flip that visibility mid-flow, log out of the publisher CLI and back in. The OAuth token caches your org list at login.

From 8 tools to 76

Here is what three months of not publishing did.

The May post listed eight tools. The version published that day, 0.1.2, registered 19 — undersold before the ink was dry. The version on npm today, 0.2.1, registers 76. The families the original never mentioned are now most of the surface: project management (6 tools), package install and trust (6), scratchpads (5), the chi agent-runner (5), todos (4), secrets (4), distributed locks (4), a KV store (4), Claude asset pinning (4), timers (3), sessions (3), and pins (3).

That growth wasn't a roadmap. Each family arrived the week it was needed. Locks and timers showed up when two agents started fighting over the same pane. Scratchpads showed up when a plan needed to outlive a chat session. Projects showed up when one workspace stopped being enough.

An MCP server against your own environment grows to the shape of your own habits. That's a feature while you're the only user and a liability the moment you aren't — a problem we now have and haven't solved.

We're not going to print all 76 here. The README has the current list, and it will be current after this post isn't.

Where the trust boundary moved

The May draft said the control surface was intentionally small — the things a human would do at a keyboard and mouse, not the things a privileged developer would do at a terminal.

That is no longer true, and we'd rather say so than leave the old line standing.

The transport claims hold. The server only ever talks to 127.0.0.1 on the port from control.json, authenticated with the token from the same file. No outbound network. No telemetry. It ships no credentials and runs nothing remotely.

The scope claim broke. iyke_chi_run starts agent runs with bypassPermissions among its modes. iyke_secret_get and iyke_secret_set read and write a vault. iyke_pkg_uninstall stops sidecars and deletes files. Those are exactly the privileged-terminal things the May draft promised were out of scope.

Which puts the honest version of this post in an awkward place, so here it is plainly. An agent wrote this server. The server hands agents a mode called bypassPermissions. The tool that widens what agents may do was built by the thing it widens it for, and the only load-bearing check on that loop is a human reading the diff before it merges.

That gate is not ceremony, and it isn't modesty either. Every part of this could run unattended today; the mechanics are finished. It doesn't because we have no way yet to make an agent's judgment about scope legible enough to approve without reading it — not its correctness, which tests cover, but its sense of what it was and wasn't invited to touch. That's a claim about the current state of the art rather than a permanent principle, and we expect it to age. At least for now, a person reads the diff.

Nothing here was smuggled in. Each tool was a deliberate call. But "small control surface" no longer describes what you grant by adding this server, and anyone deciding whether to install it deserves the real shape rather than May's.

What's still wrong with it

Three things, all of them next-release work.

The MCP registry entry is frozen. It still lists 0.1.2, still points at the repository the code left, and still reports itself as latest. Correcting it means cutting a release.

The published server reports the wrong version. It identified itself as 0.1.0 from a hardcoded string while package.json said 0.2.1. That's fixed in the source — it now reads the version at load, so it can't drift again — but the fix is unreleased. Install 0.2.1 from npm today and it still says 0.1.0.

The protocol revision is the real work. iyke negotiates up to 2025-11-25, the ceiling of the SDK it depends on. The 2026-07-28 revision retires the initialize/initialized exchange and the Mcp-Session-Id header entirely: each request now travels on its own, carrying its protocol version, client identity and capabilities in _meta, and servers that need state hand back explicit handles instead of leaning on the transport to remember. Server-to-client calls move to multi round-trip requests rather than held-open streams. Tasks leave the core for an extension; Roots, Sampling and Logging are deprecated with a twelve-month runway. It is not backward compatible in either direction.

To be precise about what that does and doesn't mean for a server like this one: stdio is not going away — the deprecated transport is legacy HTTP+SSE, also with a year-long offramp. What changes for iyke is the session model it was built on. We haven't scheduled that migration and won't pretend a date.

One item did come off this list while the post was being checked. The original standalone repo was still public and unarchived, declaring 0.1.2 while its source carried 67 of the 76 tools from the weeks it was where the work happened — anyone who cloned it got a tree that was never published. It's archived and read-only now, with a notice pointing at the monorepo.

Where it lives

• Source: Royalti-io/ikenga-pkgs/packages/mcp/iyke
• npm: @ikenga/mcp-iyke — currently 0.2.1
• License: Apache 2.0
• Issues and PRs: open

If you're building a Tauri 2 app and you want agents to use it rather than describe it back to you from screenshots, the bridge is there and the pattern transfers — to whichever client the person at the keyboard already has open. The interesting part was never that an AI can click buttons. It's that the environment where your work already lives becomes addressable, and that once it is, the surface grows toward whatever you actually do all day.

Ours grew to 76 tools in three months. Yours will grow somewhere else.

Ikenga is a multi-agent orchestration and workflow environment for businesses in any industry, built on Tauri 2. iyke is the Apache 2.0 MCP layer that lets any MCP client drive it. Written by Chinedum Okerengwor with Claude; edited by Adaugo Ugwu. Published 12 August 2026; the work described began in May.