العربية Get In Touch

MCP Explained: Connecting AI to Your Business Systems

October 15, 2026 4 min read By: Code Vision

An AI assistant that cannot see your orders, invoices or documents can only give general answers. Connecting every AI application to every business system by hand gets expensive quickly, and each new tool starts the work again.

The Model Context Protocol (MCP) exists to solve that. Its official documentation calls it “an open-source standard for connecting AI applications to external systems”, and compares it to a USB-C port for AI applications: one standard connection in place of many custom ones.

What MCP actually does

An AI application acts as the client, and it connects to MCP servers. Each server gives it access to data sources such as files and databases, tools such as search, and workflows such as specialised prompts. Build one server around your ERP, and any compatible AI application can use it without its own integration.

Here is a tool as a server might describe it. The description matters more than it looks, because it is what the model reads when deciding whether to call the tool.

{
  "name": "get_order_status",
  "description": "Return the status of one sales order by its order number.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_number": { "type": "string" }
    },
    "required": ["order_number"]
  }
}

Who governs it

MCP began at Anthropic. On December 9, 2025, the Linux Foundation announced the Agentic AI Foundation, with MCP among its founding contributions alongside Block’s goose and OpenAI’s AGENTS.md. Its platinum members include Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. For a business choosing what to build on, that neutral home matters: the standard does not depend on one vendor’s roadmap.

What changed in the 2026-07-28 specification

The current protocol version is 2026-07-28, and its changelog lists several changes that affect how servers are built:

  • The protocol is now stateless. The initialize handshake is gone, and every request carries its protocol version and client capabilities.
  • Protocol-level sessions are removed, along with the Mcp-Session-Id header. A server that needs state across calls uses explicit handles, passed as ordinary tool arguments.
  • Long-running tasks moved into an official extension, out of the core protocol.
  • Authorisation tightened. Clients must validate the issuer when one is present and key stored credentials by issuer, and OAuth Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents.

In practice, requests that stand on their own are easier to run behind ordinary load balancers. The changes are also not all backward compatible, so if you built on an earlier revision, read the changelog and check your SDK before upgrading.

Where to start in a real business

  1. Pick one workflow. “Answer customer questions about order status” is a project. “Connect AI to the ERP” is not.
  2. List the minimum data it needs, and leave out everything else.
  3. Wrap your existing API rather than exposing the database, so your current business rules still apply.
  4. Begin read-only. Lookups and document search carry far less risk than actions.
  5. Log every call, with who asked, which tool ran and what came back.
  6. Add write actions last, each with a confirmation step.

The security rules to follow from day one

An MCP server can become a direct path into your core systems, so its security best practices deserve a careful read before launch. Three stand out:

  • No token passthrough. The specification is explicit: “MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.”
  • Least-privilege scopes. Start with a minimal scope set and elevate only when needed. Wildcard or all-access scopes are listed as a common mistake.
  • Care with local servers. Before a one-click install, the client must show the exact command and get explicit approval. Running servers in a sandbox with minimal privileges is also recommended.

Whatever a tool returns should also be treated as untrusted input, because the model reads it. Our article on prompt injection explains why.

When you do not need MCP

If one application talks to one API, a direct integration is simpler and has fewer moving parts. MCP pays off when several AI applications need the same systems, or when one assistant needs many tools. Choose it because it removes work, not because it is new.

Want AI that works with the systems you already run? See our AI automation service, or tell us about your workflow.

Sources