MCP GuideAI assistants

What is an MCP server, and does your company need one?

A plain explanation of the Model Context Protocol for people who have to decide whether to build one, from someone who builds them.

Bence Bial 2 min read

AI assistants

  • Claude
  • ChatGPT
  • Copilot

MCP server

  • search_customers
  • get_open_items
  • get_document
  • create_draft

OAuth 2.1, per-user permissions, audit log

Your systems

  • REST API
  • PostgreSQL
  • Search index
The screens are illustrations of the systems; names and figures in them are made up.

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to tools and data. Anthropic introduced it in 2024, and today it is supported by Claude, ChatGPT, Gemini, Microsoft Copilot and many other clients.

An MCP server is the piece you build on your side. It tells the assistant, in a form a language model can read, what your system can do, such as “find a customer” or “list open invoices”, and it carries out those calls when the assistant asks.

  1. AssistantClaude, ChatGPT, Copilot
  2. MCP servertools, identity, rules
  3. Your systemsAPI, database, documents
The assistant asks; the MCP server checks who is asking and returns only what that person may see.

When it is worth building one

  • You run a data product or SaaS, and your customers already work in AI assistants. An MCP server puts your product inside their assistant, instead of them copying and pasting between your app and the chat.
  • Your staff need answers from live systems. An assistant that can only read documents cannot tell you a customer’s open balance or the status of a ticket. Tools can.
  • You want one integration for every assistant. One MCP server works with all of them.

When it is not

  • A scheduled export or a dashboard would answer the need.
  • Nobody in your company or among your customers uses an AI assistant for this kind of work yet.
  • The underlying data is not reliable. An assistant makes bad data easier to reach, not better.

What makes one good

The protocol itself is the small part. A good server has a handful of tools shaped around what users actually want, never lets the model decide who the user is, says where every answer came from, and is tested with real questions before release.

Where to start

Pick the five questions your users ask most often that need your data. Build the smallest server that answers those well, put it in front of real users, and measure. Two servers we built, one for a company-information platform and one for a real estate data platform, started exactly that way.

More write-ups

All posts