The service handle (StandMeet as MCP server)
Parent: key-designs
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 incmd/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.