The as-MCP facade

Parent: service-handle

This page is the service handle — StandMeet as an MCP server (the outward plane), not the capability plane where our own agent consumes plugins as host — see confusables.

The master design names three orientations of the platform:

host — runs plugins
connector-owner — holds credentialed integrations
as-MCP-server — the instance itself exposed as ONE MCP endpoint so that other people's agents can consume the owner's tools

Implementation

mcphandle.registerTools (backend/internal/routes/mcphandle/server.go:173) has two sources: registerCapabilities walks OwnerMCPBindings() on the capability registry (adapter.go:36) — capabilities declare their owner-facing tools once — and registerDispatcherOps (from_dispatcher.go:45) projects every op of the outbound-convergence dispatcher into a tool via d.Attach(MCPFace()).Ops(), the ui-mcp-parity projection. The old hand-written tools_*.go AddTool registrations were deleted (none exist at 36789537d). Since 2026-09-04 (a5e1cada9) the handshake reports the instance version and ships ServerInstructions (corpus model + "call instance.upgrade_check") to the connecting agent (server.go:57).

Auth = Sigv1.

Why it matters

With entry-agnostic-agent, this facade is just "another consumer" of the same neutral boundary — the machine-readable outlet of the product (your persona as an API for agents), unified rather than built twice.


flowchart LR
  EXT["owner's AI session · someone else's agent
(external MCP clients)"] --> F
  subgraph SM["StandMeet — our box"]
    F["/mcp/* facade (Sigv1)"] --> REG["capreg OwnerMCPBindings()"]
    F --> DISP["dispatcher ops
Attach(MCPFace).Ops()"]
    REG --> T1["owner tools, aggregated"]
    DISP --> T1
  end

The facade turns the capability registry into one aggregated tool surface for external agents — declared once at the capability, served once at the endpoint.