MCP Explained: What Model Context Protocol Means for Your Business

A Jeddah retailer we scoped a project for had already been burned once. They had paid another agency to connect a chatbot to their inventory system, then watched that integration become dead weight the moment they wanted to try a different AI vendor six months later. Nobody had explained that the connector they paid for was built to talk to one specific tool, not to their inventory system in any general sense. They had bought a dead end and called it an integration.

That is precisely the problem MCP was built to solve, and it is worth twenty minutes to actually understand before your next AI project starts.

We hear a version of that retailer's story from almost every new client who has already tried an AI project once. It is rarely that the AI itself failed. It is that the integration work, the unglamorous part that actually connects the agent to real data, was built in a way that only served the tool that was fashionable at the time. Understanding MCP is what lets you ask the one question that would have saved that Jeddah retailer real money: "is this connector reusable, or is it welded to your product?"

MCP explained in plain terms

Think of it the way you think of USB-C. Before USB-C, every device had its own cable, and a new phone meant a new charger. USB-C did not make any single device better; it made every device speak the same connector, so the cable stopped being the thing you had to worry about. The Model Context Protocol does that for AI agents: it defines a standard way for an agent to read from and act on an external system, a database, an ERP, a CRM, a messaging platform, so that connector works regardless of which AI vendor is on the other end.

MCP was originated by Anthropic and has grown to 200 or more server implementations across the wider ecosystem, and it functions as a genuine portability layer between agent frameworks from different companies, including both Claude's and OpenAI's SDKs (nomadx.ae).

That last part is the detail that surprises most business owners. A protocol invented by one AI company becoming the standard other companies build on top of is not how software companies usually behave, and it happened here because the alternative, every vendor shipping an incompatible connector standard, would have slowed the entire AI integration market down for everyone, including the companies that might otherwise have wanted to keep customers locked in.

Why it stops vendor lock-in for AI integrations

Build a connector to your ERP as a plain, ad-hoc integration tied to one chatbot product, and switching AI vendors later means rebuilding it. Build the same connector as an MCP server, and switching vendors becomes a configuration change: point a different agent at the same server. That difference alone is worth more to a growing business than any single feature of any single AI product, because it protects the money you already spent.

Think about how many software decisions you have made in the last three years that you would make differently today. Whichever AI vendor looks best in October 2026 will very likely not be the best choice in October 2028, and a business that built its integrations on MCP gets to make that switch on its own schedule, for its own reasons, instead of being stuck with a two-year-old decision because unwinding it costs as much as the original project did.

MCP servers for ERP, CRM and WhatsApp: what we build

This is the connective tissue behind most of what we build inside our AI agents and automation service, including the kind of retrieval setup covered in our RAG knowledge base chatbot guide. In practice, three kinds of MCP servers cover most of what a Gulf SME asks for:

• ERP connectors, most often for Odoo given how strong its adoption is across the UAE and KSA, letting an agent check stock, create a purchase order, or pull a financial report on request.
• CRM connectors, giving an agent read and write access to leads, deals and customer history, scoped to exactly the operations a support or sales agent needs.
• WhatsApp connectors, since that is where Gulf customers actually message a business, letting an agent answer, qualify and hand off through the channel with the highest response rates in the region.

Noon runs personalisation and data at real volume across a Gulf retail operation; the same connector discipline behind that kind of scale is what a single, well-built MCP server needs from day one, not just at year three.

MCP vs A2A

The two protocols solve different problems and people conflate them constantly. MCP connects one agent to your data and systems. A2A, Agent2Agent, connects multiple agents from different vendors to each other, and now sits under the Linux Foundation with 50 or more partner organisations including Salesforce and SAP (Wikipedia).

If the connectors themselves are the bottleneck, the agent doing the actual coding work behind them matters too; see our take on Claude Code, Codex and Cursor for what that changes about delivery speed. For nearly every business reading this, MCP is the one that matters this quarter. A2A becomes relevant when you are dealing with multiple large vendors coordinating on a single tender, which is a different and later conversation, usually one your fractional CTO or IT consultant should be leading rather than a single vendor pitching their own protocol preference.

Security considerations

An MCP server is a door into your system, and it deserves exactly the same discipline as any other API: scoped permissions so the agent can only touch what its task requires, authentication that is not an afterthought, and logging of every call the agent makes through it. The fact that an AI agent is the one calling the door does not make the door less sensitive, and treating it as a special, lower-scrutiny case is how integrations go wrong.

There is a specific failure pattern worth naming: a connector built with broad, unscoped permissions because it was faster to build that way, then left in place because narrowing it down later felt like unnecessary work. That shortcut is exactly the kind of gap a determined attacker, or a poorly reviewed skill from an open marketplace, will eventually find. Scoping permissions correctly the first time costs a small amount of extra planning up front and saves a much larger amount of cleanup later.

A first MCP project

The right first project is narrow: one system, a handful of operations an agent genuinely needs, built and tested against real data before anything customer-facing depends on it. That is the shape of our AI Agent Pilot, four weeks to one working agent in production on your own data, connected through MCP so the integration outlives whichever specific AI tool is fashionable next year.

Resist the urge to scope the first MCP server around everything the agent might eventually need. A server that reads stock levels and creates draft purchase orders is a useful, shippable four-week project. A server that tries to touch every module of your ERP on day one is a six-month project that risks never shipping at all, and the narrower version teaches your team exactly what the wider version should look like once you have real usage to learn from.