Technical overview
MCP, short for Model Context Protocol, is an open standard for connecting AI applications to the outside world: your files, databases, calendars, accounting tools and any other system an AI assistant would otherwise know nothing about. It was introduced by Anthropic in 2024 and is now supported by a wide range of AI assistants and developer tools, including Claude, ChatGPT, Visual Studio Code and Cursor.
The official documentation describes it with a simple picture: MCP is a USB-C port for AI applications. Just as one kind of port lets you plug a screen, a drive or a charger into the same laptop, MCP gives AI applications one common way to plug into external systems. You can read the original in the MCP introduction.
An AI model on its own can only work with what it was trained on and what you paste into the chat. To be genuinely useful at work, it needs to read your stock levels, check a calendar or draft an invoice. Before MCP, every AI application needed its own custom connection to every tool, and every tool needed to be wired up again for the next assistant. The work multiplied with every new pair.
MCP replaces that with a shared language. A tool is connected once, by building an MCP server for it. After that, any AI application that speaks MCP can use it. Build once, use everywhere.
Developers. Less time and complexity when building or integrating AI features, because the connection is standard rather than hand-made.
AI applications and agents. Access to a whole ecosystem of data sources, tools and apps, which makes them more capable.
Everyday users and businesses. More capable assistants that can read your information and take actions for you when needed, and a clear place to decide how far that goes.
MCP uses a client-server design with three roles. The documentation explains them in its architecture overview.
The host. The AI application your team uses, for example an assistant or a coding tool. It coordinates everything.
The client. A component inside the host. The host creates one client for each server it connects to, and each client keeps its own dedicated connection.
The server. A program that provides context and actions to the client. It can run on your own machine (a local server) or on a remote platform (a remote server).
Underneath, MCP has two layers. The data layer defines the messages that clients and servers exchange, using the widely adopted JSON-RPC 2.0 format. The transport layer defines how those messages travel: either through standard input and output for programs on the same machine, or over HTTP for remote servers, with normal authentication methods and OAuth recommended.
A server can be connected to different AI applications, and one AI application can use many servers at the same time, for example one for your warehouse system and another for your calendar.
A server shares its abilities through three building blocks. They are described in the server concepts.
Building block | What it is | Who decides when it is used | Examples |
|---|---|---|---|
Tools | Functions the AI can call to do something, such as querying a database, calling an API or creating an event. | The AI model, based on the request | Check stock, draft an order, create a calendar event |
Resources | Read-only information that gives the AI context. | The application | A document, a database schema, a price list |
Prompts | Ready-made instruction templates for common tasks. | The user, on request | Summarise my meetings, prepare the weekly order |
Each tool is described with a name, a plain-language description and a precise list of inputs it accepts. That description is what the AI reads to understand what it may do, which makes every action explicit and predictable.
Discovery. The AI application connects to the server and learns what it supports.
Listing. It asks the server for the list of available tools and their descriptions.
Decision. While talking to your employee, the AI model decides whether one of those tools would help.
Call. The application sends the request to the server, with the inputs the tool expects.
Result. The server does the work and returns the result, which the AI uses in its answer.
Servers can also announce changes. If a tool is added or removed, connected applications that asked to be informed are notified, so the AI always knows what is currently available.
One standard instead of many connections. Connect a tool once and use it from every assistant that supports MCP.
No lock-in. MCP is open and not owned by one AI vendor. If you change assistant tomorrow, your connections stay.
Explicit, predictable actions. Every action the AI can take is a defined tool with typed inputs, not a free-form guess.
A natural place for control. Because everything passes through the server, that is where permissions, limits and records belong. The documentation itself encourages showing available tools to users, asking for approval on individual actions, pre-approving only safe operations and keeping activity logs.
Fast to adopt. A growing library of ready-made servers and SDKs for many programming languages means less to build from scratch.
This is the most important idea for a business. MCP standardises the connection, not the rules. What an AI can do depends entirely on what the server offers. If a tool is not on the server, the AI has no way to call it, however it is asked and however convincingly it is misled.
That is why every Vista Point setup is custom-built. We create an MCP server for your tools and expose only the actions you have agreed to, in three layers:
Scoped tools. Only the agreed actions exist. Everything else is simply not available to the AI.
Read or draft. Reading data and preparing drafts are separate permissions, set per action. Sending, paying and deleting are never part of the toolbox.
Audit log. Every request and its result are recorded, so you can always see what the AI did.
You can see how this looks for a real company on the AI with boundaries page.
An employee asks the assistant to check stock and prepare this week's order.
The AI uses a read-only tool to check stock. This is allowed.
It uses another tool to prepare a draft order. This is allowed.
It tries to send the order. There is no tool for that, so nothing happens. The draft waits for a person.
The employee reviews the draft, changes a line and sends the order in your usual system.
The AI later tries to change the supplier. That tool does not exist either, so nothing happens.
Giving an AI access to business systems deserves care. The MCP project publishes security best practices, and several ideas in them guide how we plan every setup:
Least privilege. Start with the smallest set of permissions, and add more only when a task really needs it. Broad, catch-all permissions make any leak far more damaging.
Clear consent. Important actions should be visible and approved by a person, not triggered silently.
No shortcuts with credentials. A server should only accept credentials that were issued for it, and should never blindly hand someone else's credentials on to other systems.
Caution with local programs. A server that runs on a computer has the same reach as the person who started it, so it should be trusted, restricted and, where possible, isolated.
Verify who is asking. Possessing an identifier for some stored state is not proof of identity. The server must check who is making each request.
No. Developers build the server, and your team simply uses their AI assistant as usual.
Only what the server exposes. That scope is part of what we agree with you.
Yes. Rules are adjusted as your business changes, and the server is updated to match.
No. It is an open standard with an open specification, and many AI applications and tools support it.
Any assistant or agent that supports MCP. We confirm compatibility with your tools during the consultation.
Yes. The application keeps a separate connection for each server, so the same assistant can combine, for example, your stock system and your calendar.
No. MCP only covers how context and actions are exchanged. How the AI model reasons and uses that information is outside of the standard.
These pages from the official MCP documentation go deeper into each topic:
modelcontextprotocol.io (documentation home)
What is MCP? (introduction)
Understanding MCP servers (tools, resources and prompts)
Book a consultation and tell us what AI should never do. You can reach us on the contact page.