Unclassified

MCP Pool Multi-Environment Strategy

Status: DRAFT
Date: 2026-07-30
Related: PR #109 (Remote-Only MCP Architecture)

Architecture Overview

The MCP Pool must handle three distinct operational profiles while maintaining the frozen remote-only architecture:

┌─────────────────────────────────────────────────────────────┐
│                   IntegrateWise MCP Fabric                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌──────────────────┐  ┌──────────────────┐  ┌─────────────┐│
│  │  Customer Zero   │  │   Development    │  │   External   ││
│  │   MCP Pool       │  │   MCP Pool       │  │   MCP Pool   ││
│  │                  │  │                  │  │             ││
│  │  Full Spine      │  │  Full Spine      │  │  Subset      ││
│  │  Full ADK        │  │  Full ADK        │  │  Capabilities││
│  │  All MCPs        │  │  All MCPs        │  │  Selected    ││
│  │  Internal-only   │  │  Internal-only   │  │  Public      ││
│  └──────────────────┘  └──────────────────┘  └─────────────┘│
│           │                    │                    │        │
│           ▼                    ▼                    ▼        │
│  ┌────────────────────────────────────────────────────────┐│
│  │              Internal MCP Services                     ││
│  │  Provider Management · Integration Management          ││
│  │  Task Management · Spine (Neon + D1)                 ││
│  └────────────────────────────────────────────────────────┘│
│                                                             │
└─────────────────────────────────────────────────────────────┘

Three MCP Pool Profiles

1. Customer Zero MCP Pool (`mcp-pool-customer-zero`)

Purpose: Internal platform development and operations
Environment: Production isolation
Access: Internal only via iw-customer-zero tenant

Characteristics:

Full operational spine fabric integration
All internal MCP services (Provider, Integration, Task, Spine)
Complete ADK capability resolution
Direct Neon workbench access
Full memory and continuity integration
Complete marketplace connector access

Service Bindings:

[[services]]
binding = "PROVIDER_MANAGEMENT"
service = "integratewise-provider-management-mcp-prod"

[[services]]
binding = "INTEGRATION_MANAGEMENT"
service = "integratewise-integration-management-mcp-prod"

[[services]]
binding = "TASK_MANAGEMENT"
service = "integratewise-task-management-prod"

[[services]]
binding = "SPINE"
service = "integratewise-spine-prod"

Allowed Tenants: ["iw-customer-zero"]
Deployment: Cloudflare Workers prod environment
Resources: Isolated D1, KV, Vectorize per environment

2. Development MCP Pool (`mcp-pool-dev`)

Purpose: Parallel development environment
Environment: Development isolation
Access: Internal development teams

Characteristics:

Full operational spine fabric (development copies)
All internal MCP services (dev versions)
Complete ADK capability resolution
Development Neon workbench access
Full memory and continuity integration
Complete marketplace connector access
Hot-reload and debugging capabilities

Service Bindings:

[[services]]
binding = "PROVIDER_MANAGEMENT"
service = "integratewise-provider-management-mcp-dev"

[[services]]
binding = "INTEGRATION_MANAGEMENT"
service = "integratewise-integration-management-mcp-dev"

[[services]]
binding = "TASK_MANAGEMENT"
service = "integratewise-task-management-dev"

[[services]]
binding = "SPINE"
service = "integratewise-spine-dev"

Allowed Tenants: ["iw-dev"]
Deployment: Cloudflare Workers dev environment
Resources: Isolated D1, KV, Vectorize per environment

3. External MCP Pool (`mcp-pool-external`)

Purpose: Public-facing capabilities with governance boundaries
Environment: Production isolation
Access: External customers via marketplace connectors

Characteristics:

Subset of capabilities (19-tool semantic contract)
Selected internal MCP services only
Capability filtering based on customer tier
No direct Spine access (via gateway only)
No internal memory access (customer-scoped only)
Marketplace connector integration
Governance enforcement per customer

Service Bindings:

[[services]]
binding = "INTEGRATION_MANAGEMENT"
service = "integratewise-integration-management-mcp-prod"

[[services]]
binding = "TASK_MANAGEMENT"
service = "integratewise-task-management-prod"

# NO PROVIDER_MANAGEMENT (external customers cannot manage providers)
# NO SPINE (external customers access via gateway API only)

Allowed Tenants: ["external-*"] (wildcard for external customers)
Deployment: Cloudflare Workers prod environment
Resources: Isolated D1, KV, Vectorize per environment

Capability Exposure Matrix

Capability	Customer Zero	Development	External
Provider Management	✅ Full	✅ Full	❌ None
Integration Management	✅ Full	✅ Full	✅ Filtered
Task Management	✅ Full	✅ Full	✅ Filtered
Spine CRUD	✅ Full	✅ Full	❌ Gateway Only
Memory Access	✅ Full	✅ Full	✅ Customer-Scoped
Marketplace Connectors	✅ All	✅ All	✅ Purchased
ADK Resolution	✅ Full	✅ Full	✅ Filtered
Internal MCPs	✅ All	✅ All	✅ Selected

Deployment Architecture

Cloudflare Workers Configuration

Three separate worker deployments:

integratewise-mcp-pool-customer-zero (prod)
integratewise-mcp-pool-dev (dev)
integratewise-mcp-pool-external (prod)

Isolation Strategy

Each MCP Pool has its own:

D1 databases (separate per environment)
KV namespaces (separate per environment)
Vectorize indexes (separate per environment)
Service bindings (different target services)
Tenant access policies (different allowed tenants)

Service Binding Strategy

Customer Zero → Prod internal services
Development → Dev internal services
External → Prod services (filtered) + Gateway API

Routing Strategy

Ingress Routing

Client Configuration (Codex config.toml):

# Customer Zero
[mcp_servers.iw-mcp]
url = "https://mcp.integratewise.ai"
enabled = true
required = true

# Development (optional override)
[mcp_servers.iw-mcp-dev]
url = "https://mcp-dev.integratewise.ai"
enabled = false  # Disabled by default

# External (marketplace connectors)
[mcp_servers.iw-mcp-external]
url = "https://mcp-external.integratewise.ai"
enabled = false  # Enabled via marketplace

Tenant-Based Routing

MCP Connector routes requests based on tenant:

function routeToMCPPool(tenantId: string): string {
  if (tenantId === "iw-customer-zero") {
    return "mcp-pool-customer-zero";
  }
  if (tenantId.startsWith("iw-dev")) {
    return "mcp-pool-dev";
  }
  if (tenantId.startsWith("external-")) {
    return "mcp-pool-external";
  }
  return "mcp-pool-external"; // Default for external customers
}

Governance Integration

Customer Zero Governance

Full internal governance policies
No capability restrictions
Direct approval workflows

Development Governance

Internal development governance
Test capability restrictions
Debug and monitoring capabilities

External Governance

Customer tier-based capability restrictions
Per-customer approval workflows
Usage-based capability limits
Audit and compliance requirements

Resource Requirements

Customer Zero MCP Pool

D1: mcp-pool-customer-zero-registry
KV: mcp-pool-customer-zero-cache
Vectorize: mcp-pool-customer-zero-index

Development MCP Pool

D1: mcp-pool-dev-registry
KV: mcp-pool-dev-cache
Vectorize: mcp-pool-dev-index

External MCP Pool

D1: mcp-pool-external-registry
KV: mcp-pool-external-cache
Vectorize: mcp-pool-external-index

Implementation Steps

Phase 1: Customer Zero (Current)

✅ Complete PR #109 (remote-only architecture)
⏳ Deploy isolated MCP Pool for Customer Zero
⏳ Update Codex config for Customer Zero
⏳ Test full operational spine integration

Phase 2: Development Environment

⏳ Create dev MCP Pool deployment
⏳ Set up dev service bindings
⏳ Configure development Codex profiles
⏳ Test development workflow

Phase 3: External Profile

⏳ Create external MCP Pool deployment
⏳ Implement capability filtering
⏳ Integrate with marketplace
⏳ Test external customer access

Security Considerations

Isolation Requirements

No resource sharing between MCP Pools
Tenant-based routing enforced at MCP Connector
Capability filtering for external pool
Internal-only services protected from external access

Data Protection

Customer Zero: Full internal data access
Development: Development data isolation
External: Customer-scoped data only, no internal access

Access Control

Tenant allowlists per MCP Pool
Service binding validation at startup
Runtime capability checks on each invocation
Audit logging for all external access

Monitoring and Observability

Metrics per MCP Pool

Invocation counts per capability
Success/failure rates by tenant
Latency metrics by service binding
Resource utilization (D1, KV, Vectorize)

Logging Strategy

Customer Zero: Full debug logging
Development: Enhanced logging for debugging
External: Security-focused logging, customer isolation

Compliance and Auditing

Customer Zero

Internal audit trail
Full capability access logging
No external compliance requirements

Development

Development activity logging
Change tracking and rollback
No external compliance requirements

External

Per-customer audit trails
Capability access logging
GDPR/SOC2 compliance requirements
Data retention policies

Cost Optimization

Resource Scaling

Customer Zero: High-performance, full resources
Development: Variable resources, auto-scale
External: Tiered resources based on customer plan

Usage-Based Allocation

External customers pay for capability usage
Development environment cost allocation
Customer Zero internal cost center

Migration Strategy

From Current Architecture

Deploy Customer Zero MCP Pool (isolated)
Update Codex configuration for Customer Zero
Deploy Development MCP Pool
Implement external MCP Pool with filtering
Update MCP Connector routing logic
Deprecate old shared MCP Pool

Rollback Plan

Keep old MCP Pool available during transition
Per-tenant routing with fallback
Gradual migration of customer base
Final removal of old pool after validation

Success Criteria

Customer Zero MCP Pool

✅ Remote-only architecture (no local MCP processes)
✅ Full operational spine integration
✅ All internal MCP services connected
✅ Resource isolation verified
✅ Zero violations in audit script

Development MCP Pool

✅ Complete development environment parity
✅ Hot-reload and debugging capabilities
✅ Development resource isolation
✅ No interference with production

External MCP Pool

✅ Capability filtering working correctly
✅ Tenant-based routing functioning
✅ No internal data exposure
✅ Marketplace integration complete
✅ Compliance requirements met

Related Documents:

Architecture Overview

Three MCP Pool Profiles

1. Customer Zero MCP Pool (mcp-pool-customer-zero)

2. Development MCP Pool (mcp-pool-dev)

3. External MCP Pool (mcp-pool-external)

Capability Exposure Matrix

Deployment Architecture

Cloudflare Workers Configuration

Isolation Strategy

Service Binding Strategy

Routing Strategy

Ingress Routing

Tenant-Based Routing

Governance Integration

Customer Zero Governance

Development Governance

External Governance

Resource Requirements

Customer Zero MCP Pool

Development MCP Pool

External MCP Pool

Implementation Steps

Phase 1: Customer Zero (Current)

Phase 2: Development Environment

Phase 3: External Profile

Security Considerations

Isolation Requirements

Data Protection

Access Control

Monitoring and Observability

Metrics per MCP Pool

Logging Strategy

Compliance and Auditing

Customer Zero

Development

External

Cost Optimization

Resource Scaling

Usage-Based Allocation

Migration Strategy

From Current Architecture

Rollback Plan

Success Criteria

Customer Zero MCP Pool

Development MCP Pool

External MCP Pool

1. Customer Zero MCP Pool (`mcp-pool-customer-zero`)

2. Development MCP Pool (`mcp-pool-dev`)

3. External MCP Pool (`mcp-pool-external`)