What is MCP
and why use it?

Most AI systems begin with a rather empty desk. The model can reason and write, but it does not know how many leads you received yesterday, what the team agreed on during its last call or why a new feature shipped on Tuesday.

You can bring it a spreadsheet, paste the relevant messages and explain the business every time. Or you can give it controlled access to the systems it needs. This is what MCP — the Model Context Protocol — is for.

MCP is not another AI model

MCP is an open standard for communication between AI applications and external systems. It is often compared with USB-C: instead of building a proprietary adapter for every service, there is a common way to describe which data is available and which actions can be performed.

On one side is an AI application such as Claude, ChatGPT, Codex, Cursor or an internal assistant. On the other is an MCP server exposing clearly defined capabilities. An MCP client maintains the connection between them.

Imagine asking an ordinary chat, “How many leads came in yesterday?” It does not know. It cannot see your CRM, spreadsheet or backend. Once connected through MCP, the AI can see where it is allowed to look for the answer and what it may do there.

What actually goes into an MCP system?

MCP does not pour every piece of company data into one enormous folder. It gives AI an organised set of capabilities and explains how to use them.

1. Tools. Specific commands the AI can call: retrieve sales for a period, find a customer, check stock or draft a task. Each command has defined inputs and an expected output.
2. Sources and resources. The approved databases, documents and systems: spreadsheets, policies, a knowledge base, CRM, backend, work conversations and call transcripts.
3. Ready-made prompts. Templates for recurring jobs such as “prepare the daily briefing”, “check the funnel”, “find discrepancies” or “build a report with source links”. They define both the sequence and the output format.
4. Access rules. Who can see financial data or customer records, where the system is read-only and which actions require human approval.

MCP tells the AI which doors exist, what sits behind each one, how to request what it needs and which doors it is allowed to open.

MCP itself does not store knowledge about your business, select a model or make management decisions. It is not the company’s brain or memory. It is a controlled, legible connector to them.

An AI agent then decides when to use that connector and in which order to call the available tools. For the distinction between a model, a chat and an agent, read “What is an AI agent and how does it work?”.

MCP gives a model hands and keys to selected cupboards.It does not guarantee that the model understands why last quarter’s report lives in cupboard number three.

What MCP looks like in an ordinary company

There is no need to imagine a rack of servers with flashing lights. In practice, a company selects a few systems that employees constantly visit for information and gives AI limited access to them through MCP.

1. An online shop. AI can read permitted order and stock data. You can ask, “Which items sold best last week, and which have fewer than ten units left?”
2. A sales team. AI can search approved CRM data, call transcripts and work conversations. It can find unanswered leads or assemble the history of a particular customer.
3. A knowledge base. AI searches company policies and documents. Instead of answering from general knowledge, it returns the current rule and a link to the source page.
4. A product team. AI can query analytics and the task tracker. It can show a metric change and find which releases or experiments took place at the same time.

Well-known products do the same thing in their own domains: Notion exposes pages and knowledge bases, Atlassian exposes tasks and documentation, and GitHub exposes code and development work. Cloudflare provides infrastructure for companies building their own MCP servers.

The advantage of a shared standard is that one connection can work with different MCP-compatible AI applications. You no longer need a bespoke integration for every chat or agent.

Can you build your own MCP server?

Yes. For an internal knowledge base or a specialised business system, a custom server is often more useful than a ready-made one.

Imagine that a company has a library of policies and process documents. Its MCP server could expose a few focused capabilities: search by topic, read a specific section, show who updated it and when, and return links to the source. An employee can then ask, “How do we approve discounts above 15%?” and receive an answer based on the current company policy rather than the model’s general knowledge.

The same approach works for a CRM, warehouse, billing platform, analytics store, task tracker or internal API. A server can run locally beside the AI application or remotely behind a protected connection.

What are you paying for when someone builds an MCP system?

A demonstration server with a single tool can be assembled quickly. A production system costs money not because the protocol is mysterious, but because the real work is turning a company’s processes into a reliable set of sources, rules and tools.

1. Use-case design. Define which questions the system must answer, who will use it and what a good result looks like.
2. Source connections. Set up authentication and integrations with databases, Salesforce or HubSpot, Slack or Teams, Google Drive or SharePoint, a warehouse and internal services.
3. Tool design. Instead of exposing a full API, create clear operations such as “retrieve sales”, “find a contract”, “assemble customer history” or “draft a task”.
4. Knowledge layer. Add policies, process documentation, metric definitions, data schemas, constraints and source priorities.
5. Prompts and workflows. Build reusable flows for a daily briefing, funnel review, management report or discrepancy check, each with defined steps and output.
6. Permissions and security. Separate reading from writing, protect personal and financial data and require approval for risky actions.
7. Traceability. Return source links, filters, formulas and data freshness; keep logs and provide useful error messages.
8. Evaluation and maintenance. Test real questions, edge cases and deliberately incomplete data, then keep the system aligned as the business changes.

The client is not buying “an adapter for an AI model”. They are buying a structured, documented version of their business that AI can access safely.

A real case: one interface for company metrics and context

For a company I cannot name yet, we built a large internal system around MCP. The goal sounded irresistible: give the team an assistant that can see the operating numbers and understand what was happening in the business at the same time.

Three layers of data feed the system:

1. Backend and business metrics. Leads, sales, conversions, cash balances, products and other factual indicators.
2. Company conversations. A separate bot reads permitted Telegram work chats and makes them searchable.
3. Calls. A transcription service turns meetings and conversations into text that can be found and compared with events.

The task tracker is connected as well. This means the assistant can show that conversion fell on a certain day, find what shipped on that date, retrieve the team’s discussion and surface the relevant call notes.

Strictly speaking, not every part of this system is MCP. The bot, transcription pipeline and data stores may operate independently. MCP is the common interface through which the AI discovers the sources and calls the tools we prepared. That is what allows one assistant to answer questions across several layers of context.

What the system does well

It is strongest when the request has a verifiable factual answer:

1. show conversion for a period and compare it with the previous one;
2. retrieve balances, sales, leads and best-selling items;
3. combine related figures from several systems into one table;
4. find what the team released on a particular day;
5. locate a discussion and link to the messages, tasks or transcripts;
6. check whether a statement in a report agrees with the underlying data.

This already saves hours. Instead of travelling through an admin panel, spreadsheets, Telegram and a tracker, a person gets the evidence in one conversation and can open the original source.

Where does it go wrong?

The trouble begins when the question changes from “what happened?” to “why did it happen?”.

The model can see that conversion fell on Tuesday and that the team released a new form on the same day. It will happily connect the two. Yet timing alone does not establish cause. The traffic mix may have changed, checkout may have failed, an item may have sold out, a competitor may have launched a promotion or the analytics system may simply have duplicated events.

The more context we provide, the more convincing a wrong story can sound. A model can find a plausible explanation and stretch the evidence to fit it — calmly, coherently and with excellent subheadings.

Retrieving a number is not the same as understanding its cause.Data access shortens the path to evidence. It does not remove the need to test a hypothesis.

Why an MCP system needs a business manual

To keep the assistant from comparing incompatible numbers, its tools need a detailed knowledge base beside them. In our case, this is effectively a substantial README explaining the data and the business.

It does not make the model infallible, but it sharply reduces the volume of beautifully written nonsense. The manual should contain:

Does this replace an analyst?

As an interface to data, partly. As a person who understands the business, measurement quality and causal reasoning, not yet.

A strong business analyst notices that the question is wrong, two segments cannot be compared, a metric has changed definition or a neat causal story needs an experiment. MCP can bring that analyst evidence faster, check a calculation and retrieve related context. The responsibility for the conclusion remains human.

In a small business, the owner often plays this role. They know where figures originate, which process is still maintained by hand and why December cannot be compared directly with November. An MCP assistant can become a remarkably strong interface to that business — once the owner extracts those rules from their head and writes them down.

Where to start

1. Choose five concrete questions. Not “understand the whole business”, but “show sales”, “find the policy” or “collect this week’s leads”.
2. Assign sources of truth. Define the system, formula and owner behind every answer.
3. Begin with read-only access. Start with search and reporting, move to drafts, and introduce actions last.
4. Demand evidence. Answers should include sources, filters, time periods and formulas.
5. Build an evaluation set. Include ordinary cases, exceptions and questions whose correct answer is “insufficient data”.
6. Separate facts from hypotheses. Make the system label what it retrieved, calculated and inferred.

A good first MCP server does not try to run the company. It answers a small set of expensive questions reliably. New data, tools and permissions can come later.