Goal
Expose Noosphere as a first-class remote MCP server while preserving the existing modular-monolith architecture, durable execution model, workspace isolation, deterministic policies, and provider authority rules.
The MCP surface must be an inbound adapter of the existing Noosphere application, not a second business backend.
Target architecture
MCP client
-> HTTPS /mcp
-> apps/api
-> MCP interface adapter
-> shared Noosphere application/runtime
-> application ports
-> infrastructure / durable jobs / outbox
Non-goals
- No standalone MCP microservice for v1.
- No MCP -> REST loopback calls.
- No direct Drizzle/PostgreSQL access from MCP tool handlers.
- No direct provider calls from MCP tools.
- No workspace ID supplied by the model as an authority source.
- No long-running business operation owned by an MCP HTTP connection.
- No mutable prospect/session state stored in MCP process memory.
Core principles
workspaceId, userId, current workspace role and granted MCP scopes come from authenticated server-side context.
- Effective permission = OAuth scope ∩ current workspace role ∩ deterministic business policy.
- Read tools reuse existing redaction and authorization semantics.
- Mutations reuse application use cases, idempotency and audit facilities.
- Long-running work returns durable operation/job handles.
- External effects flow through existing approval/policy/outbox/worker/reconciliation mechanisms.
- MCP transport is stateless and deploys in the existing
api container on the same VPS.
Delivery slices
Suggested implementation order
#70
-> #71
-> #72
-> #73
-> #74
-> #75
-> #76
-> #77
#73 can be developed against local/dev authentication while #72 is being completed; production remote access remains gated by OAuth.
Definition of done
A supported MCP client can authenticate to one Noosphere workspace, inspect its authorized GTM state, invoke supported internal actions, launch durable work, and safely propose governed external actions without bypassing any domain authority or tenant boundary.
Goal
Expose Noosphere as a first-class remote MCP server while preserving the existing modular-monolith architecture, durable execution model, workspace isolation, deterministic policies, and provider authority rules.
The MCP surface must be an inbound adapter of the existing Noosphere application, not a second business backend.
Target architecture
Non-goals
Core principles
workspaceId,userId, current workspace role and granted MCP scopes come from authenticated server-side context.apicontainer on the same VPS.Delivery slices
apps/apiand production routingSuggested implementation order
#73can be developed against local/dev authentication while#72is being completed; production remote access remains gated by OAuth.Definition of done
A supported MCP client can authenticate to one Noosphere workspace, inspect its authorized GTM state, invoke supported internal actions, launch durable work, and safely propose governed external actions without bypassing any domain authority or tenant boundary.