Pillar 2 · Capabilities (they speak MCP)

Parent: key-designs

Two MCP planes — don't conflate them

StandMeet plays both MCP roles, in opposite directions:

• The capability plane — StandMeet as MCP host. Our own visitor-agent consumes MCP servers as its tools: the builtin mcp-servers/ (stdio child processes), owner-attached ext-mcp, and the not-yet-migrated in-process capabilities. Client side: mcpclient; registry: capreg. Process-local — no network auth; sandboxed builtins reach back via capsocket.
• The service handle — StandMeet as MCP server (as-MCP). The outward /mcp/* endpoint (as-mcp-facade), guarded by Sigv1, consumed by external MCP clients: the owner's own AI session pushing curated corpus (the thesis loop) and other people's agents reading the persona.

"MCP" unqualified is ambiguous here — say capability plane or service handle. Full disambiguation table (these two + eight more collisions): confusables.

The agent's hands, organized as plugins on the MCP standard (copied verbatim — no private protocol). capreg is the registry: deterministic assembly order (the system-prompt hash depends on it), EnableGate, and the exposure formula exists ∧ owner_enabled ∧ connector_deps_met ∧ role_acl ∧ quota. Five capabilities already live outside the process as standalone Go MCP servers (mcp-servers/: ask-visitor, booker, mail-sender, retrieval, summarize) loaded over stdio at compose boot, each declared by a data-only manifest (backend/capabilities/<id>/manifest.yaml, go:embed-ed — ids ask_visitor, calendar.book, corpus.retrieval, mail.send, summarize_conversation); sandboxed builtins reach host data through capsocket (one narrow unix socket per capability), whose verbs are since 2026-08-01 (5cb8d8464) ordered by name in the manifest (host_ops) and served by the inbound convergence point internal/routes/hostdesk. Around the core: mcpplugin (manifests + install discovery, Origin 3-tier trust: builtin/managed/owner), mcpclient (http — streamable with HTTP+SSE fallback — / in-process / stdio transports), the as-MCP facade (aggregate owner tools into one endpoint for other people's agents), ui:// MCP-Apps cards, and the marketplace (GitHub-backed skill discovery).

Status (2026-09-07, 36789537d): mechanism green — the monitor panel, the last placeholder, went real on 2026-09-04 (e3af33a1c; see monitor). The remaining structural work is the externalization migration. Still MustRegistered in-process: the job-loop trio (jobs / resume / applications — internal/owner/jobs/jobs.go:110-112), the skill runner, ext-mcp, openapi agent-tools and resume_read (internal/routes/capload/capreg_register.go:39-50). me / seo / codes are no longer capabilities at all — their owner ops moved to the outbound dispatcher (internal/routes/dispatcher), and the global SEO settings feature was removed on 2026-09-06 (7037a434e; SEO now follows each microsite). Goal unchanged: in-process registry → zero, with the feature floor intact.

Superseded in mechanism — everything-is-a-block (eiab), 2026-09-13 → 2026-09-18

Landed after the stamp above; the intent (externalize to MCP, floor intact) is unchanged, the vocabulary and hosting are not:

• The five builtin servers are JS blocks now, not Go. ask_visitor / calendar.book / corpus.retrieval / mail.send / summarize_conversation live under backend/blocks/*/manifest.yaml + a JS MCP server (not backend/capabilities/ Go mcp-servers/). Owner-attached ext-mcp still applies.
• Vocabulary renamed capabilities/cap* → plugin/block*: capreg → backend/internal/plugin/registry, mcpplugin → plugin.Manifest, store/config/quota → blockstore/blockconfig/blockquota, the inbound convergence hostdesk → blockdesk, capload → blockload; mcpclient moved to backend/internal/infra/.
• capsocket retired: blocks are JS and warm-bind their host socket at boot (see capsocket, itself superseded) — the per-capability narrow-verb reach-back survives in form, not in that package.
• Still in-process (accurate, path moved): the job-loop trio (jobs/resume/applications, still MustRegister) + loader fibers now register in internal/routes/blockload/register_mechanisms.go (was capload/capreg_register.go). In-process registry not yet zero.

Class diagrams (assembly side vs consumption side, complete verified members): capabilities-diagram-coverage.

Children

• capabilities-diagram-coverage — the module's class diagrams (assembly vs consumption side) + coverage checklist.
• mcp-capability-plugins — manifests, PluginSource, Origin trust tiers, exposure formula.
• skills-progressive-disclosure — skills as Agent Skills; 3-level disclosure (name → skill_use → skill_run_script).
• ui-cards — ui:// MCP-Apps cards: sandbox iframe + postMessage handshake; the NON_SANDBOX_CARDS exceptions; proposed manifest renderer field.
• capsocket — one narrow unix socket per sandboxed builtin; blast radius = a few verbs.
• feature-floor — the cross-cutting behaviors the externalization migration must not drop (its acceptance spec).
• capability-owns-quota-config-and-store — the manifest declares quota / claim_gate / config·code_config·role_config / visitor_tools / owner_tools / host_ops; capstore (own schema) + capconfig + capquota (one count, two outputs) + hostdesk execute them with no business word on the host; the acl: always trio; how a per-session Binding is assembled.

(The outward-facing pages — as-mcp-facade, ui-mcp-parity — live under service-handle, deliberately a separate node.)