AI and MCP integrations for products and teams

Who this service is for

Teams that own an API and have a specific case: an AI assistant or agent is meant to do something in your system that the off-the-shelf connectors cannot. Most often that is:

• a SaaS product owner who wants customers to operate the product from Copilot, Claude or ChatGPT — without handing the model the whole API;
• an internal platform team that has to expose company data and functions to agents in a safe, repeatable way;
• a delivery partner whose project is missing one controlled connection between a model and the client's system.

There is one condition, and it is a hard one: someone on your side has to own that API and be able to take the deployment decision. Without that we would be building a connector to a system nobody will accept.

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

MCP (Model Context Protocol) is an open standard in which a server exposes the functions of a system as named tools with a described schema — "find a business partner", "create an order for approval" — and a client (Claude, ChatGPT, Copilot Studio, your own agent) calls them instead of a separate integration for every program. We compared the four patterns for connecting a model to company systems, this one included, in our note on integrating AI with ERP and CRM systems.

The protocol 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 a call fails. When an off-the-shelf connector cannot perform your case, what is usually missing is not the protocol but that layer: business semantics for the tools, access control, and tests. That layer 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, because only a working, tested connection tells you whether it is worth extending:

• one existing API — we do not build a new one and we do not rebuild the one you have;
• one client application — the one you will actually use, not "any MCP client";
• a handful of named operations, chosen for one use case — not the whole API;
• read-only first, or operations gated behind human approval; unattended writes only after acceptance;
• a test environment and a test account — not a public multi-tenant service.

Extending it with further operations, a second client or production writes is a separate, separately priced stage — not a default part of the first one.

What you get

• Tool schemas with business semantics — names, arguments and descriptions the model understands the same way your team does.
• Stable, predictable errors, plus pagination and result limits.
• Authentication integrated with your system, with audience validation of the token — the server does not pass the client's tokens downstream.
• Per-user and per-tenant permissions, enforced on every call.
• Separated read and write operations and safe retries — a repeated call does not create a duplicate.
• A call log with sensitive data redacted.
• Acceptance tests run against the chosen client.
• A deployment package, a deployment guide and a runbook for the person who will maintain it.

All of it lands in your repository. After handover you do not depend on us — that is one of the conditions of our delivery methodology.

Security: the baseline we do not go below

• No token passthrough — the server presents its own validated identity to your API, not a token handed over by the client.
• The target system's permissions enforced on every call, not once at login.
• Least privilege — a read tool has no write rights.
• Secrets out of prompts and out of logs.
• No arbitrary network or file operations — only those the tool declares.
• Limits on the number of calls, on cost and on time.
• Content fetched from the system never becomes an instruction to the model — an instruction injected into a product description, an e-mail or a document is treated as data.

The MCP specification says tool 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 of one tenant cannot see another tenant's data;
• expired or revoked credentials stop the call;
• a repeated write call does not create a duplicate;
• a partial outage of the target system ends in a controlled error, not a hung client;
• invalid arguments are rejected before they reach your API;
• malicious content returned by a tool does not change the model's behaviour;
• cost and time limits abort the call when they are exceeded.

The list is part of the contract. If it turns out during the work that a case cannot be handled, we say so before acceptance, not after.

What we do not do within this scope

• We do not expose "the whole API" — the tools are chosen for the use case.
• We do not build a new identity platform — we use the authentication your system already has.
• We do not launch a public multi-tenant service as the first step.
• We do not enable production writes without approval and without acceptance.
• We do not take over maintenance indefinitely — care after handover is a separate, bounded service.

We advise against the project when there is no specific client — no application and no team — that will use the integration; when nobody on your side owns the API; when there is no budget for maintenance; or when an off-the-shelf connector is simply enough. The full set of conditions under which we say no is collected on what we don't do.

When a plain API is enough

Not every connection to a model needs an MCP server. A plain API — or an off-the-shelf connector — is enough when:

• the consumer is your own code, not a model — a deterministic 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 tools called by a model;
• your system or the chosen client already has an official connector that performs the operations you need — more and more systems do;
• there is only one client and one operation — an MCP server pays off only when one connector is meant to serve several clients or several tasks.

An MCP server makes sense when the other side is a model or an agent that chooses its own tools — that is, when permissions and tests matter more than the transport 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 in which a server exposes the functions of a system as named tools with a described schema, and a client — Claude, ChatGPT, Copilot Studio or your own agent — calls them instead of a separate integration for every program. It is not the only way: a direct API call, an intermediate layer such as n8n, or RPA as a last resort solve other cases. An MCP server makes sense when the client side is a model or an agent that chooses its own tools, and when one connector is meant to serve several clients or several tasks.

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

If your own code uses the API, you do not need an MCP server — a deterministic integration is cheaper and easier to test. The server is needed when a model is to use the API: a model does not read documentation the way a developer does, it picks tools by their names, descriptions and schemas, so every operation has to be described with business semantics, bounded by permissions enforced on every call, and covered by tests a plain API does not have — for instance what happens when the returned content carries an injected instruction.

Will the model have access to our data?

Only to what the tools you deliberately expose return — and those are designed narrowly: a read tool has no write rights, a user of one tenant cannot see another tenant's data, and the target system's permissions are enforced on every call rather than once at login. Fragments of data reach the 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. Secrets appear neither in prompts nor in logs.

Which AI clients does this work with?

Any client 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 against one client: the one you will actually use. A second client is often a simple extension, but we do not assume so up front, because clients differ in whether they ask the user for consent before each tool call.

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 client, the list of operations 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 interface, one client 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.