Connecting your own systems and line-of-business applications

Attach legacy software with a REST/SOAP/CMIS API to SovrGPT through a lean MCP bridge — no proprietary connectors.

SovrGPT talks to external systems exclusively through the Model Context Protocol (MCP) — an open standard through which a model can call tools. Legacy software (DMS, ERP, line-of-business applications, internal tools) usually offers a REST/SOAP/CMIS API, not MCP. The bridge in between is an MCP adapter, also called an "MCP bridge".

What is an MCP bridge?

An MCP bridge is a lean piece of middleware that translates between two languages:

Towards SovrGPT it speaks MCP (JSON-RPC over Streamable HTTP).
Towards your software it speaks that software's existing API (REST, OData, SOAP, CMIS, GraphQL …). A single bridge can serve several of these protocols at once — for example the VIS suite, which offers REST, OData, SOAP and CMIS.

It is not a proprietary connector and not a second product you have to buy — it is a thin translator that you (or your integration partner) operate in your own infrastructure. SovrGPT never gets direct access to your software; it only knows the bridge URL and a token.

Architecture at a glance

┌──────────┐   MCP (JSON-RPC)    ┌──────────────┐   REST/SOAP/CMIS   ┌────────────────┐
│ SovrGPT  │ ──────────────────▶ │  MCP bridge  │ ─────────────────▶ │ Legacy software│
│  (EU)    │ ◀────────────────── │ (your infra) │ ◀───────────────── │ (DMS/ERP/LOB)  │
└──────────┘   tool result       └──────────────┘   API response     └────────────────┘

The model decides in the chat to call a tool (e.g. "search for a case file").
SovrGPT sends an MCP tool call to the bridge URL (your endpoint).
The bridge translates the call into an API call to your software.
The API response is translated back into an MCP tool result.
The model composes the answer from it — with sources, where available.

Why a bridge — and not "REST directly"?

One standard instead of N special cases. SovrGPT only has to speak MCP; every peculiarity of your API is encapsulated by the bridge. New systems mean a new bridge, not a change to the platform.
You keep control. The bridge runs on your side. You decide which endpoints and fields are exposed — a curated subset instead of full access. Your software's credentials never leave your premises.
Sovereignty is preserved. Data flow: SovrGPT (EU) ↔ bridge (your infra) ↔ software (your infra). No hyperscaler in between.

Three ways to provide a bridge

Variant	Who operates the bridge?	When does it make sense?
A — the vendor ships MCP	Your software vendor provides an MCP endpoint itself	Increasingly common with modern SaaS tools (see Marketplace)
B — your own bridge	You or your partner operate a thin adapter in front of the REST API	Legacy software with an open API but without MCP
C — generic adapter	A standard bridge against an open standard (e.g. CMIS)	Several systems share the same standard

Connecting it in practice

Custom bridges are added like any other MCP server:

Deploy the bridge in your infrastructure (container/VM), reachable over HTTPS.
In SovrGPT, enter the bridge URL and a bearer token under Sidebar → Marketplace → Custom MCP.
The token is stored AES-256-GCM encrypted in the EU database (encrypted columns, org-scoped) — never visible client-side.
The bridge's tools appear in the composer immediately. Write actions can require confirmation per chat (confirm_writes).

Public-sector line-of-business applications

For public administration there are curated bridge templates against the open eGovernment standards — no proprietary connector needed:

Template	Standard	Purpose
VIS / DMS case file	CMIS (OASIS)	Search and read case files and documents in a public-sector DMS (VIS suite, nscale, Fabasoft …)
FIT-Connect	FIT-Connect (FITKO)	Standardised OZG application delivery into line-of-business systems

Because CMIS and FIT-Connect are open HTTP standards, one bridge covers several DMS products. Genuine connectors inside a specific line-of-business application remain a customer-specific integration project.

These public-sector templates are not visible to all organisations: a platform admin unlocks them per organisation through an entitlement (public-sector connectors). Corporate tenants do not see them.

Security

Token org-scoped & encrypted — only the server can decrypt it.
Least privilege — the bridge exposes only what it is meant to expose.
Confirmation required — write actions are confirmed per chat.
Audit — every tool call is logged (usage_events / audit log), including traceability for public administration.

More on the protocol and on editor clients: MCP server · ready-made connectors: Marketplace.