Your product is invisible to the AI your customers already use.

Your customers are moving their work into Claude, ChatGPT, Copilot and agents that run on their own. We build the MCP server that lets all of them use your product: designed for models, secured to spec, proven with evals.

Talk to an engineer See it done right

30 minutes, with an engineer
Built to spec 2026-07-28

The interface moved. Your product didn't.

Work that used to happen in your UI is now asked of an agent. If the agent can't reach your product, your user leaves the conversation, or leaves you.

Every major AI
Claude, ChatGPT, Copilot, Gemini, Cursor and VS Code all speak MCP.: Linux Foundation
Governs MCP since December 2025, co-founded by Anthropic, OpenAI and Block.: ~500M
downloads a month of the official MCP SDKs.

One protocol, instead of an integration per agent.

Six agents and six systems used to mean 36 integrations. With MCP it's one server, and every client that speaks the protocol can use it.

Write it once. It works in all of them.

The same tool answers a person in Claude, a developer in their IDE and an agent that runs at 7:00 with nobody watching.

TSserver.tsTSerp-client.tsacme-erp-mcp

1import { erp } from "./erp-client";

2const server = new McpServer({ name: "acme-erp", version: "1.4.0" });

mainLn 4, Col 1TypeScript

Claudechat+ find_overdue_accountsacme-erp · 0 tools

How can I help today?

Reply…acme-erp

ChatGPTchat+ find_overdue_accountsacme-erp · 0 tools

What's on your mind?

Ask anythingacme-erp

VS CodeIDE agent+ find_overdue_accountsacme-erp · 0 tools

CHATAgent ▾12

Ask, or type # for tools

n8nworkflow+ find_overdue_accountsacme-erp · 0 tools

ScheduleMon 08:00

MCP Clientacme-erp

Slack#finance

Waiting for trigger

Your agentheadless+ find_overdue_accountsacme-erp · 0 tools

$agent serve --mcp acme-erp

waiting for next run

TSserver.tsacme-erp-mcp

1import { erp } from "./erp-client";

2const server = new McpServer({ name: "acme-erp", version: "1.4.0" });

mainTypeScript

Clientsacme-erp

ClaudeChatGPTVS Coden8nYour agent

Claudechat+ find_overdue_accountsacme-erp · 0 tools

How can I help today?

Reply…acme-erp

Your agentheadless+ find_overdue_accountsacme-erp · 0 tools

$agent serve --mcp acme-erp

waiting for next run

Who needs an MCP server first

Legacy software vendors
A modern front end, without rewriting twenty years of business logic.
Vertical and B2B SaaS
Your product inside ChatGPT, Claude and Copilot, not in another tab.
Companies with internal systems
Staff agents on your ERP and CRM, under your auth, scopes and audit trail.
New products
No dashboard to build. The conversation is the interface.

The catch: an MCP server is not an API with a new name.

An API is read once, by a developer. An MCP server is read on every request, by a model deciding what to call.

Who reads it

REST APIREST API: A developer, once, while writing an integration

MCP serverMCP server: A model, on every request, choosing between tools

Unit of design

REST APIREST API: Resources and endpoints

MCP serverMCP server: Jobs the user wants done

Documentation

REST APIREST API: A docs site for people

MCP serverMCP server: Names, descriptions and schemas are the prompt

Interaction

REST APIREST API: Request, response

MCP serverMCP server: The server can stop and ask the user, then continue; long work runs as a task

Budget

REST APIREST API: Bandwidth and rate limits

MCP serverMCP server: Tokens: every definition and every result spends the model's context

What most people implementing MCP do wrong

~55K
tokens of tool definitions from five common MCP servers, spent before the user types a word: 97.1%
of 856 audited MCP tools had at least one defect in their description: 30+ → 2
tools in Block's Linear server after it was redesigned around intents

01
Wrapping the REST API 1:1
What most teams ship
One tool per endpoint.
get_invoicelist_invoicescreate_invoiceupdate_invoicepatch_invoice_lineget_customerlist_customerssearch_customersget_customer_contactslist_paymentsget_paymentpost_payment_allocationlist_disputesget_disputelist_dunning_levelsget_dunning_levellist_templatesrender_templatelist_mailboxessend_messageget_account_balancelist_ledger_entriesget_fx_ratelist_currenciesget_companylist_warehousesget_stock_itemlist_stock_moveslist_price_listsget_price
212 tools6 calls per job
A generator turns 200 endpoints into 200 tools. The agent chains six calls to do one job and gets one of them wrong.
What we ship
One tool per job.
We start from what users actually ask for and fold the whole chain into one call that does it.
02
Flooding the context window
What most teams ship
Every tool, loaded on every turn.
context window · 200K tokens
tool definitions · ~55K before a word is typed
the actual task
raw results, refetched
accuracy drops as tools pile up
Definitions eat tens of thousands of tokens before the user types a word. Past a few dozen tools, the model starts picking the wrong one.
vs
What we ship
A handful of tools. The rest on demand.
context window · 200K tokens
tool definitions · ~3K
the actual task
free for the conversation
tools found when needed
A small, deliberate surface. For large APIs, progressive discovery or code execution instead of a flat list.
03
Returning raw payloads
What most teams ship
Whatever the API returns.
{ "data": [ { "cust_id": 88213, "cust_no": "K-0041", "inv_status_cd": 3, "dunning_lvl": 2, "created_ts": 1720512000, "upd_by": 117, "lines": [ { "art_id": 5531, "qty": 24, "uom_cd": "PCE", "vat_cd": "S25", ... } ], "addr": { "street": "...", "zip": "...", ... }, "_links": { "self": "/v2/invoices/99102", ... }}, { ... }, { ... }, ... 214 more ] }
48 KB~12K tokens
48 KB of JSON, internal IDs, every field. The model loses the thread, and you pay for every byte of it.
vs
What we ship
The answer, not the database.
Filtered, paginated, readable names, structured output with a schema: only what the next decision needs.
04
Schemas the model has to guess
What most teams ship
Accept object. Reply “400 invalid”.
The model guesses the shape, fails, and guesses again. Three calls, no progress, and a user watching it flail.
What we ship
Typed inputs. Errors that teach.
Typed schemas, introspection, and errors that state the valid input, so the model fixes itself in one turn.
05
Auth and security as plumbing
What most teams ship
Pass the user's token straight through.
One token, every scope, any audience: a confused deputy. And tool output the model reads as instructions.
What we ship
Scope every tool. Confirm every write.
OAuth to the current spec, tokens bound to your server, confirmation before destructive writes, and a prompt-injection review of every data path.
06
Shipping without evals
What most teams ship
Tried it once in Claude. Shipped it.
Nobody measures whether the agent picks the right tool with the right arguments, so every change is a guess.
What we ship
Proven on every change.
An eval suite of real tasks, run across models before launch and on every change after it.

What doing it right looks like

One request. The agent asks once, the server does the work across your system, and the model gets the answer, not the payload.

Tools6

Claudedesktop

You

Which customers are more than 30 days overdue? Post a summary to #finance.

choosing a tool...

Conversationclient

Claudedesktop

You

Which customers are more than 30 days overdue? Post a summary to #finance.

→tools/call#7mcp.acme-erp.com

{ "name": "find_overdue_accounts",

"arguments": { "min_days_overdue": 30 } }

←16 ms

Networktools/call · 4 upstream

NameStSizeWaterfallTime

0 ms50100150+100+2001.3s16 ms

find_overdue_accounts••16 ms

GET/invoices••4 ms

GET/payments••2 ms

GET/disputes••0 ms

bytes on the wireKB/ms, one scale · peak 0.88API → server0.0Kto the model0.00K

48.2 KB← 0.42 KB

Payloadresult

API → server—

raw JSON · 4 responsesstays on the server

find_overdue_accounts keeps 5 fields

Server → model—

structuredContent

{

"overdue": 7,

"total_eur": 184200,

"oldest": "Kovač d.o.o., 64 days",

"disputed": 1,

"top": ["Kovač", "Brenner", "Ilić"]

}

Server → model—

Context costsame scale

—

raw0 tok

model0 tok

tool call from the agent: 1
API calls, in parallel: 4
stays on your server: 48 KB
reaches the model: 0.4 KB

We learned this on our own product.

To learn where MCP breaks, we built Mailoo: a drip-email campaign engine with no dashboard and no login. You run it only through an AI assistant.

Product: Mailoo, campaign engine
Interface: MCP only
Status: Upheave R&D, not a client project

MCP tools: 21
screens: 0
agent-first design principles: 15
of them made obsolete by spec 2026-07-28: 4

A schema is the only documentation an agent has.

The lesson we design every server around

Read the full write-up

Five revisions in twenty months. We build to the latest.

Each one changed how a server is built. A server written in early 2025 is already on deprecated paths; we build to 2026-07-28 and migrate the ones that aren't.

2024-11-05
- Tools, resources, prompts
- stdio and HTTP+SSE transports
2025-03-26
- OAuth 2.1 authorization
- Streamable HTTP, replacing HTTP+SSE
- Tool annotations
2025-06-18
- Servers as OAuth resource servers (RFC 9728)
- Resource indicators (RFC 8707)
- Structured tool output
- Elicitation
- ~~JSON-RPC batching~~
2025-11-25
- Client ID Metadata Documents
- URL-mode elicitation
- Tasks, experimental
- Validation errors the model can act on
Current · we build here2026-07-28
- Stateless: no session, discovery per request
- Multi round-trip requests
- Tasks as an official extension
- Gateway routing headers, OpenTelemetry
- ~~Sessions and the initialize handshake~~
- ~~Dynamic Client Registration~~
- ~~Sampling, roots and logging~~
- ~~HTTP+SSE~~

Built on an older revision? What we change

Official SDKs we build with: TypeScript · Python · Go · C#

~~Mcp-Session-Id and in-memory session state~~Explicit handles, any instance serves any request
~~Dynamic Client Registration~~Client ID Metadata Documents
~~Server-initiated sampling and elicitation~~Multi round-trip requests
~~HTTP+SSE transport~~Streamable HTTP

From your product to a server agents use well

Four steps, each ending in something you can check. The core of your product doesn't change.

1Map
Jobs, not endpoints
We list what your users would ask an agent to do, and what data and permissions each job needs.
You getJob map
- Chase overdue accountsinvoices:read
- Quote from a price listquotes:write
- Book a technicianjobs:write
- Check free stockstock:read
- + 2 more jobs
Design
Tool surface and evals
Tools, schemas, result shapes and risk levels, plus the eval tasks that will judge them, before any code.
You getTool spec and eval set
3Build
Remote server, real auth
Streamable HTTP, OAuth against your identity provider, deployed in your cloud. Gateway and tracing included.
You getA running server
- mcp.acme-erp.com
- Streamable HTTP, stateless
- OAuth via your IdP
- Gateway + OpenTelemetry
- In your cloud
Prove
Evals, review, launch
Evals across models, a security review, and submission to the client directories you want to be in.
You getEval report

Questions engineers ask us

Short answers. The call is for the long ones.

We already have a REST API. Why an MCP server?

Your API serves developers who write integrations. An MCP server serves the agent your customer already uses, and it works in every MCP client without anyone writing an integration. It usually sits on top of your API rather than replacing it.

Can't we generate it from our OpenAPI spec?

You can, and it will work in a demo. Generated servers mirror endpoints, so the agent chains calls, burns context and picks the wrong tool. A generated list is a useful inventory to design from, not a design.

Which AI clients will it work with?

Any MCP client: Claude, ChatGPT (its apps are built on MCP), Microsoft Copilot Studio and Microsoft 365 Copilot, Cursor, VS Code and Gemini among them. Clients differ in which extensions they support, such as MCP Apps, and we test in the ones that matter to you.

Remote or local server?

Remote, over Streamable HTTP, for almost every product: one deployment, OAuth per user, and it works in web and mobile clients. Local (stdio) only when the server needs the user's machine, such as files or desktop apps.

How do you keep it secure?

Tokens are issued for your server and never passed through. Scopes are per tool, destructive tools ask for confirmation, and every call is traced. We also review where untrusted content meets private data, because tool output is input to a model. See the security best practices we build to.

The spec keeps changing. Will our server go stale?

It changes, but deliberately: 2026-07-28 made the protocol stateless and deprecated Dynamic Client Registration, with a twelve-month window before removal. We build to the current revision, and we migrate servers built on older ones.

We already have an MCP server. Can you help?

Yes. We audit it against real tasks with evals, cut and reshape the tool surface, fix auth, and migrate it to the current spec.

What should an agent be able to do with your product?

Tell us about the product and the jobs your users would hand to an agent. You get an engineer, not a sales call.

30 minutes on your product, your API and your users
An honest read on whether MCP is worth it for you yet
If it is, a first sketch of the tool surface

Who you will talk to

Mario Jurić

Co-founder & Partner

Building software since 2019, from Zagreb, Croatia.

Prefer email? Write to office@upheave.tech.