AI, MCP, and API surfaces for the command tower
OpenVibeCoding is the command tower for AI engineering. This page is not the top-level product story; it is the secondary technical map that shows which AI-facing, MCP-facing, and API-facing surfaces already exist for Codex and Claude Code workflows.
Current boundary: these surfaces are not a hosted operator product, the shipped MCP node remains read-only, and the frontend packages remain a thin client + contract + shared substrate layer instead of a full SDK platform.
1. Explain-only AI operator copilot
OpenVibeCoding already exposes a bounded AI operator brief on the workflow path instead of an unbounded floating chat box. Today it shows up in three major places:
- Flight Plan preview: a pre-run advisory brief before execution starts
- Workflow copilot: a workflow-scoped explainer over queue posture, latest run context, and next action
- Run / compare brief: a run-scoped explainer over deltas, proof, incident context, and next operator step
The detailed operator-copilot architecture stays repo-internal. This public page intentionally summarizes only the bounded public contract.
2. Read-only MCP surface
OpenVibeCoding ships a real read-only MCP node for control-plane reads. The current public contract is:
- inspect runs, workflow cases, queue posture, approvals, compare, proof, and incident summaries
- return structured JSON for agent/tool consumption
- do not mutate queue items, approvals, provider state, or workflow truth
This keeps MCP useful for external inspection while staying honest about the current boundary.
If you want the shortest MCP-specific map, go straight to the read-only MCP quickstart.
3. Frontend API and contract entrypoints
OpenVibeCoding also exposes a thin builder edge for frontend consumers that want the same routes and contracts the dashboard and desktop use today.
@openvibecoding/frontend-api-client: thin JS/TS client helpers for runs, Workflow Cases, approvals, and command-tower reads@openvibecoding/frontend-api-contract: contract-facing route/query names and generated frontend-safe types@openvibecoding/frontend-shared: shared copy, locale, and status-presentation substrate for dashboard and desktop, kept workspace-only today
For the public machine-facing HTTP summary, use the API and contract quickstart instead of raw internal contract files.
If you want the shortest API-oriented map, use the API and contract quickstart.
4. What we can say truthfully
- Codex: OpenVibeCoding is positioned for Codex workflows as an operator control plane, not as an official Codex product.
- Claude Code: OpenVibeCoding is positioned for Claude Code workflows as the same governed command-tower path, not as an Anthropic-managed surface.
- MCP: the current protocol story is real, but it is read-only only.
- API / builder layer: current packages are useful integration entrypoints, but they are not yet a full SDK platform.
- Queue pilot groundwork: repo-owned HTTP queue preview/cancel plus a confirm-gated, default-off queue-only MCP pilot server can exist internally without changing the public “read-only MCP” contract.
4.5. Integration and skills adoption
If your real question is “How do I plug this into a coding-agent team workflow without making fake plugin claims?”, use the compatibility matrix, the integration guide and the skills quickstart.
- Compatibility matrix: the fastest “which ladder fits my stack?” answer across agents, skills, builders, proof-first cases, and MCP.
- Integration guide: the truthful map for Codex, Claude Code, and OpenClaw usage.
- Skills quickstart: repo-owned playbooks and adoption guidance for repeatable agent behavior.
5. What stays explicitly out of scope
- no hosted operator login surface
- no write-capable MCP claim
- no claim that queue pilot groundwork means general agent-safe mutation is already live
- no official partnership implication with OpenAI or Anthropic
- no claim that the current packages replace the orchestration runtime