Modern AI systems can reason well, but real work becomes messy when every external system exposes a different API, permission model, retry behavior, evidence format, and failure mode. A chat model should not need to carry that operational complexity in its prompt.

Unified MCP separates reasoning from execution mechanics. The AI decides what capability it needs. Unified MCP provides the machine-readable contract, checks the current living state, applies admission and authority rules, dispatches the provider operation, records durable state, and exposes the result back to the AI.

• One stable front door: the public MCP surface stays small even as the capability catalog grows.
• Less guessing: capabilities describe their inputs, environments, risk class, authority requirements, provider binding and evidence.
• Real execution: work is not merely suggested in prose; authorized operations can be submitted to the connected provider.
• Durable state: long or interrupted work is represented as a job that can be inspected again.
• Evidence first: provider receipts and postconditions matter more than what a chat remembers.

Unified MCP v2 deliberately exposes only six public tools. They are generic enough to support a large capability catalog without making ChatGPT carry one top-level tool for every provider operation.

The name factory here refers to the durable execution envelope used by the MCP runtime. It does not mean every request is a software Factory Build. A normal GitHub read, governed code change, Azure observation, or other provider action can travel through the same durable submission machinery.

A capability is more than an API name. Its descriptor tells the AI what the operation does, the exact target schema, the exact input schema, the operation class, maximum risk, allowed environments, whether elevated authority is required, and how the operation must be submitted.

Capabilities also carry a living state. Current Unified MCP uses states such as AVAILABLE, TRYABLE, and BLOCKED. That state can reflect current provider binding, proof sufficiency, known defects, and durable evidence rather than a static promise that something “should work.”

For example, a GitHub branch read can be AVAILABLE with current direct proof, while a different operation may remain TRYABLE because its provider binding exists but current execution proof is insufficient. A genuine known defect can make a capability BLOCKED.

One of Unified MCP v2's core accepted use cases is governed GitHub engineering across authorized Babco repositories. The v2 build established the ability to perform ordinary repository work without turning GitHub into an unrestricted write surface.

• Read repositories, files, branches, issues and pull-request state.
• Create bounded branches and update authorized files.
• Apply an atomic changeset as one governed commit with idempotent behavior.
• Evaluate PR readiness without causing a provider effect.
• Keep higher-risk actions such as workflow dispatch under separate protected authority.
• Fail closed for non-authorized repository scope rather than silently broadening access.

The result is intentionally different from handing the AI a GitHub token. Unified MCP knows the capability, the target, the risk class, the current proof, the admission rule and the authority context before provider mutation is allowed.

When Unified MCP accepts a mission, it creates a durable job identity. Operations receive provider-operation IDs, execution receipts and evidence addresses. The job can then be read back independently of the chat turn that created it.

This solves a basic AI-operability problem: a network interruption, tool timeout, application refresh or lost chat context should not force the system to pretend that nothing happened—or blindly repeat a write.

The accepted v2 architecture also includes bounded, replay-safe SQL durability behavior. Durable storage is part of execution correctness, not merely telemetry. If durable state is unavailable, sensitive execution paths fail closed instead of inventing state from memory.

Unified MCP is powerful precisely because it does not treat capability availability as permission. A capability can exist and still require elevated authority before a state-changing effect is admitted.

• Read-only work can use identity-scoped authority where the capability contract allows it.
• Writes are risk-classified and can require protected authority references.
• Environment and target scope are explicit; DEVELOPMENT authority does not silently become PRODUCTION authority.
• Protected effects remain separately gated even when lower-risk capabilities on the same provider are available.
• Real secrets stay fail-closed. Source-code text, identifiers and examples must not be confused with credentials, but actual credentials are not accepted as ordinary inline content.

Unified MCP therefore acts as an execution boundary between AI reasoning and provider effects. It does not create authority by itself, and discovery does not grant permission.

Unified MCP v2 is a real service, not logic embedded inside a ChatGPT conversation. The accepted runtime is hosted as the existing Babco Labs Azure App Service app-kvsf-factory-mcp-dev and exposes the MCP endpoint at /mcp.

ChatGPT connects to that service through the same six-tool contract used by the plugin. OAuth and Microsoft Entra provide client identity; the accepted compatibility surface preserves public PKCE and also supports the confidential-client token authentication method required by ChatGPT Business connectivity.

The design deliberately avoids a public “raw REST” escape hatch. Provider APIs can be broad internally while the AI-facing contract remains governed, typed, observable and recoverable.

Unified MCP is designed to make interruption boring. Every submission carries an idempotency identity; provider actions can record exact external operation IDs; postconditions are read back; and the durable job remains queryable.

That makes the safe recovery pattern straightforward:

This same philosophy is why Factory recovery can use repository and provider truth instead of relying on conversational memory.

The canonical Unified MCP v2 Factory workstream is TERMINAL / ACCEPTED. Its saved Build Plan is Revision 2, with an accepted decomposition of 54 nodes / 43 executable leaves and an accepted execution graph of 43 executable leaves across 8 lanes.

The terminal acceptance record proves the v2 objective: authorized Babco GitHub scope, governed ordinary writes, separate workflow-dispatch protection, atomic and idempotent changesets, no-effect readiness/preflight behavior, narrow replay-safe SQL resilience, the same endpoint and six-tool surface, provider permission across the required Babco targets, non-Babco fail-closed behavior, and preservation of historical evidence.

Later surgical repairs remain preserved on current main—covering SQL diagnostics, natural-language capability discovery, ChatGPT confidential OAuth compatibility, GitHub mutation discovery, scoped services-authority admission, and secret-detection false-positive hardening—without reopening the accepted core v2 build.

Factory recovery disposition: there is no incomplete lawful leaf in the canonical Unified MCP v2 workstream, and no accepted effect should be replayed merely for confidence.

Install or connect the Babco Labs Unified MCP v2 plugin in ChatGPT.

For most users, the simplest interaction is natural language. The AI can search the catalog, describe the best matching capability, submit the work and report the durable evidence.

Copy and paste the following prompt into ChatGPT: