Integrating LLMs into Your Existing Software: A Complete Guide to Model Context Protocol (MCP)

You have a working CRM, an ERP, a proprietary database built over the last decade, and now your leadership wants an AI assistant that can answer questions about it. The obvious path — write a custom API wrapper for each tool — quickly becomes untenable. A real enterprise might have 10 internal systems and 5 different AI agents (Claude, ChatGPT, a custom fine-tuned model, a RAG pipeline, an autonomous workflow agent). That is 50 custom connectors to build, maintain, version, debug and secure. One API change in your CRM breaks five integrations simultaneously. This is the N×M problem, and it is the reason most enterprise AI projects stall at the proof-of-concept stage.

The good news: a standard now exists that collapses this N×M problem into N+M. Build one MCP server per data source, and any compatible AI client can consume it. That standard is the Model Context Protocol.

What Is Model Context Protocol (MCP)?

Model Context Protocol (MCP) is an open-source standard introduced by Anthropic in late 2024 and widely adopted across the AI ecosystem by 2026. It defines a universal communication protocol between AI agents (clients) and the systems that hold data or execute actions (servers). Think of it as the USB-C of AI integration: one standardised connector that works across every device in your ecosystem, regardless of who made it.

Before MCP, every AI provider had its own way of connecting to external data — OpenAI had function calling, other providers had plugins, and custom LLM pipelines had their own ad-hoc formats. MCP standardises all of that. You write an MCP server once for your Salesforce CRM, and every MCP-compatible AI client — Claude, a custom agent, an enterprise chatbot — can immediately consume it without additional configuration.

Under the hood, MCP uses JSON-RPC 2.0 as its wire protocol. An MCP server exposes a defined set of capabilities — Resources, Tools and Prompts — and AI clients discover those capabilities at runtime through a standard handshake. The server can run locally over standard I/O (ideal for desktop agent workflows) or remotely over HTTP with Server-Sent Events (ideal for enterprise web APIs).

The Three Pillars of MCP

Every MCP server exposes some combination of three core primitives. Understanding these is essential before you start building — they map directly to the three distinct things an AI agent might need to do with your internal systems.

1. Resources — Data the AI Can Read

Resources are read-only data endpoints. They allow an AI agent to fetch structured or unstructured data from your systems — a user's profile, a list of open Jira tickets, a CRM account record, a document from Google Drive, or a row from your proprietary PostgreSQL database. Resources are safe operations: they have no side effects and cannot modify state. This makes them the appropriate primitive for AI assistants that need to answer questions about your data without being allowed to change it.

Resources are identified by URI templates. For example, your CRM MCP server might expose a resource like `crm://accounts/{account_id}` — an AI agent can fetch that URI and receive the full account object as structured JSON. You control which fields are returned, which accounts the authenticated user can access, and how the data is serialised for the AI.

2. Tools — Actions the AI Can Take

Tools are functions with side effects — they allow the AI agent to actually do things in your systems: create a Jira ticket, send a customer email, update a database record, trigger a workflow in your ERP. Tools are the most powerful and therefore the most carefully governed primitive in MCP. Unlike Resources, a Tool invocation changes state, so you must apply the same authorisation rules you would to any human-initiated action in your system.

Each Tool has a name, a description (which the AI uses to decide when to call it), and a JSON Schema defining its input parameters and return type. The AI agent presents tool calls as structured JSON that your MCP server validates before execution — you have full control over what happens at the server layer, and you can reject any tool call that would violate your business rules.

3. Prompts — Reusable Templates for Complex Tasks

Prompts are pre-built instruction templates that your MCP server exposes to AI clients. They encode domain expertise and workflow knowledge that would otherwise have to be re-explained to the AI in every conversation. For example, your HR MCP server might expose a Prompt called `analyse-performance-review` that provides structured instructions for how the AI should interpret data from your performance management system — which fields to prioritise, which edge cases to handle, which tone to use in summaries.

Prompts are not required for a minimal MCP implementation, but they are the difference between an AI integration that needs constant hand-holding and one that autonomous agents can use reliably without constant human review.

WebMCP: Browser-Native AI Integration in 2026

While the core MCP specification handles server-to-agent communication, a newer development in 2026 brings MCP capabilities directly into the browser. WebMCP allows websites and web applications to expose their functionality to AI agents without requiring a separate backend API — using simple HTML attributes that browsers like Chrome can interpret natively.

The practical implication is significant for enterprise web applications. A web portal that previously required custom API work to become AI-accessible can now declare its capabilities in HTML, and any AI agent running in the browser or through an authorised extension can discover and use those capabilities automatically. This is analogous to how semantic HTML allowed screen readers to understand web content without custom integrations — WebMCP does the same for AI agents.

For engineering teams, WebMCP is not a replacement for a full MCP server when connecting to databases or proprietary backend systems. It is a complementary layer for the browser-facing tier of your application — making your existing web UI consumable by AI agents without forcing a full API redesign. The two approaches compose naturally: your backend data lives behind a properly secured MCP server, while your frontend interactions are accelerated by WebMCP declarations.

Security and Governance: The Enterprise Requirement

Security is the first objection every CISO raises when AI integration enters the conversation. 'You want to give an AI model access to our customer database?' The correct answer is not to calm the concern — it is to explain how MCP is designed to sit inside your existing security perimeter rather than bypass it.

MCP servers are standard HTTP services. They live behind your existing infrastructure — your API gateway, your VPN, your network firewall, your load balancer. They are not a new attack surface; they are a new client of your existing security controls. Access to an MCP server is governed by the same mechanisms you already use to govern access to any internal API.

Authentication: OAuth 2.1

The MCP specification mandates OAuth 2.1 for remote server authentication. This is not a proprietary scheme — it is the same standard your existing SSO, your internal APIs, and your cloud providers already use. An AI agent that calls your MCP server must present a valid OAuth token scoped to exactly the Resources and Tools the authenticated user is allowed to access. The AI sees only what the human behind the session is authorised to see — no more, no less.

Authorisation: Least-Privilege Tool Scopes

Beyond authentication, well-designed MCP servers implement tool-level authorisation. A sales analyst should be able to use the `fetch-deal` Resource but not the `delete-account` Tool. A customer service agent should have access to read and update support tickets but not billing records. These constraints live in your MCP server's authorisation layer — not in the AI model, not in the agent framework — so they are enforced consistently regardless of which AI client is in use.

• OAuth 2.1 for authentication — every agent call carries a scoped bearer token tied to a real user or service account
• Token scoping maps to your existing RBAC roles — no new permission system to maintain
• All tool invocations are logged server-side with the authenticated identity — full audit trail for compliance
• Rate limiting at the MCP layer prevents runaway agent loops from overwhelming your backend systems
• Input validation via JSON Schema on every tool call — malformed AI-generated arguments are rejected before reaching your database
• Network isolation — MCP servers sit inside your VPN/private network; AI clients in the cloud interact only through your API gateway
• Sensitive data masking — your MCP server controls field-level redaction before data is returned to the AI model

The Key Insight: The AI Never Touches Your Database Directly

This is the architectural point that resolves most enterprise security concerns. The AI model — whether it is Claude, GPT-4, or a custom fine-tuned model — never connects directly to your database, your file system, or your internal API. It connects to your MCP server, which is a controlled intermediary you own and operate. The MCP server fetches data, executes actions, and returns structured responses. Your sensitive data never travels directly to a third-party AI provider — only the sanitised, scoped, validated output of your MCP server does.

Building Your First MCP Server: Where to Start

The fastest path to a working MCP integration is to pick a single, high-value internal tool — the one your team spends the most time manually querying — and build a minimal MCP server for it. Anthropic and the MCP community provide SDKs in Python, TypeScript and Go that handle the JSON-RPC transport layer for you; your work is the domain logic: which resources to expose, which tools to build, and how to map your existing authentication to OAuth scopes.

• Step 1 — Identify the highest-friction internal data source: what does your team query manually every day that an AI assistant could answer instantly?
• Step 2 — Choose your SDK: TypeScript (ideal for Node.js/Next.js stacks), Python (ideal for data science and ML-adjacent backends), or Go (ideal for high-throughput production servers)
• Step 3 — Define your Resources first: read-only data access has zero risk and gives your team immediate AI value with no security overhead
• Step 4 — Add Tools incrementally: start with low-risk write operations (creating draft records, sending internal notifications) before exposing destructive operations
• Step 5 — Wire your existing OAuth provider: map your current RBAC roles to MCP tool scopes — do not build a parallel permission system
• Step 6 — Add observability from day one: log every agent invocation with timestamp, user identity, tool name, inputs and outputs
• Step 7 — Test with a real AI client: Claude Desktop or Claude API can connect to a local MCP server via stdio — validate the full loop before exposing over HTTP

A well-scoped first MCP server — covering one data source with five to ten Resources and two to three Tools — can be built in one to two weeks by a single backend engineer using the official SDK. The value compounds immediately: once that server exists, every MCP-compatible AI agent in your organisation can use it without additional work.