Connecting an AI assistant to your system (MCP)

Who this service is for

Teams that own an API (the interface other software uses to connect to their system) and have a specific case: an AI assistant or agent is meant to do something in your system that ready-made integrations cannot. Most often that is:

• a SaaS product owner who wants customers to operate the product from Copilot, Claude or ChatGPT — without giving the AI the whole API;
• an in-house team responsible for shared company systems and data that has to make company data and functions available to AI assistants and agents in a safe, repeatable way;
• a delivery partner whose project is missing one controlled connection between the AI and their client's system.

On your side we need someone who owns that API and takes the deployment decision — they accept the integration and carry it forward.

What MCP is — and why the protocol is not the point

MCP (Model Context Protocol) is an open standard that lets an AI assistant use the functions of your system, such as "find a business partner" or "create an order for approval". A small program runs on your system's side, called an MCP server. It describes what each function does and what input it needs. The assistant (Claude, ChatGPT, Copilot Studio or your own agent) uses those functions without a separate integration for every program. We compared the four ways of connecting AI to company systems, this one included, in our note on integrating AI with ERP and CRM systems.

The standard itself is not hard — there are libraries to spare and thousands of public servers. What is hard is what the server should expose, to whom, with which permissions, and what happens when an action fails. If a ready-made integration does not do what you need, what is usually missing is not the MCP standard itself but three things: functions described in your company's own terms, control over who can access what, and tests. That is what we build.

We are also preparing an open reference example of such a server for one of the Polish business systems — so that the way we work can be inspected in code before you commission anything.

The smallest scope we start with

The first project is deliberately small: it quickly gives you a working, tested connection that the next stages build on:

• one existing API — we work with the one you already have, without rebuilding it;
• one AI app — the one you will actually use;
• a handful of named operations, chosen for one use case;
• read-only first, or operations gated behind human approval; unattended writes only after acceptance;
• a test environment and a test account — a public service shared by many customer organisations comes in a later stage.

Extending it with further operations, a second AI app or changing data in everyday use is a separate, separately priced stage.

What you get

• Each function described in your company's terms: names, inputs and explanations the AI understands the same way your team does.
• Consistent, predictable error handling, large results split into pages, and result limits.
• Identity checks integrated with your system: the server checks that the access token (a digital pass) was issued for it and does not forward tokens received from the AI app.
• Permissions per user and per customer organisation, checked on every action: without them, the action does not run.
• Separate read and write actions. Repeating an action does not create a duplicate.
• An activity log, with sensitive data removed or masked.
• Acceptance tests run against the chosen AI app.
• An installation package, a deployment guide and an operating guide for the person who will look after it.

All of it lands in your repository. After handover your team runs the integration on its own — that is one of the conditions of our delivery methodology.

Security: the baseline we do not go below

• The server does not forward tokens received from the AI app to your API. It connects using its own verified identity.
• Your system's permissions enforced on every action, not once at login.
• Least privilege — a read function has no write rights.
• Passwords, keys and other credentials never go into instructions to the AI or into activity logs.
• No arbitrary network or file operations — only those specified in the function's description.
• Limits on the number of actions, on cost and on time.
• Content fetched from the system never becomes an instruction to the AI — an instruction hidden in a product description, an e-mail or a document is treated as data.

The MCP specification says function descriptions and returned content are to be treated as untrusted; we treat what a user can type the same way. Where the data goes, and who the controller is then, is set out on our security and GDPR page.

Acceptance: what we check before we say it works

Acceptance is a list of cases the integration has to handle correctly — agreed before the build and run as tests:

• allowed operations execute, and disallowed ones are rejected with a readable error;
• a user from one customer organisation cannot see another organisation's data;
• expired or revoked credentials block the action;
• a repeated write action does not create a duplicate;
• if your system is partly down, the action ends with a controlled error and the AI app does not hang;
• invalid input is rejected before it reaches your API;
• malicious content in data from the system, such as a hidden instruction, does not change what the AI does;
• cost and time limits stop the action when they are exceeded.

The list is part of the contract, and we test every case before acceptance. On the day of acceptance you know exactly what the integration handles.

How we protect your system during the implementation

• We expose only the functions chosen for the use case, not the whole API.
• We use the way your system already checks identities, so accounts and access stay where they are today.
• We start in a test environment, and launch a public service for many customer organisations in a later stage.
• We enable changing data in everyday use only after approval and acceptance.
• After handover your team maintains the integration from the operating guide, and for changes to the AI model, the AI app or the API we offer care after handover.

A project delivers best when there is a specific AI app, a team that will use the integration, an API owner on your side and planned maintenance — we settle these together before the start. The security and hand-over principles we apply on every project are set out in our standards.

When a plain API is enough

We match the type of connection to the case and tell you plainly when a simpler solution is enough. A plain API — or a ready-made integration — is enough when:

• your own software uses the API, rather than AI choosing functions itself — a rules-based integration is cheaper and easier to test;
• the order of steps is known in advance — then it is a job for AI automation, not for functions the AI chooses itself;
• your system or the chosen AI app already has an official integration that performs the operations you need — more and more systems do;
• there is only one AI app and one operation — an MCP server pays off only when one integration is meant to serve several AI apps or several tasks.

An MCP server makes sense when the other side is an AI model or an agent that chooses its own functions — that is, when permissions (who can access what) and tests matter more than the connection itself. When an agent makes sense at all is covered under AI agent implementation; the integration itself is also often one stage of a wider AI implementation.

Scope and price

Frequently asked questions

What is MCP, and is it the only way to integrate AI with our system?

MCP (Model Context Protocol) is an open standard that lets an AI assistant use the functions of your system. A small program on your system's side, called an MCP server, describes what each function does and what input it needs. The assistant (Claude, ChatGPT, Copilot Studio or your own agent) uses those functions without a separate integration for every program. It is one of several routes we match to the case: other cases are solved by a direct connection to the API, an intermediary automation tool such as n8n, or, as a last resort, a software robot (RPA) that clicks through an application the way a person would. An MCP server makes sense when an AI model or agent that chooses its own functions uses the system, and when one integration is meant to serve several AI apps or several tasks.

We have a well-documented API. Why would we also need an MCP server?

If your own software uses the API, we build a rules-based integration — it is cheaper and easier to test. An MCP server is worth having when AI is to use the API and choose the functions itself. AI does not read documentation the way a developer does. It picks functions by their names, descriptions and the input they require. So every action has to be described in the terms your company uses, limited by permissions checked every time, and tested. The tests also cover cases that ordinary API testing does not cover, such as malicious content, including a hidden instruction to the AI in data returned by the system.

Will the AI have access to our data?

Only to what the functions you deliberately make available return. We design them narrowly: a read function has no write rights, a user from one customer organisation cannot see another organisation's data, and your system's permissions are checked on every action rather than once at login; an action without the required permissions does not run. Fragments of data reach the AI model provider you choose, on its terms. Where they go, and who the controller is then, is set out on our security and GDPR page. Passwords, keys and other credentials never go into instructions to the AI or into activity logs.

Which AI assistants does this work with?

Any AI app that supports MCP — today that includes Claude, ChatGPT, Microsoft Copilot Studio, Claude Code and many agent platforms — and your own agent. We build and test the first stage on one AI app: the one you will actually use. We add a second app as a further stage and test it separately, because apps differ in whether they ask the user for consent before each use of a function.

What does it cost and how long does it take?

We set the scope and the price after seeing your API documentation and one written-up use case — naming the AI app, the list of actions and the person on your side who will accept the result. Pricing is per stage, at a fixed scope and a fixed price: the first stage covers one API, one AI app and an agreed list of acceptance tests, and is usually counted in weeks rather than months. Third-party licences and API usage, including the model, sit outside the quote.