A smooth gradient shifting from pale white to vibrant purple

Model context protocol architecture: portable AI stacks

Accessible Learning Hub maps model context protocol architecture, reducing vendor lock-in and clarifying security, governance, testing, and operating costs.

ARTIFICIAL INTELLIGENCE & FUTURE TECHACCESSIBLE LEARNING

Sachin K Chaurasiya | Samy

10/28/20269 min read

The Death of Proprietary Function Calling: Engineering Portable Stacks with Model Context Protocol
The Death of Proprietary Function Calling: Engineering Portable Stacks with Model Context Protocol

The Core Thesis

Proprietary function calling is becoming an expensive architectural liability when it serves as the foundational integration layer between enterprise systems and AI agents. Every provider-specific tool schema, orchestration adapter, authentication workflow, and error-handling convention adds another dependency that must be maintained whenever an organization changes models or expands its agent fleet.

The Model Context Protocol (MCP) offers a different design: standardize the boundary between reasoning engines and the systems they operate, while keeping business logic, authorization, and data access under organizational control. Introduced by Anthropic in November 2024 and subsequently adopted across major AI development ecosystems, MCP uses a common protocol for exposing tools, resources, and prompts. Its growing maturity does not eliminate vendor lock-in automatically.

It relocates the architectural boundary where that lock-in must be managed. The engineering objective is therefore not to abolish function calling, but to prevent a model provider's proprietary interface from becoming the permanent foundation of enterprise infrastructure.

Structural Mechanics & System Architecture

From proprietary tool schemas to a shared execution boundary

  • Traditional function calling couples an application's reasoning layer to a provider's tool interface. A developer defines a function using the provider's expected schema, submits it with a model request, receives a structured tool call, executes the relevant backend operation, and returns the result through another provider-specific interaction.

  • This is useful inside a single application. The problem emerges when organizations repeat the integration for multiple models.

  • Consider an enterprise assistant connected to PostgreSQL, Salesforce, GitHub, an internal document repository, and a payment API. If three model providers each require bespoke integrations for five systems, the organization potentially maintains 15 provider-system integration paths. Each path introduces compatibility tests, logging conventions, authentication concerns, and failure-handling logic.

  • MCP changes the interface topology. Rather than independently integrating every reasoning engine with every system, engineers implement standardized MCP servers around business capabilities and connect compatible AI applications through MCP clients.

  • The theoretical integration surface changes from approximately P x S provider-system pairs to P + S provider adapters and system-side MCP integrations, where P is the number of provider interfaces and S is the number of backend systems. This is a model of integration complexity, not a guarantee of equivalent engineering savings: production testing, authorization, semantic mapping, and deployment still require investment.

The three-layer execution model

The reference architecture consists of three principal components. Each has a distinct responsibility.

1. Host: the orchestration and policy boundary

  • The host is the AI application coordinating user interactions, model inference, context assembly, and tool execution. It may be an IDE, an enterprise assistant, or a custom agent runtime.

  • It manages MCP clients, determines which servers are available, and mediates interactions between the reasoning engine and external capabilities. Critically, the host should enforce user consent, tool approval policies, and the limits of the agent's authority.

  • The host is not synonymous with the language model. Replacing a model should not require rewriting the application's entire data-access layer.

2. Client: the protocol adapter

  • An MCP client maintains a dedicated connection to an MCP server. It handles protocol communication, capability discovery, and request-response exchange.

  • The MCP data layer is based on JSON-RPC 2.0, with message semantics for requests, results, errors, and notifications. The protocol defines mechanisms for discovering capabilities and exposing functionality through a shared interface.

  • However, most language models do not directly consume arbitrary MCP messages. The host or provider runtime typically translates MCP-discovered tool definitions into a model-compatible representation, then maps the model's selected action back into an MCP request. That translation remains a potential source of provider-specific coupling.

3. Server: the controlled enterprise capability

The MCP server exposes capabilities without requiring the reasoning engine to understand their underlying implementation.

MCP defines three especially important primitives:

  • Tools: Executable operations such as querying customer records, creating a support ticket, or initiating an approved payment.

  • Resources: Contextual data such as database schemas, document contents, or application records.

  • Prompts: Reusable instruction templates and workflows.

An MCP server might expose search_customer_records, get_account_status, and create_support_case while interacting with PostgreSQL, an internal REST API, or a CRM through ordinary application code.

The server should not become a thin proxy with unrestricted credentials. It should implement business rules, input validation, authorization checks, and output filtering. The model requests a capability; the backend decides whether the requested operation is permissible.

Transport and deployment boundaries

MCP supports different deployment arrangements. STDIO is appropriate for locally launched server processes, while Streamable HTTP supports remote servers and shared infrastructure. These are transport choices, not different business contracts.

For an enterprise, the resulting stack can separate model inference from private enterprise systems:

  • Model → Host/Agent Runtime → MCP Client → MCP Server → Internal API or Database

A private server can remain inside a protected network while the host communicates with it through an appropriately secured channel. OpenAI's documentation, for example, describes remote MCP support in the Responses API and Secure MCP Tunnel for reaching private or local servers without exposing those servers directly to the public internet.

As of the July 28, 2026, MCP specification, the protocol has moved toward a stateless core, with changes intended to simplify scalable deployments, routing, and caching. The release also formalized an extensions framework and revised authorization guidance. Organizations adopting MCP should pin the specification and SDK versions they support, rather than assuming that an evolving standard makes all clients and servers interchangeable without qualification.

Empirical Case Analysis & Bottlenecks

The integration-debt trap

Provider-specific function calling is not inherently defective. Its failure mode is architectural overreach.

When model schemas become embedded across application services, business operations may depend on proprietary message formats, provider-specific retry logic, and undocumented assumptions about tool selection. A migration then becomes more than a model substitution. Engineers must rewrite execution adapters, select regression-test tools, and reconstruct operational guarantees.

MCP reduces repeated integration work by establishing a common capability boundary. But protocol compatibility is not semantic compatibility.

One provider may select a tool reliably when given an ambiguous request, while another may require clearer descriptions or stricter argument constraints. A tool can be discoverable through MCP yet behave differently when invoked by different models. Therefore, portable tool access does not imply portable reasoning quality.

Teams need a stable internal contract for every business operation, plus model-specific adapters where necessary. MCP standardizes communication; it does not standardize intelligence.

Security is the principal bottleneck

Connecting an agent to more systems expands its effective authority. A compromised MCP server, malicious tool description, or prompt injection contained in retrieved content can influence subsequent tool calls. An agent with access to email, files, and internal databases may become an unintended pathway for data exfiltration.

OWASP's MCP security guidance identifies risks including tool poisoning, excessive permissions, confused-deputy behavior, and supply chain compromise. These are operational risks, not theoretical objections to open protocols.

The appropriate response is not to abandon interoperability. It is to enforce the same controls expected of conventional enterprise APIs:

  • Identity: Establish which human, service, or agent initiated each operation.

  • Authorization: Apply least-privilege access at execution time, not merely when the server is installed.

  • Approval: Require confirmation for sensitive, externally visible, or irreversible operations.

  • Observability: Record the principal, tool, arguments, authorization decision, execution result, and correlation identifier.

  • Input and output controls: Validate parameters and treat retrieved content and tool descriptions as potentially untrusted.

MCP's protocol requirements and security recommendations support input validation, access controls, rate limiting, output sanitization, timeouts, and audit logging. Implementations must still build and enforce the necessary safeguards.

Latency, context and operational complexity

A standardized interface introduces its own costs. Tool discovery, remote network calls, serialization, authentication, and additional execution hops contribute to latency. Large tool catalogs also consume model context when their descriptions and schemas are included in the reasoning process.

The failure pattern is predictable: teams expose hundreds of tools, allow the model to inspect an oversized catalog, and then wonder why selection quality, token consumption, and response times deteriorate.

The solution is capability segmentation. Expose domain-specific servers, restrict available tools by user and task, cache stable metadata where supported, and avoid sending large datasets through the model when a deterministic backend query can return a compact result.

The operational trade-off is therefore explicit: MCP can reduce integration duplication, but poorly designed MCP deployments can replace connector sprawl with tool-catalog sprawl.

The Operator’s Strategic Playbook

A portable stack requires deliberate boundaries, not a wholesale rewrite. Enterprise teams should migrate incrementally and measure engineering savings against execution reliability and security risk.

The Operator’s Strategic Playbook
The Operator’s Strategic Playbook

Establish the canonical business contract first

Do not start by wrapping every existing function in an MCP server. Start by identifying operations that represent stable organizational capabilities.

For example, create_refund should express business intent, not expose a raw payment-provider API. Its contract should define required arguments, maximum permitted amounts, authorization requirements, idempotency behavior, and possible outcomes.

The MCP server can then translate this canonical operation into the payment system's native API. If the payment provider changes, the internal contract should remain stable even though the server implementation changes.

Separate read paths from write paths

Read-only operations, such as searching approved documentation, generally have a lower operational risk than writes affecting financial or customer records. They should not share an undifferentiated permission policy.

Deploy read capabilities first. Introduce write operations behind narrowly scoped credentials, explicit approval requirements where appropriate, idempotency keys, and compensating procedures for recoverable failures.

This distinction matters because a model can repeat a request, misunderstand an ambiguous instruction, or lose track of whether a previous operation succeeded. An agent runtime must not assume that a timeout means the backend transaction failed.

Treat portability as a testable property

A server working with two model providers is a starting point, not proof of production portability.

Maintain a conformance suite that exercises discovery, valid and invalid arguments, authorization failures, empty results, pagination, timeouts, and downstream service errors. Run the same task scenarios against multiple reasoning engines and compare tool selection, argument correctness, completion rates, and total latency.

The host should own model-specific adaptation. The MCP server should own domain-level execution and policy enforcement. This division prevents provider migrations from becoming backend rewrites.

Calculate the actual economics

The relevant financial measure is not the number of MCP servers deployed. It is the total cost of ownership per reliable business capability.

Track connector implementation hours, regression-testing effort, model-migration cost, infrastructure expenses, token consumption, incident frequency, and mean time to recovery. Include the cost of operating and securing protocol servers, not just the savings from avoiding duplicated connectors.

The investment case is strongest where several applications or reasoning engines need the same enterprise capabilities. A single-model application with two simple tools may not justify a dedicated MCP platform.

Second-Order Dynamics & Strategic Trajectory

Over the next 24–36 months, the most consequential change will likely be the separation of the agent market into distinct infrastructure layers.

First, enterprise capability layers will become strategic assets. Organizations will increasingly invest in stable, governed interfaces over CRM systems, data warehouses, document repositories, and internal APIs. These interfaces can survive changes in model pricing, latency, licensing, or performance. The durable competitive advantage lies less in the ability to call a tool than in the quality and governance of the capability behind it.

Second, orchestration will remain differentiated. Standardizing tool access does not make all agent runtimes equivalent. Context selection, task planning, state management, caching, human approval, and recovery after partial failure remain important engineering disciplines. MCP provides the connection standard, not a complete agent operating system.

Third, security and governance will migrate toward the capability boundary. Enterprises will have to manage tool registries, server provenance, version changes, identity, delegated permissions, and auditability. Tool catalogs will need the same discipline as API gateways and software dependencies. The July 2026 specification's changes to stateless operation and authorization illustrate that protocol maturity is an ongoing engineering process, not a one-time adoption decision.

Fourth, proprietary function calling will persist as an execution mechanism. Model providers will continue to optimize their native tool schemas and inference interfaces. The strategic change is that enterprise applications no longer need to make those interfaces their primary integration contract. Native function calling can remain inside the reasoning adapter, while MCP becomes the shared boundary for external capabilities.

The important qualification is that an open protocol does not eliminate lock-in by itself. Organizations can recreate lock-in through proprietary server extensions, provider-specific assumptions in tool descriptions, or business rules hidden inside a single orchestration platform. Portable architecture must be demonstrated through conformance tests, independent deployment boundaries, and successful substitution.

The engineering mandate is clear: make business capabilities durable, reasoning engines replaceable, and authorization enforceable outside the model. The death of proprietary function calling is not the disappearance of a useful API feature. It is the end of treating that feature as the foundation of an enterprise's entire agent infrastructure.

Frequently Asked Questions (FAQs)

Q: What is Model Context Protocol (MCP)?

  • Model Context Protocol (MCP) is an open protocol that standardizes how AI applications connect to external tools, databases, APIs, and other data sources. It enables compatible AI systems to discover and use capabilities through a common interface instead of requiring separate integrations for every model provider.

Q: How does MCP architecture reduce AI vendor lock-in?

  • MCP separates the AI reasoning engine from backend systems through a standardized client-server interface. Organizations can switch between compatible AI models without rebuilding every database, API, or tool integration. However, provider-specific orchestration logic and proprietary extensions can still create lock-in.

Q: What is the difference between MCP and function calling?

  • Function calling allows an AI model to request an action through a supported tool schema. MCP provides a standardized protocol for discovering and accessing external tools, resources, and prompts. They are complementary: an application can use a model's native function calling internally while using MCP to connect to enterprise systems.

Q: How does MCP server integration work with enterprise databases and APIs?

  • An MCP server exposes controlled capabilities that connect to enterprise databases, internal APIs, document repositories, or other services. An MCP client communicates with the server, while the host application manages model interactions and tool execution. Authentication, authorization, input validation, and audit logging should protect sensitive operations.

Q: Is Model Context Protocol secure for enterprise AI applications?

  • MCP can support secure enterprise integrations, but security depends on implementation. Organizations should enforce least-privilege access, validate tool inputs, protect credentials, require approval for sensitive actions, and maintain audit logs. MCP does not automatically prevent prompt injection, unauthorized access, or data leakage.

Q: How does MCP improve agent tooling portability?

  • MCP improves agent tooling portability by allowing compatible AI applications to access standardized capabilities across different backend systems and reasoning engines. Reusable servers reduce duplicated integration work, while conformance tests help verify compatibility. Actual portability still depends on provider adapters, tool behavior, permissions, and implementation differences.