What is an MCP server?
A plain-English guide.

What is an MCP server?

An MCP server is a small, governed piece of software that sits between an AI assistant — Claude, ChatGPT, or an AI agent — and your real systems. It exposes a fixed set of named "tools" the AI is allowed to call, so the AI gets exactly the access you define — never a raw login, password or unrestricted database connection. MCP (the Model Context Protocol) is the open standard that defines how that handshake works.

The problem MCP solves

An AI assistant like Claude or ChatGPT is very good at reasoning over whatever you put in front of it. The problem is getting your actual data in front of it safely. Copy-pasting is slow and error-prone. Letting a model have a raw login to your systems is reckless. MCP — the Model Context Protocol — is the standard that closed that gap: a small server sits between the AI and your system, decides exactly what the AI is allowed to read or do, and exposes that as a defined set of "tools" the AI can call.

What an MCP server actually is

Think of it as a translator with a very short list of permissions. The AI doesn't get your database password or your broker login. It gets a list of named tools — get_account_balance, run_analytics_report — each one a narrow, well-defined piece of code running on a server you control. The AI asks for a tool by name with some arguments; the server runs it, checks every input, and hands back only the result. Nothing else is reachable.

A real example: one connector, 65 governed tools

One MCP server I built reads Google Analytics, Search Console and Tag Manager data, provisions a brand-new client site end to end — a new GA4 property, a verified domain, a published Tag Manager container — manages DNS and email routing on Cloudflare, and runs SEO/competitor research, all through a single authenticated connection. Before this existed, that was five separate dashboards and a lot of manual setup for every new client site. Now it's one governed connector an AI client can use directly, behind a standards-based OAuth 2.1 login with PKCE — the same login flow banking apps use, not a shared password sitting in a config file.

A real example: read access to a live brokerage account

The other end of the spectrum is an MCP server that gives an AI client full read access to a real trading account — live positions, option chains, Greeks, multi-source market data — and a deliberately narrow path to actually placing a trade. Every write operation needs a broker-confirmed dry run first, then a one-use, two-minute confirmation token tied to that exact order. The AI can see everything and propose anything. It can only act through a gate that expires, confirms with the real broker first, and can't be replayed. That's the actual engineering problem MCP work involves: not "can the AI reach my system," but "can I prove it can only do the narrow thing I allowed."

Why this runs on Azure

Both of those servers are hosted on Azure App Service, with secrets held in Azure Key Vault and accessed via managed identity rather than stored API keys — so there's no standing credential sitting in a config file for either server to leak. For a server touching real financial or business data, that's not an optional extra: it's the difference between "an API key existed somewhere it could be stolen" and "no API key for that service ever existed at all."

Where this fits for your business

• Reading live data (analytics, inventory, accounts) without copy-pasting it into a chat window.
• Letting an AI agent run on a schedule and act on real data, inside guardrails you define.
• Replacing "five dashboards, one person checking them" with one governed connector.
• Keeping every credential in Key Vault and every access path logged and auditable.

How do you build an MCP server?

At a high level, four things have to be true before an MCP server is safe to connect to anything real. First, every action the AI can take is defined as its own narrow tool — not open-ended access, a specific named function with a strict input schema. Second, the server authenticates properly: OAuth 2.1 with PKCE is the current standard, the same class of login flow banking apps use, not a shared API key sitting in a config file. Third, every credential the server needs lives in a secrets manager — Azure Key Vault, accessed via managed identity — so there's no standing key to leak in the first place. Fourth, anything that writes or changes data (placing an order, sending an email) gets a confirmation step, not a direct path from "AI decided to" to "it happened." The two live examples above were both built this way, and it's the same pattern regardless of whether the system behind it is a CRM, a brokerage account or an analytics platform.

Frequently asked questions