Phase 3.5 extraction & assembly

Minimal spec-compliant MCP server process with Streamable HTTP transport (production) and stdio (dev-only), auth via AuthService.ValidateToken gRPC, zero tools registered yet.

Milestone 3.5.E.1 — MCP Server Skeleton and Transport

Status: Planned
Goal: Track E — MCP Tool Surface
Phase: 3.5 — Extraction & Context Assembly
Estimated effort: 2 days
Track: Track E — MCP Tool Surface
Depends on: Phase 3 exit


Why This Milestone Exists

Stand up a minimal, spec-compliant MCP server process that authenticates against the existing IBEX identity system and exposes zero tools yet — proving the transport, auth, and process-lifecycle plumbing work before any memory logic is added.


Transport Decision (ADR-0050)

  • Streamable HTTP as the only supported production transport (established in 2.5.G6.M1)
  • stdio for dev-convenience only, gated behind IBEX_MCP_TRANSPORT=stdio + IBEX_MCP_ALLOW_STDIO
  • Python 3.12 + official mcp SDK (modelcontextprotocol/python-sdk)
  • Expand existing services/mcp-memory/ — do not create a second MCP process

Orientation (indicative)

Named paths, package layouts, libraries, schemas, env vars, and commands anywhere on this page are rough sketches for orientation — inspiration and a baseline, not a required change list.

During implementation, expect to:

  • open the live tree and follow existing patterns before inventing new ones
  • research current constraints (latency, tenancy, deploy shape, libraries) more deeply than this page can
  • advance the design beyond the sketch where measurement or code reality says so
  • land work in different filenames, merged packages, deferred docs, or new surfaces when the situation calls for it

Prefer outcomes over matching any particular file tree or command sequence.

Areas that may be involved (situational — not a checklist):

  • MCP server surface
  • Memory service / repositories

Success signals

Outcome-oriented signals that the milestone is in good shape. Exact filenames, package layouts, and commands may differ from any sketches above.

  • Starts, responds to MCP initialize handshake over Streamable HTTP (exact path may differ)
  • Bearer token validated via real AuthService.ValidateToken gRPC call (integration test)
  • Invalid/expired/revoked token → MCP error response in JSON-RPC format
  • Zero tools registered yet — plumbing only
  • docker-compose.dev.yml entry added; health-checked
  • Repo guards / CI checks still pass

Prerequisites

  • Phase 3 exit
  • Auth service gRPC contract stable
Edit on GitHub

Last updated on

On this page

0%