What is MCP? The Model Context Protocol explained for IT professionals

What is MCP?

MCP stands for Model Context Protocol. The standard defines how an AI application talks to the systems it retrieves content from or performs actions in. It was modelled on the Language Server Protocol, which lets development environments understand many programming languages: once built, a connection works with every application that speaks the standard.

Anthropic published MCP as an open standard in November 2024. Since 9 December 2025, it has belonged to the Agentic AI Foundation under the umbrella of the Linux Foundation, whose members include major providers such as Anthropic, Google, Microsoft and OpenAI. The current version of the specification is dated 28 July 2026.

How is MCP structured?

Component	Role	Example
Host	the AI application people work with	chat of an AI platform
Client	the host’s connection to exactly one server	connection to the wiki
Server	provides the content and functions of a system	MCP server for Confluence

A server offers three kinds of building blocks:

• Resources: content and data, such as pages, files or records.
• Tools: functions the AI model can call, such as “search tickets” or “create appointment”.
• Templates: prepared instructions and workflows that people select.

Messages follow JSON-RPC 2.0. They are transmitted locally via a program’s standard input and output, or over HTTP when the server and application run on different machines.

How does an AI application sign in to an MCP server?

For connections over HTTP, the specification describes sign-in under OAuth 2.1. The MCP server is a protected service that accepts access tokens from an authorisation service. Key rules from the specification:

• A token is valid only for the server it was issued for; the server must check this.
• A server must not accept or pass on tokens intended for other services.
• Tokens belong in the request header, never in the address.
• The application requests only the permissions it needs for the task.

For servers that run locally as a program, the specification does not provide for OAuth sign-in; credentials come from the environment there. Overall, sign-in is optional in MCP. Whether a server uses it is one of the first questions in any review.

Which security questions should IT ask?

The specification itself states that MCP enables data access and code execution and cannot enforce security principles at protocol level. That remains the job of the application. Check:

1. Whose permissions? Does the application access systems with the account of the person asking, or with a shared account that sees everything?
2. Read or write? Tools that change something should stay switched off until they are deliberately enabled, and then run only after a human confirms.
3. Where does the server come from? According to the specification, tool descriptions are to be considered untrusted unless the server is trusted. A third-party server can mislead the AI with manipulated descriptions.
4. What is in the data? Content from connected systems can contain hidden instructions. MCP does not protect against this. Hidden instructions in documents →
5. Is it logged? Every tool call should appear in the application’s audit log.
6. Which version? The July 2026 version restructured the protocol significantly; older versions are still in use. Ask which version the application and server speak.

How does basebox use MCP?

basebox connectors use MCP to connect your systems. Every access runs with the permissions of the person currently asking, read-only by default. There is no shared service account: credentials are stored per person and never displayed, and the target system enforces its own permissions. Where a system has its own sign-in, the person signs in via OAuth with their own account; basebox receives an authorisation for this, not a password. Only the basebox server establishes connections to connectors, never the person’s device, and every connector call is recorded in the audit log.

Reviewed connectors and your own MCP servers

	Connectors from the basebox library	Your own or third-party MCP servers
Reviewed	always reviewed by basebox	not reviewed by basebox
Available	for all customers	only within your organisation
Responsibility	basebox for the connector	your organisation

A third-party MCP server is only added to the basebox library once basebox has reviewed it, for example when a customer provides it.

Unreviewed MCP servers bring their own risks:

• Third-party code: The server runs code and sees all data that passes through it.
• Manipulated descriptions: Tool descriptions can lead the AI to make different calls than intended.
• Silent changes: A new version can change tools or descriptions without anyone noticing.
• Excessive permissions: A server with a shared account or write permissions can do more than the task requires.

So before adding your own MCP server, check it against the questions above, pin the version, and share it read-only with a small group first.

Which connectors exist, and their status, is listed on /konnektoren. If a system with an interface is missing, basebox builds the connector at a fixed price and adds it, reviewed, to the library. You add your own MCP servers only within your organisation, unreviewed and under your responsibility; third-party servers enter the library only after review by basebox.