HUB
The governed MCP surface.
One house layer between Codex and connector sprawl.
The Problem
Codex MCP settings are a flat list. That works until the surface gets broad, variable, or destructive.
- Too many raw tools weakens model selection
- Provider-branded catalogs leak implementation details
- Shared controls become fragmented across servers
The user should not have to reason about connector topology.
┌─────────────────────────────────────────────────────────────────────────┐ │ │ │ THE BASIC RELATIONSHIP │ │ │ │ MCP User │ │ ↓ chooses task + acceptable posture │ │ │ │ Codex │ │ ↓ lists tools, reasons, invokes │ │ │ │ CREATE SOMETHING Hub │ │ ↓ filters visibility, authorizes execution, traces outcomes │ │ │ │ Downstream MCP surfaces │ │ │ └─────────────────────────────────────────────────────────────────────────┘
Three actors. One governed surface.
Why the Hub Exists
The Hub turns a raw MCP inventory into a house surface.
- CREATE SOMETHING owns naming, routing, and policy
- Commodity provider plumbing stays behind the surface
- The visible tool catalog stays bounded and intentional
This is product structure, not just technical packaging.
Discovery
Large or variable surfaces move behind brokered discovery.
- search
- describe
- execute
Reason
The model performs better when it sees a smaller, more legible surface.
Governed exposure reduces tool sprawl and routing noise.
Execution Governance
The Hub should decide whether, how, and under what limits a call executes.
- Resolve actor context
- Classify route: read, write, destructive, control plane
- Evaluate authorization and access mode
- Enforce quotas, retries, and telemetry
┌─────────────────────────────────────────────────────────────────────────┐ │ │ │ PROTECTED EXECUTION PIPELINE │ │ │ │ actor context │ │ → route classification │ │ → authorization │ │ → quota / rate limit │ │ → retry / backoff │ │ → downstream execution │ │ → telemetry + trace │ │ │ │ Fail closed when context or policy input is missing. │ │ │ └─────────────────────────────────────────────────────────────────────────┘
Routing without governance is not enough.
Tenant Policy Shapes Visibility
The visible tool surface is a policy result.
- Allow or deny by server
- Allow or deny by tool prefix
- Gate aliases by tenant and OAuth approval state
- Prefer one provider, then fall back deterministically
What Codex can see is not the raw registry.
What the User Sees
The user should see one CREATE SOMETHING surface.
- Access state and entitlement in plain language
- Explicit reason codes for blocked states
- Standard connect or reconnect paths
- No dependency on upstream vendor branding
Codex gains
- Cleaner tool inventory
- Better routing quality
- Lower destructive ambiguity
- Fewer provider-specific branches
Operators gain
- Registry and bundle control
- Tenant routing
- Discovery packs
- Trace lookup and policy status
Hub in the Three-Tier Model
The Hub lives in Automation. But it is shaped by Judgment at the boundaries.
- Database: registry, state, routing, downstream systems
- Automation: Hub runtime, proxy tools, execution pipeline
- Judgment: exposure policy, route authz, user experience rules
The Claim
Policy governs exposure.
Hub governs execution.
Codex gets a surface it can reason over.