Skip to content

[EPIC] Native MCP interface for Noosphere #69

Description

@salim4n

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions