There is a five-question framework that separates AI infrastructure decisions worth defending in front of the CFO from those that will be re-platformed within eighteen months. It centres on a single open standard most boards have not yet heard of, but which Anthropic, OpenAI, Google, AWS, and Microsoft have all quietly committed to. The standard is called the Model Context Protocol, or MCP. Here is what every IT Director in Hong Kong needs to know before the next vendor pitch.
What is the Model Context Protocol (MCP) in simple terms?
The Model Context Protocol is an open standard for connecting AI systems to enterprise data, tools, and applications through a single, consistent interface. Anthropic released MCP in November 2024. It replaces the bespoke connectors every AI vendor previously built, with one universal protocol your systems speak once.
Think of it as the USB-C port for enterprise AI. Before USB-C, every device shipped a different cable. Before MCP, every AI vendor required a different integration pattern to read your CRM, query your data warehouse, or trigger an internal workflow. MCP removes that friction.
The protocol defines a standard way for an AI client (such as Claude, ChatGPT Enterprise, or an internal agent) to discover what an MCP server offers, request data from it, and execute actions through it. The server exposes your business systems. The client orchestrates the AI behaviour. The contract between them is the same regardless of which AI model is on the other end.
Why does MCP matter for enterprise AI strategy in 2026?
MCP matters because it ends the era of single-vendor lock-in for AI integrations. By Q1 2026, 78% of enterprise AI teams report at least one MCP-backed agent in production, up from 31% a year earlier, according to Anthropic's published adoption data. Forrester predicts 30% of enterprise app vendors will launch their own MCP servers in 2026.
The strategic implication is significant. Every custom integration your team built in 2023 to connect AI tools to your ERP, Salesforce, or document repository was a sunk cost tied to a specific vendor. If that vendor lost a procurement review, the integration had to be rebuilt. With MCP, the integration lives at the protocol layer. Swapping the AI model becomes a configuration change, not a re-platform.
For Hong Kong enterprises operating in regulated sectors such as financial services or healthcare, this matters even more. Vendor concentration risk has been a live conversation since the HKMA's 2023 supervisory letter on outsourcing. MCP gives you a defensible architectural answer.
How does MCP work in practice for an enterprise environment?
MCP works through three components: an MCP host (your AI application), an MCP client (the connector library inside that application), and an MCP server (the gateway your business systems expose). The host asks the client to fetch context. The client speaks MCP to the server. The server returns structured data or executes a defined action.
A practical scenario: a regional logistics firm in Kwun Tong wants Claude to answer questions about shipment status. Without MCP, the firm pays a developer to write a custom Claude integration. If the firm later wants to test the same workflow on Gemini, that integration must be rewritten. With MCP, the firm exposes its shipment database through one MCP server. Claude, Gemini, OpenAI, and any compliant internal agent can query it through identical calls.
The MCP server enforces the access boundary. It controls which fields are exposed, which actions are permitted, and which audit trail is recorded. This is the architectural layer where your governance team writes the rules once, instead of repeating them per vendor.
What enterprise problems does MCP actually solve?
MCP solves four enterprise-scale problems that have made AI projects expensive and brittle. The first is integration sprawl, where each new AI tool requires a fresh connector to the same internal systems. The second is vendor lock-in at the integration layer. The third is fragmented audit logging across multiple vendor consoles. The fourth is duplicated security policy enforcement.
According to McKinsey's 2024 State of AI report, integration cost is the single largest hidden line item in enterprise AI budgets, often consuming 40 to 60 percent of total project spend. MCP collapses that line by allowing one integration to serve every AI client your organisation deploys, present and future.
For the IT Director presenting to a CFO, this is the slide that matters. A pre-MCP architecture priced three AI vendors at three integrations. A post-MCP architecture prices three AI vendors at one integration with three configuration profiles. The five-year total cost of ownership changes shape.
What are the new risks MCP introduces for enterprises?
MCP introduces new risks that did not exist with closed, vendor-specific integrations. The most immediate is access control drift, where an MCP server exposes more capability than the business intended. The second is prompt-injection escalation, where a malicious instruction in user data convinces the AI to trigger an unsafe MCP action. The third is supply-chain risk in community-built MCP servers.
The mitigation pattern is mature, but it must be designed in from the start. Every MCP server should run with least-privilege credentials against the underlying system. Every tool exposed through MCP should be reviewed under the same change-control process you apply to any production API. Every MCP client your organisation runs should log every action with full payload to a central audit store.
The newly formed Agentic AI Foundation, under the Linux Foundation, has now taken stewardship of MCP and is publishing reference governance patterns. Your security team should be reading those references before signing the first MCP-enabled vendor contract.
How should Hong Kong IT Directors evaluate AI vendors against MCP in 2026?
Hong Kong IT Directors should evaluate every new AI vendor against five questions before signing a contract. The questions test whether the vendor will accelerate the organisation's MCP strategy or quietly entrench another integration silo that becomes a future migration cost.
The five questions are direct. First, does the product act as an MCP host, an MCP server, or both? Second, which MCP transport modes are supported, and does the vendor handle authentication consistently with the rest of the stack? Third, does the vendor publish a roadmap for MCP feature parity with their proprietary integrations? Fourth, can your team operate the vendor entirely through MCP, or does it require parallel proprietary connectors for full functionality? Fifth, what is the vendor's commitment to the Agentic AI Foundation governance roadmap?
A vendor that hesitates on any of these questions is asking you to repeat a procurement mistake the market has now standardised away from. The vendor's answer is your single best leading indicator of whether the contract is a long-term investment or a future re-platform.
What are the common pitfalls when adopting MCP in an enterprise?
The common pitfalls are predictable. The first is treating MCP as a technical decision owned by one engineering team, when it is actually an enterprise architecture decision that touches security, procurement, and data governance. The second is rushing to deploy community MCP servers without a security review. The third is allowing every team to expose its own MCP server with no central catalogue.
A Hong Kong professional services firm with 300 staff recently learned the third pitfall the hard way. Three departments each stood up an MCP server pointing at the same client database, with different scopes and inconsistent audit logging. When the firm tried to consolidate, it discovered no department could prove which AI agents had accessed which client records over the prior quarter. The remediation took longer than the original deployment.
The defensible pattern is a single internal MCP registry, owned by the IT governance function, with a documented onboarding process for every new MCP server. Every server enters production with named owners, an access control matrix, and a tested audit pipeline. Without that, MCP becomes another flavour of shadow IT.
Conclusion: MCP is now a procurement question, not a technology trend
The Model Context Protocol has moved from a clever Anthropic announcement in late 2024 to a fundamental enterprise architecture standard in less than two years. The board-level question for 2026 is not whether your organisation adopts MCP. The question is whether the AI vendors, internal platforms, and agentic systems you are procuring this year are MCP-compliant, and whether your governance framework covers the new risks that MCP-based integrations create.
The IT Directors who address this question proactively will spend the next two years extending capability. The ones who do not will spend them re-platforming. We understand AI. We understand you. With UD by your side, AI never feels cold.
Take the next step with UD
Now that you have the strategic framework, the next step is mapping your current AI vendor landscape against MCP readiness and designing the governance layer your team will need. We'll walk you through every step, from architecture review and vendor scorecards to MCP server pilot deployment, drawing on twenty-eight years of UD experience supporting Hong Kong enterprises.
