Model Context Protocol (MCP): Connecting AI Assistants to Your Business Systems

Until recently, connecting an AI assistant to your systems meant writing a custom integration for every pair: one for your CRM in one chat product, another for the same CRM in a different agent framework. The Model Context Protocol (MCP) replaces that matrix with a single standard. You expose your systems once, as an MCP server, and any MCP-compatible client — desktop assistants, IDEs, agent frameworks — can use them.

What MCP actually is

MCP is an open protocol that defines how an AI application (the _client_) discovers and uses capabilities provided by a _server_. A server can offer three kinds of things:

• Tools — functions the model can call, like search_customers or create_invoice_draft.
• Resources — read-only data the client can load into context, like a document or a record.
• Prompts — reusable, parameterized prompt templates for common tasks.

The client asks the server what it offers, shows those capabilities to the model, and forwards the model's tool calls to the server. Your business logic stays in your server; the AI application never touches your database directly.

When MCP is the right choice

MCP shines when several AI clients need the same access, or when you want your team to use your internal systems from the assistants they already work in. Typical examples:

• Sales staff querying the CRM and drafting follow-ups from their AI assistant
• Developers letting their coding assistant read tickets, logs and API docs
• Operations staff asking questions about inventory or orders in plain language

If you're building a single customer-facing chatbot inside your own app, plain function calling may be simpler. Many teams do both: their app's agent calls the same tool implementations that their MCP server exposes.

Anatomy of a small MCP server

Here's the shape of a server exposing two ERP tools, using the official TypeScript SDK:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "erp", version: "1.0.0" });

server.tool(
  "search_products",
  "Search products by name or SKU. Returns stock levels per warehouse.",
  { query: z.string().min(2), limit: z.number().int().max(20).default(10) },
  async ({ query, limit }, { authInfo }) => {
    requireScope(authInfo, "inventory:read");
    const rows = await erp.products.search(query, limit);
    return { content: [{ type: "text", text: JSON.stringify(rows) }] };
  }
);

server.tool(
  "create_purchase_order_draft",
  "Create a DRAFT purchase order. Drafts must be approved in the ERP before sending.",
  {
    supplierId: z.string(),
    lines: z.array(z.object({ sku: z.string(), qty: z.number().positive() })),
  },
  async (input, { authInfo }) => {
    requireScope(authInfo, "purchasing:draft");
    const po = await erp.purchaseOrders.createDraft(input, { by: authInfo.userId });
    return { content: [{ type: "text", text: `Draft ${po.number} created for review.` }] };
  }
);

Notice the second tool only creates a draft. The assistant can do the tedious work; a person still approves anything that leaves the company.

Transports: local vs remote

MCP servers run in two main ways:

For business systems, a remote server over HTTPS is almost always right: you deploy it like any other API, put it behind your identity provider, and log every call centrally.

Security is the whole job

An MCP server is an API that an AI will call on behalf of a person. Everything you'd do for a public API applies, plus a few AI-specific concerns:

1. Authenticate the human, not the AI. Use OAuth so each call carries the real user's identity and scopes. The MCP specification defines an OAuth-based authorization flow for remote servers.
2. Least privilege. Expose the smallest set of tools that does the job, and check scopes inside every tool.
3. No raw query tools. run_sql is a data breach waiting for a prompt injection. Expose specific, parameterized operations.
4. Treat outputs as untrusted. Data returned by tools (emails, documents, web pages) may contain instructions written by an attacker. Clients should present it to the model as data, and your tools should avoid echoing untrusted content unnecessarily.
5. Audit everything. Log user, tool, arguments and result summary for every call.
6. Rate limit per user and per tool.

Designing tools models use well

Tool descriptions are prompts. Clear, specific descriptions dramatically improve how reliably models choose and call tools:

• Say what the tool does _and when to use it_ ("Use this to check stock before promising delivery dates").
• Document units, formats and limits in the schema, not just in prose.
• Return concise, structured results; include IDs the model can pass to follow-up tools.
• Prefer a few task-oriented tools over dozens of thin CRUD endpoints.

A rollout path that works

1. Read-only first. Search and lookup tools for one team. Measure usage and accuracy.
2. Drafts next. Tools that prepare work for human review: draft emails, draft orders, draft reports.
3. Selective automation. Promote specific, low-risk actions to automatic once logs show they're reliable.

MCP doesn't make your AI smarter — it makes your systems _reachable_ in a consistent, governable way. That's exactly what most businesses need before AI can do useful work.

_Want your ERP, CRM or internal APIs available to AI assistants securely? Explore our AI software & automation service._