The service handle (StandMeet as MCP server)

Updated · View the entry on sijie.xyz ↗

Not a pillar — the outward face. This node is deliberately separate from capabilities because the two are the easiest concepts in the system to conflate (confusables): capabilities is the capability plane — our agent consuming tools as MCP host; this node is the service handle — the /mcp/* endpoint where we are the MCP server and external MCP clients call in.

Who calls in:

  • the owner's own AI session — pushing curated corpus mid-conversation (the thesis loop's ingestion arm);
  • other people's agents — reading the persona as structured tools (the machine-readable outlet, interpretation-economy);
  • a visitor holding an access code, from their own AI client — the visitor MCP face /mcp/visitor (shipped 2026-08-23, 3ffa49015, backend/internal/routes/public/mcp_visitor.go; mounted in cmd/server/boot_http.go:150). Same code, same role/quota/billing as web chat; the tool table is filtered per code.

Auth = Sigv1 on the owner face /mcp (boot_http.go:152; the capability plane is process-local, unauthenticated by design). The visitor face swaps Sigv1 for the code itself: Authorization: Bearer <code> (mcp_visitor.go:77), because an MCP client's config can hold one static string and the code is already the product's ticket.

Children

  • as-mcp-facade — one aggregated endpoint over OwnerMCPBindings() (the third platform orientation).
  • ui-mcp-parity — landed. Whatever the admin UI can do, this handle can do: parity gate + declare-once-project-twice.

Related notes