The Wrap Pattern: Commodity Integration as Invisible Infrastructure

Not all MCP integrations are created equal. The value of building an MCP server correlates inversely with how standardized the underlying operations are.

At one end of the spectrum: commodity integrations. Connecting Slack to send a message. Listing HubSpot contacts. Creating a Jira ticket. These are CRUD operations against well-documented APIs with established OAuth flows. The operations are identical regardless of who builds the MCP server.

At the other end: creation integrations. Syncing a QuickBooks general ledger to Notion with reconciliation logic. Building a scheduling system with conflict detection and template-based backfill. Implementing a construction project management layer with RFI drafting and compliance checks. These require domain expertise, custom orchestration, and the Intelligence Layer that produces outcomes.

The strategic question is not whether to build MCP servers — it is which ones deserve your creation energy.

2.1 Definition

The Wrap Pattern is an architectural approach where a first-party MCP server delegates commodity operations to a third-party vendor’s SDK internally, while presenting a unified, branded surface to the client. The vendor is invisible infrastructure — plumbing that the client never sees, never interacts with, and never depends on.

The pattern follows the same principle as the Automotive Framework’s chassis: the structural frame that holds everything together is invisible when driving. MCP is the chassis; the commodity vendor is a replaceable part bolted to it.

2.2 Architecture

The wrapped architecture has three layers:

1. Client-Facing MCP Server — Your server, your name, your mcp-core framework. This is what the client connects to. It registers tools, resources, and prompts using your naming conventions and schema definitions.
2. Bridge Layer — A thin adapter that translates between your MCP tool definitions and the vendor’s SDK. It handles tool registration (fetching vendor schemas, converting to your format), auth delegation (mapping your account model to the vendor’s), and execution (routing tool calls through the vendor’s API).
3. Vendor SDK — The commodity provider’s client library, used as an internal dependency. It handles the actual API calls, token management, and rate limiting against the upstream service.

2.3 The Key Invariant

The client never knows the vendor exists. This is not a cosmetic requirement — it is a structural invariant that preserves the creation moat. If the client interacts with the vendor directly, you have introduced a dependency that bypasses your value layer.

Your MCP server is always the server framework. The vendor is always swappable. The Intelligence Layer (Skills, Agents, domain logic) sits on top of both wrapped and custom tools identically.

When a new integration request arrives, apply these four questions in order:

1. Does it need domain-specific logic beyond CRUD? If yes → Build Custom. Domain logic is the moat. QuickBooks reconciliation, scheduling conflict detection, construction compliance — these require understanding the domain, not just calling an API.
2. Does it need Three-Tier alignment (Resources + Prompts)? If yes → Build Custom. Commodity vendors typically provide tools only. If your integration needs Resources (state exposure) or Prompts (judgment templates), you need full MCP server control.
3. Does it need two-way data synchronization? If yes → Use a sync platform. Bidirectional sync between two systems (e.g., Notion ↔ HubSpot contacts) is a specialized problem. Sync platforms solve it; commodity tool vendors do not.
4. Is it standard CRUD with managed OAuth? If yes → Wrap. This is where the wrap pattern applies. The integration is commodity plumbing that does not deserve creation energy.

The Three-Tier Framework (Database, Automation, Judgment) applies to wrapped integrations as cleanly as to custom ones. The wrap pattern does not bypass the framework — it maps the vendor’s capabilities into it.

4.1 Tier Mapping

4.2 The Bridge Components

A well-designed bridge package provides three components that map to the three tiers:

• Tool Factory (Automation) — Fetches tool definitions from the vendor, converts JSON Schema to your validation format, registers them as standard MCP tools with handlers that route execution through the vendor’s API.
• Auth Bridge (Judgment) — Implements your MCP server’s auth provider interface, delegating OAuth flows to the vendor’s managed auth. Policy enforcement (which accounts can access which tools) remains yours.
• Client Wrapper (Database) — A thin, edge-compatible wrapper over the vendor’s client SDK. Handles instantiation, health checks, and connection state. Must work in Cloudflare Workers (no Node.js builtins).

4.3 Custom + Wrapped = Unified Surface

The power of the pattern emerges when you combine wrapped commodity tools with custom deep-domain tools on the same MCP server:

• Wrapped tools handle the long tail of standard integrations
• Custom tools handle the core domain logic
• The Intelligence Layer (Skills, Agents) operates identically across both
• The client sees one unified MCP server with consistent naming and schemas

This is the subtractive move: wrapping removes the build burden for commodity integrations so creation energy focuses on the moat.

The wrap pattern is only safe if the vendor is always replaceable. This is the swappability invariant: at any point, you must be able to swap the underlying vendor without changing the client-facing MCP surface.

5.1 Structural Guarantees

• No vendor types in public API — Your bridge package exports your types, not the vendor’s. If the vendor renames a field, only the bridge adapter changes.
• MIT license or equivalent — If the vendor dies or pivots, you can fork the SDK and maintain the adapter yourself. Proprietary SDKs violate the invariant.
• Contained blast radius — The vendor dependency lives in exactly one package (the bridge). No other package in your monorepo imports the vendor directly.
• Edge compatibility — The vendor SDK must work in your deployment target (e.g., Cloudflare Workers). If it requires Node.js builtins, it fails the compatibility gate and the wrap pattern does not apply.

5.2 Evaluation Protocol

Before wrapping any vendor, run a structured evaluation:

The edge compatibility gate is non-negotiable. Everything else is negotiable within thresholds. If evaluation fails, the integration stays custom.

The wrap pattern has clear boundaries. Cross them, and the vendor stops being invisible infrastructure and becomes a visible dependency — eroding the creation moat.

6.1 Do / Do Not

6.2 The Moat Test

For every integration, ask: “If a competitor used this same vendor, would they produce the same outcome?”

• If yes → This is commodity. Wrapping is appropriate. Your differentiation comes from the Intelligence Layer on top, not the CRUD underneath.
• If no → This is creation. Build it custom. The domain logic, the orchestration, the policy enforcement — these are the moat. Wrapping would hide your value.

6.3 Criticality Boundary

Never wrap integrations that are critical path for your client’s SLA. If the vendor has downtime and your client’s workflow stops, you have a vendor dependency, not invisible infrastructure.

Critical integrations stay custom. Wrapped integrations are always nice-to-haves — the long tail of standard connectivity that makes your MCP server more useful but is not the reason the client chose you.

7.1 Build vs. Wrap Cost

The economic argument for wrapping is straightforward:

7.2 The Margin Structure

Wrapping inverts the cost structure for commodity integrations:

• Without wrapping: Each commodity integration costs days of engineering time (OAuth implementation, API mapping, error handling, rate limiting). This is undifferentiated work that competes with creation work for attention.
• With wrapping: Each commodity integration costs hours of bridge configuration plus ~$30/mo vendor cost. Creation energy redirects entirely to the Intelligence Layer — the monetizable layer.

The margin is in the Intelligence Layer, not the CRUD layer. Wrapping eliminates the CRUD tax so you can focus on where the margin lives.

8.1 Bridge Package Structure

The bridge lives in a single package with clear boundaries:

• src/client.ts — Thin wrapper over vendor SDK (edge-compatible)
• src/tool-factory.ts — Fetches vendor tools, registers as MCP tools
• src/auth-bridge.ts — Auth provider implementation + token delegation
• src/types.ts — Your types only (no vendor type re-exports)
• eval/ — Evaluation scripts (compatibility, latency, quality, auth)

8.2 Registration Flow

At server startup, the Tool Factory:

1. Fetches available tool definitions from the vendor for specified apps
2. Converts vendor JSON schemas to your validation format (e.g., Zod)
3. Registers each tool on your MCP server with a handler that routes execution through the vendor’s API
4. Applies naming conventions and description standards to match your surface

Custom tools are registered directly on the same server, using the same server.tool() API. The client cannot distinguish wrapped from custom.

8.3 Edge Deployment

The wrap pattern must work at the edge. The bridge package must:

• Use fetch exclusively (no http/https modules)
• Avoid Node.js builtins (fs, path, crypto beyond Web Crypto)
• Accept a custom fetch option for testing and instrumentation
• Handle vendor rate limits gracefully (retry with backoff)

9.1 The Subtractive Move

The wrap pattern is fundamentally a subtractive move in the sense of the Subtractive Triad:

• DRY (Implementation) — Eliminates the duplication of building the same OAuth flows, CRUD operations, and error handling that every MCP server builder implements for commodity APIs.
• Rams (Artifact) — The wrapped tool earns its existence by providing connectivity without demanding creation energy. “Weniger, aber besser” — fewer custom integrations, but the ones you build are better.
• Heidegger (System) — The wrap pattern serves the whole by keeping the vendor invisible. It prevents the disconnection that occurs when external dependencies become visible to clients, creating coupling that constrains the system’s evolution.

9.2 Zuhandenheit of Wrapped Tools

When the wrap pattern works correctly, wrapped tools recede into transparent use — Heidegger’s Zuhandenheit (ready-to-hand). The agent calls hubspot_list_contacts without knowing or caring whether that tool is implemented via custom code or a vendor bridge. The tool disappears in use.

When the pattern breaks — vendor downtime, schema mismatches, auth failures — the tool becomes Vorhandenheit (present-at-hand). It stands out as an object of concern rather than receding into function. The swappability invariant minimizes this risk: if one vendor breaks, swap in another without touching the client surface.

9.3 Gestell Warning

The temptation is to wrap everything. This is Gestell — the technological enframing that reduces all integrations to standing reserve, resources to be optimized. The wrap pattern is not a universal solution. It is a targeted tool for commodity work, applied with judgment about what deserves creation energy and what does not.

The question is not “Can we wrap this?” but “Should we wrap this?” The classification heuristic (Section 3) provides the framework for that judgment.

9.4 Limitations

• Vendor dependency — Even with the swappability invariant, switching vendors has a cost. The bridge adapter must be rewritten, and vendor-specific quirks may leak through.
• Tool quality ceiling — Wrapped tools inherit the vendor’s schema quality. If the vendor’s tool descriptions are poor, LLM function calling reliability suffers.
• Latency overhead — Wrapping adds a network hop. For latency-sensitive operations, this may be unacceptable.
• Three-Tier gap — Most commodity vendors only provide Tools (Automation tier). Resources and Prompts must still be implemented custom if needed.

MCP consumption is commoditized. MCP creation is not. The wrap pattern formalizes the strategic response to this asymmetry: delegate commodity integrations to invisible vendors, focus creation energy on deep domain logic and the Intelligence Layer.

The pattern is simple in structure (bridge package, tool factory, auth adapter) but disciplined in application (classification heuristic, swappability invariant, red lines). Applied correctly, it eliminates the CRUD tax on engineering time while preserving the creation moat.

The contribution is both strategic and architectural. Strategically, it provides a decision framework for when to build, wrap, or sync. Architecturally, it provides a reference pattern for invisible vendor integration that maintains Three-Tier alignment and edge deployment compatibility.

Key Takeaway: The wrap pattern is a subtractive move. It removes the build burden for commodity integrations — not to do less, but to focus on the work that matters. The vendor disappears. The creation moat deepens.

If you are building MCP servers for clients:

1. Classify each integration request using the four-question heuristic (Section 3)
2. For commodity integrations, evaluate potential vendors against the swappability criteria (Section 5)
3. Build the bridge package as a single, contained dependency
4. Register wrapped and custom tools on the same MCP server
5. Focus Intelligence Layer development on custom tools — that is where the margin lives

If you are evaluating commodity vendors:

1. Gate on edge compatibility first — everything else is secondary
2. Test tool schema quality (80%+ typed parameters)
3. Verify OAuth flows for your target apps
4. Benchmark latency overhead
5. Confirm MIT or equivalent licensing

If you are deciding your integration strategy:

1. Map your integrations on the commodity–creation spectrum
2. Build custom where differentiation matters
3. Wrap commodity where speed matters
4. Never wrap critical-path integrations
5. Apply the moat test: if a competitor could produce the same outcome using the same vendor, it is commodity