What the Model Context Protocol is
The Model Context Protocol (MCP) is an open protocol introduced by Anthropic in November 2024 to connect artificial intelligence applications to external data sources and tools. Before MCP, every assistant had its own integrations, written one by one; with MCP a service connects once and any compatible client can use it. That is why it is often described as a standard port for AI.
The protocol has three roles. The host is the application the person uses, for example Claude or ChatGPT. The client is the part of the host that talks to a server, one per connection. The server is the service that offers data and actions: a document store, a CRM, a data platform. Messages travel in JSON-RPC 2.0 format, the same for everyone.
What an MCP server does (tools, resources, permissions)
An MCP server declares what it can do, and the client shows it to the model. The specification provides for three kinds of capability.
| Capability | What it is | Example on company data |
|---|---|---|
| Tools | Functions the model can call, with described arguments | Run a read-only query, list a project's datasets, create a dashboard |
| Resources | Content the application can read and give the model as context | A dataset's description, a document, the column schema |
| Prompts | Request templates prepared by the server | A guided analysis of the monthly margin |
The most important point is that the server decides what to expose and to whom. The model does not see the database: it sees the tools the server offers it, and every call goes through the server's permissions. A good MCP server for company data exposes data that is already governed, such as datasets with stable fields and shared definitions, rather than raw tables, because a model choosing on its own among a hundred similarly named tables gets it wrong more often.
Local or remote: the differences
| Local server | Remote server | |
|---|---|---|
| Where it runs | On the person's computer, started by the application | On a network service, reached at an HTTPS address |
| Transport | stdio (the process's input and output) | Streamable HTTP |
| Access | Credentials sit in the local configuration | OAuth login: the person signs in to the service and grants permissions |
| Suited to | Developers, local files, personal tools | Shared company data, several people, central control |
| Revocation | Remove the server from the configuration | Revoke the connection from the service, with immediate effect |
Security: OAuth, permissions, revocation
For remote servers the MCP specification adopts OAuth 2.1: the assistant never receives the password, but a token limited in time and in permissions, obtained after the person has signed in to the service and approved a consent page. The questions to ask of any MCP server before connecting it are always the same.
- What permissions does the assistant work with? Those of the person who connected it, never more, and only the ones they granted.
- What can it change? Reads are one thing, writes another: who approves a change the assistant proposes?
- Who can connect it? An administrator must be able to decide whether connectors are on and which assistants are admitted.
- How is it revoked? The connection must be revoked from the service, taking effect on the next call, without depending on the assistant.
- What gets recorded? Every call, with the assistant and the connection that made it.
Muvia's MCP server answers like this: a connection is always one person, one company and one assistant; the login is Muvia's, with the second factor if the company requires it; what the assistant can do is the intersection of the person's current roles, the permissions granted, the company's modules and the administrator's consent, recalculated on every call. Every write is a proposal that a person approves in Muvia, except for the autonomy an administrator chooses kind by kind, and actions on machines always wait for a person. The connection guide describes the six permissions one by one.
Example: asking Claude for the month's margin
A controller has connected Claude to Muvia, granting read and SQL reads. She writes in the chat: “In the Controlling project, what was September's margin by business unit, compared with August?” Here is what happens.
- Claude reads the available tools and calls the one that lists the project's datasets: it finds the monthly income statement dataset, with its columns.
- It builds an SQL query on the dataset and passes it to the
query_sqltool. Muvia runs it read-only, with the controller's permissions, only in the projects she is assigned to. - Muvia returns the rows; Claude writes the answer with the margin table by business unit and the difference from August.
- In the conversation the tool call stays visible with its query, which the controller can open and read.
The whoami tool is the simplest check: asked “Who am I on Muvia?”, the assistant answers with the person's name, the company and the permissions granted. It is the first thing to ask after connecting.
How to check an answer (the query underneath)
An assistant connected to data goes wrong in different ways from one that makes things up: usually the number really is calculated, but on the wrong definition. For example, the margin calculated on invoices without subtracting credit notes, or a month taken by delivery date instead of invoice date. That is why the answer should be judged by its query, not by its tone.
- Read the query: the table or dataset used, the filters on the period, what is being summed. If you do not know SQL, ask the assistant to explain it line by line.
- Check the source: a certified dataset, with a shared definition, is worth more than a raw table chosen by the model.
- Compare with a known number: the month's total in a dashboard or report the company already uses.
- Run it again: the same query, pasted into Muvia's SQL editor, must give the same result.
It is the principle Muvia's agents are built on: every answer, inside Muvia with Athena or outside with the assistant the company has already chosen, comes with the query that produced it.
List of compatible clients
MCP is supported by a growing number of applications. Among the most widespread are Claude (on the web, in the desktop app and in Claude Code), ChatGPT with connectors, Visual Studio Code, Cursor and Microsoft Copilot. How it works varies from one client to another and over time: some accept only remote servers with OAuth, others local servers too, and some require a paid plan or enabling by an administrator.
Muvia's server is a remote server: by default a company admits only the assistants Muvia has verified, namely Claude, ChatGPT and Visual Studio Code, and an administrator can admit others. Claude Code connects with the command claude mcp add --transport http. The steps for each client are in the connection guide; the technical details of the protocol, tokens and permissions are in Agents and MCP and in the developer documentation.
Frequently asked questions
It is a service an AI assistant can query with a standard protocol, the Model Context Protocol, to read data or carry out actions, with the permissions of the person using it. It is connected once and works with every compatible client.
No, if it is well designed. The model sees only the tools the server exposes, and every call goes through the connected person's permissions. With Muvia's server, the assistant reaches only what the person's role and the permissions granted allow, and queries are read-only.
A local server runs on the person's computer and talks to the application through the process; a remote server is a network service reached at an HTTPS address with an OAuth login. For shared company data a remote server is usually the one used.
It depends on the server and the permissions. With Muvia every write is a proposal that a person approves in Muvia, unless an administrator chooses immediate execution for that kind of change; actions on machines always wait for a person.
By revoking the connection from the service. In Muvia each person revokes their own connections in Settings → AI connectors, and an administrator those of the whole company; revocation applies from the next call.