NEXUS local MCP vs Chainabit cloud MCP
There are two Chainabit MCP servers, and they address different planes:
- the NEXUS local MCP server, which acts on the NEXUS app running on your machine;
- the Chainabit cloud MCP server, which acts on your Chainabit account.
Each is correct on its own. The problem only appears when both are connected at once: several tools share a name or a concept across the two, and a client that picks the wrong one gets a confident, plausible answer about the wrong thing.
The two servers at a glance
| NEXUS local MCP | Chainabit cloud MCP | |
|---|---|---|
| Acts on | The running app: windows, canvases, browser, sessions, local agents, local workspaces | The SaaS account: chains, bits, connectors, cloud agents, billing |
| Transport | The nexus-mcp stdio entry, talking to the app on your machine | POST https://<your-api-host>/api/v1/mcp over HTTPS |
| Authentication | A local, owner-only credential file written by the app | OAuth 2.0 + PKCE |
| Identity | A local agent and a local workspace | A Chainabit account and a cloud workspace |
| Works offline | Yes — everything it touches is on your machine | No |
| Docs | NEXUS MCP | Chainabit MCP Server |
The fastest way to tell them apart
Every tool description served by the NEXUS local server begins with [Local NEXUS app]. Nothing else does. If you are looking at a tool description and that marker is absent, the tool is not going to touch the running app.
The local server also serves a nexus://planes resource that states the same boundary in machine-readable form — read it once at the start of a session if you have both servers connected. See MCP Protocol § resources/list and resources/read.
Collisions to watch for
agent_create exists on both
Both servers expose a tool called agent_create, and they do different things. On the local server it requests a new agent in your local roster and an invitation into a mesh channel you are already in. On the cloud server it creates an agent record in your Chainabit account. Neither can see the other's result.
The same concept under different names
| If you mean… | Chainabit cloud | NEXUS local |
|---|---|---|
| List agents | list_agents | agent_list_peers |
| Read one agent | get_agent | agent_get |
| Change an agent | update_agent | agent_update_self (self only) |
| Wake an agent | trigger_agent | agent_trigger |
| Save a memory | memory_store | memory_add |
| Search memory | memory_search | memory_query |
| Ask about the workspace | get_workspace_info / get_workspace_context | workspace_current |
The two memory systems are separate stores. An entry written with memory_add is not searchable with memory_search, and vice versa.
Cloud tools named nexus_* — the trap
The Chainabit cloud server exposes nexus_room_join, nexus_room_say, and nexus_room_history. These are cloud tools. They carry the local product's name, but they do not touch the local NEXUS 2D Room, its agents, or anything you can see on screen.
This is the single easiest mistake to make: asked to "say something in my Nexus room", a client reaches for the tool literally called nexus_room_say and hits the cloud instead of the running app. If you mean the Room you can see in the NEXUS window, you want the local server.
Two unrelated things called "workspace"
A NEXUS workspace and a Chainabit workspace are different entities that share a word. There is no mapping between them — a local workspace identifier and a cloud workspace identifier live in separate identity spaces, and neither server can translate one into the other.
Never pass an identifier from one server to the other. It will not resolve, and if it ever appeared to, that would be a coincidence rather than a relationship.
Choosing, in one rule
If the person is talking about something they can see on screen right now — a window, a pane, a canvas, a terminal, a browser tab, the Room — they mean the local NEXUS server. If they are talking about their account — chains, bits, connectors, billing, cloud agents — they mean the Chainabit cloud server.
When you cannot tell, ask. Answering from the wrong plane produces an answer that looks right and is about something else entirely.
There is no bridge between them
Nothing proxies a call from one server to the other. This is deliberate: a bridge would need a workspace identity mapping that does not exist, and it would make the boundary harder to see at exactly the moment clients are already confusing the two planes.
Where to go next
- Tool Namespaces — the ten families the local server serves.
- MCP Tools — every local tool, in full.
- Chainabit MCP Server — the cloud server's own documentation.
- Chainabit Tools Reference — the cloud tool list.