Most teams already use an AI assistant every day. They draft emails in ChatGPT, summarize documents in Claude, or ask Gemini to explain a spreadsheet. What those assistants usually can’t do is work with the systems that hold the organization’s real data: the CRM, the ticketing system, the finance application, the document library.
The Model Context Protocol (MCP) is how that gap gets closed, and an MCP server is the piece you build to close it safely.
MCP in one paragraph
MCP is an open standard, introduced by Anthropic in 2024 and now supported by OpenAI, Google, Microsoft and others, that lets AI assistants use external tools and data. An MCP server sits next to one of your systems and publishes a short list of named tools, such as “check availability”, “find this customer” or “summarize this ticket”. Any MCP-capable assistant can discover those tools and call them. The server does the actual work against your system and returns only the result.
The important detail: the AI never talks to your system directly, and never sees its credentials. It only sees the tools you chose to publish.
Why not just give the AI an API key?
It’s tempting to point an AI assistant straight at an API. It’s also why most security teams say no. Raw API access has three problems:
- It’s all or nothing. The assistant gets every field and every operation the account can reach, including data it doesn’t need and actions it should never take.
- There’s no record of who asked for what. Calls happen under one service account, so you can’t tell which person’s question led to which change.
- Sensitive data leaks into prompts. Whatever the API returns, payment details and private notes included, is sent to the AI provider.
An MCP server fixes each of these by putting a governed layer in between.
What a well-built MCP server does
A production MCP server is more than a thin wrapper. The ones we build at Bryant Technologies include:
- Identity. Staff sign in with single sign-on (Microsoft Entra ID, Google Workspace or Okta); systems use API keys; public tools need no sign-in but only see public information.
- Permissions per tool, role and field. The box office sees orders, marketing sees sales trends, leadership sees summaries. Each role only gets the tools it needs.
- Redaction. Payment details, dates of birth and private notes are removed on the server, before anything reaches an AI model.
- Human approval for changes. Read tools run immediately; anything that writes, such as a note, a contact update or a reservation, waits for a person to approve it.
- Audit logs and limits. Every call is logged with who asked, what ran and what changed. Rate limits and query caps protect the underlying system.
Tools, not endpoints
The biggest design decision is which tools to publish. A good tool is shaped around a question people actually ask, not around the structure of your API.
Compare a raw endpoint like GET /constituents?filter=... with a tool called brief_me_on_donor(name). The second one returns exactly what a development officer needs before a meeting: giving history, recent contact, open asks. It hides everything else. It’s also far easier for an AI to use correctly.
We usually start with a handful of read-only tools for one team, measure how they’re used, and add more, including write tools with approval, once people trust the results.
Where the server runs
An MCP server is a small service, so it can live wherever your systems do:
- in your own Azure, AWS or Google Cloud account, next to the system it connects to;
- on your own servers, including networks with no internet access, paired with local AI models;
- or as a service managed by us.
Either way, your system’s credentials stay on the server.
One integration, every AI tool
Because MCP is a standard, one server works with Claude, Claude Code, ChatGPT (through custom connectors), Gemini-based tools, IDEs such as Cursor and VS Code, and the agents and apps you build yourself. Instead of a different plugin for every AI product, you maintain one governed integration.
The same server can also power customer-facing assistants. Our MCP Server for Tessitura gives arts-organization staff governed access to live ticketing and donor data, and also feeds the AI Chatbot for Tessitura that answers patrons around the clock.
How to get started
- Pick one team and one system. Write down the ten questions they’d most like to ask.
- Design the tools. Decide what each tool returns, who can use it and what must stay private.
- Build against a test environment. Prove the tools on safe data first.
- Connect the AI tools your team already uses, then train people and watch real usage.
- Expand to more tools, more teams and more systems on the same foundation.
If you’d like help planning your first MCP server, see our Custom MCP Servers service or get in touch.