MCP in plain words: how AI gets access to work data

You ask an AI assistant to prepare a report on tasks, and it replies: "I don't have access to your system." The data sits in your customer relationship management system (CRM) and on a shared drive, tasks are tracked in Notion, and every time you have to copy them into the chat by hand. MCP is a way to give AI access to these systems directly and under control.

MCP (Model Context Protocol) is an open standard by which AI applications connect to external systems: databases, files, work services and their application programming interfaces (APIs). It is often compared to USB-C: one connector instead of a separate cable for every device.

Why a company needs a common standard

Without a common standard, each "AI application – work service" pair needs its own connection. Three AI tools and five work systems mean up to fifteen separate integrations, each with its own request format, its own rules for checking access rights and its own errors. MCP defines a common protocol for interaction between client and server: if a service supports MCP, a compatible AI application can connect to it.

Compatibility is not absolute, though. It depends on the version of the specification that both sides support, on the set of capabilities and on how security is implemented.

How it works: three participants

The host is the AI application you use: a desktop AI client, a code editor or a work assistant. It manages the connections. Inside the host run clients, and each one talks to a single server. The server is a program that opens up access to a specific system for AI: to files, GitHub, a database or Notion.

One host can connect to several servers at the same time. How isolated these connections are from each other and what rights they have is decided by the host itself and by the servers.

What a server gives AI

A server offers AI three kinds of capabilities:

• tools perform actions – find a record in a database, create a task, send a request to an API; the model decides whether to call a tool;
• resources provide context for reading – the contents of a file, the structure of a database, the change history in Git; the application passes them on;
• prompt templates – ready-made scenarios such as an "analyse document" menu command, which the user chooses themselves.

Where it is useful

The first scenario is an assistant that can see the company's tasks and documents. The AI application is connected to the servers of work systems and uses their data in its answers. It sees exactly what the account used for the connection is allowed to see.

In software development, a code editor is connected to the source code repository, monitoring and the database: the agent understands the project structure and calls the permitted tools. Write permissions here should be especially narrow.

The third option is running automations straight from the dialogue: the agent calls a ready-made process through the MCP server of an automation system. Here you need to check the consequences of running it separately and make sure that a repeated request does not carry out the action twice.

Risks and what to ask IT before connecting

An MCP server tool can read confidential data or perform actions that cannot be undone. The protocol itself does not create an isolated environment: key storage, confirmation of dangerous actions, an operations log and network access restrictions are provided by the application and the server.

Before connecting, find out:

• Who published the server, and can it be trusted?
• What actions can it perform – only read, or also change data?
• What permissions does it request, and under whose account does it run?
• Is human confirmation required before writing and deleting?
• Is there a log: who did what, and when, through AI?
• What data goes to the AI model provider? If it includes personal data of customers or employees, it is covered by GDPR – the European regulation on the protection of personal data.

Where to start

At Simplit we advise starting with one system and read-only access. Connect the server to a separate test folder with no secrets or work data and see how AI works with it. Add write permissions later, selectively and with human confirmation. Decide in advance what data AI may see, which operations are available to it and where a person has to click "yes".

MCP does not make an AI assistant smarter: it gives it access to your data. So beyond the technical setup, there is management work here too: deciding what to open up, to whom and with what checks. You can discuss which system to start with in your company at a free 30-minute meeting with Simplit. Discuss your task

Read next: how to limit MCP access and protect yourself against instruction tampering and what to delegate to an agent in Notion.

For the technical specialist

A condensed summary of the technical part based on the reference updated on 8 September 2026. The current specification version number was verified on 1 November 2026 against the official website.

Version. The current version of the specification is 2026-07-28. It moved the MCP core to a model without a protocol session: the initialize/initialized exchange and the Mcp-Session-Id header have been removed. Each request is self-contained: the protocol version is specified separately, and information about the client and its capabilities is passed in _meta. An optional server/discover call lets you find out the server's capabilities in advance. Clients and servers on version 2025-11-25 may need to migrate. Application state, where needed, is stored separately – for example, in an explicit identifier returned by a tool.

Transport. Messages are encoded in JSON-RPC 2.0. Locally, STDIO is used: the client launches the server as a subprocess and exchanges messages with it through stdin and stdout. Remotely, Streamable HTTP: the client sends requests over HTTP, and the server responds with JSON or an event stream; in version 2026-07-28, requests contain the Mcp-Method and Mcp-Name headers – the method name and, when the request addresses a tool, its name. Gateways, rate limiters and WAFs use them to route and account for requests without parsing the JSON body. The old HTTP+SSE is deprecated, with a transition period of at least 12 months after the 2026-07-28 release.

New in 2026-07-28. Multi-round exchanges (MRTR) have been introduced: a tool can request missing data or human confirmation. The server responds with resultType: "input_required", and the client repeats the call with inputResponses. MRTR replaces the earlier server-initiated calls elicitation/create, sampling/createMessage and roots/list, which required an open bidirectional stream.

The tools/list, prompts/list, resources/list and resources/read responses contain ttlMs and cacheScope – explicit caching rules. Tasks have been moved into the io.modelcontextprotocol/tasks extension with tasks/get and tasks/update for long-running operations; notifications go through subscriptions/listen with subscription by event type. Roots, Sampling and Logging have been declared deprecated: compatibility is maintained for at least 12 months after the 2026-07-28 release, but building new architecture on them is not advisable.

Authorisation. Optional. For HTTP transports, the authorisation specification is based on OAuth 2.1; it should not be applied to STDIO – credentials are taken from the environment. The client checks the iss parameter before the code exchange; credentials are bound to the authorisation server that issued them; Dynamic Client Registration has been deprecated in favour of Client ID Metadata Documents but is retained for now for backward compatibility; the server accepts only tokens intended for it and does not pass an incoming token on to a third-party API. For Streamable HTTP, the server must check Origin; the documentation recommends authentication and, when running locally, binding to 127.0.0.1 rather than to all interfaces.

Quick start. An illustrative example for a client that supports the mcpServers format: the file server is connected to a separate test folder with no secrets or work data – do not open your whole home directory to the server. The example has not been run – check the package name, launch method and version compatibility against your client's documentation.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/mcp-test"]
    }
  }
}

Restart the client, make sure the server is connected and shows tools or resources, create a file with harmless text in the test folder beforehand and ask AI to read it. If the client doesn't see the server, check the path, whether Node.js is installed, the launch log and version compatibility.

If it doesn't work:

• the server doesn't start – run the command on its own and look at stderr, the runtime version and the package name;
• no tools or resources – check the server's capabilities through the client's discovery mechanism and the compatibility of protocol versions;
• an HTTP request is rejected – check MCP-Protocol-Version, Mcp-Method, Mcp-Name, Origin and authorisation;
• an OAuth error – check the authorisation server metadata, redirect URI, PKCE, scopes and the binding of the token to the MCP server;
• context is lost between requests – don't rely on Mcp-Session-Id, pass the state identifier explicitly;
• an old client has stopped connecting – find out the specification versions on both sides and use the SDK migration guide.

SDKs. Version 2026-07-28 is supported by the tier-one SDKs: TypeScript, Python, Go and C#; Rust is in beta. Before upgrading, read your SDK's migration notes.

Official sources: MCP documentation, specification versions, MCP server registry.