MCP and Agent Portability Across Model Providers

You pinned OpenAI for production, Anthropic for the IDE assistant, and a fine-tuned open model for batch classification. Each vendor exposes tool calling differently — schema quirks, parallel call support, streaming deltas, max tool count. Your Jira integration should not be rewritten three times because the model API changed. Agent portability is not about running the same weights everywhere. It is about not re-plumbing every capability when the model provider shifts. MCP targets that plumbing layer.

Where coupling actually lives#

Teams assume model lock-in is the API key. Operational lock-in usually sits one level up:

• Tool definitions formatted for one SDK's tools parameter shape
• Host-specific function-call parsers and retry heuristics
• Auth and logging embedded in provider sample code
• Eval replay tied to one vendor's message format

Swap providers and the "simple" migration becomes re-validating forty tool schemas, fixing enum handling edge cases, and re-tuning prompts that assumed one model's tool-selection behavior.

MCP separates capability access (stable protocol to servers) from model invocation (vendor-specific chat/completions API). The host translates MCP-discovered tools into whatever shape the active model expects — once per provider, not once per tool per provider.

The portability stack#

Think in layers:

Portability wins when layers two and three are thin and tested. If your Jira logic lives in the MCP server, switching from Provider A to B is an adapter change plus eval regression — not a connector rewrite.

Model adapter pattern in code#

Each provider adapter implements the same host interface:

interface ModelAdapter {
  name: string;
  toProviderTools(mcpTools: McpTool[]): ProviderToolDefinition[];
  parseToolCalls(response: ProviderResponse): ToolCallRequest[];
}

function openAiAdapter(mcpTools: McpTool[]): OpenAiTool[] {
  return mcpTools.map((t) => ({
    type: "function" as const,
    function: {
      name: t.name,
      description: t.description ?? "",
      parameters: t.inputSchema,
    },
  }));
}

function anthropicAdapter(mcpTools: McpTool[]): AnthropicTool[] {
  return mcpTools.map((t) => ({
    name: t.name,
    description: t.description ?? "",
    input_schema: t.inputSchema,
  }));
}

// Host core stays provider-agnostic
async function runAgentLoop(
  session: McpSession,
  model: ModelAdapter,
  allowlist: Set<string>,
) {
  const catalog = await session.listTools();
  const tools = catalog.filter((t) => allowlist.has(t.name));
  const providerTools = model.toProviderTools(tools);
  // ... invoke model, parse calls, session.callTool(name, args)
}

Tool semantics stay in MCP servers. Format translation stays in adapters. New provider = new adapter + golden evals — not N new integrations.

Multi-model platforms without integration chaos#

Model-agnostic platforms (internal "AI gateway," vendor-neutral agent builder) need:

• One MCP catalog enabled per workspace
• Per-request or per-tenant model routing — cheap model for draft, strong model for final
• Consistent tool traces regardless of which model ran the loop
• Eval suites that assert tool-selection and argument quality per adapter

Without MCP (or an equivalent standard), each routed model multiplies bespoke tool wiring. Platform teams become the bottleneck. With MCP, onboarding a new model is primarily an adapter certification exercise against the same server fixtures.

What MCP does not make portable#

Be explicit about the limits:

• Prompts and system instructions — still tuned per model family
• Context window budgets — tool definitions consume tokens; trim per model
• Parallel tool calling — adapter must respect provider capabilities
• Structured output modes — separate from MCP tool schemas
• Latency and cost — same tool fan-out, different price per provider

MCP makes capability access portable — not the full agent behavior stack.

Reducing vendor host lock-in too#

Portability cuts both ways. Engineers use IDE assistants and desktop agents from vendors who will not import your private SDK. When your enterprise capabilities are MCP servers in a catalog, those hosts connect without custom partnership integrations — subject to their allowlisting UX and your SSO.

That is strategic portability: your capabilities travel to more model surfaces, not just your model choice traveling across tools.

Playbook: onboarding a second model provider#

1. Extract MCP servers if capabilities still live inside provider-specific agent code
2. Add a second adapter behind a factory; feature-flag it per tenant
3. Shadow traffic — same prompts, both models, compare tool traces
4. Fix adapter mapping bugs before retuning prompts (most "new model is dumb" reports start here)
5. Pin production by workload — use a routing table, not a global default swap
6. Document supported providers per MCP server — some tools need schema tweaks for weaker models

Adding only an adapter without extracting servers leaves portability on paper.

Governance for multi-provider tool access#

Same MCP tool through different models can diverge in risk:

• Smaller models may hallucinate arguments more often — tighten validation at host
• External provider may log prompts — data classification per server still applies
• Rate limits differ — host throttling must be model-aware

Publish which providers are approved for which server classifications (PII, write-capable, external-only).

Token budget portability is real work#

Tool definitions ride in every model call. Provider B may accept fewer tools per request or charge more per input token. A portable host trims the MCP catalog per model:

def select_tools_for_model(
    tools: list[McpTool],
    model_id: str,
    policy: ToolPolicy,
) -> list[McpTool]:
    allowed = [t for t in tools if policy.is_allowed(t.name)]
    budget = MODEL_TOOL_BUDGETS[model_id]  # e.g. 8 tools, 4k schema tokens
    ranked = policy.rank_by_priority(allowed)
    return trim_to_token_budget(ranked, budget.max_tools, budget.max_schema_tokens)

Same MCP servers; different subsets per provider. Without ranking policy, swapping to a smaller context model silently drops critical tools or truncates schemas mid-field.

Fallback routing without reintegration#

Production platforms often keep a fallback model when the primary rate-limits or errors. If tools are provider-welded, fallback means maintaining two integration stacks under incident pressure. With MCP plus adapters, fallback is a routing-table change: same session.callTool, different ModelAdapter implementation. Runbooks should rehearse this — teams discover welded integrations during outages, not during architecture reviews.

Summary#

Agent portability across model providers fails when tool integrations are welded to one vendor SDK. MCP stabilizes the capability layer — discovery, schemas, calls — so hosts only adapt message formats per model. Multi-model platforms invest in tested adapters and shared MCP catalogs instead of N×M connector matrices. Protocol adoption does not remove eval work on model swap; it removes the integration rewrite that makes swaps prohibitively expensive.