Was ist eine MCP-Verbindung? Eine praktische Definition

MCP-Server und MCP-Client sind Rollen im Protokoll. Ein Server stellt Tools bereit, ein Client entdeckt und ruft sie auf. Bei Connic ist die MCP-Server-Verbindung ausdrücklich das serverseitige Produkt, das Connic-Agenten als MCP-Tools veröffentlicht. Ein Connic-Agent, der einen externen MCP-Server nutzt, übernimmt über seine mcp_servers-Konfiguration die Client-Rolle.

Was ist das Model Context Protocol?

MCP ist ein offenes Protokoll, das den Zugriff von KI-Apps auf externe Tools, Daten und Prompts standardisiert. Anthropic stellte es im November 2024 vor. Es verbreitete sich schnell: OpenAI unterstützt MCP im Agents SDK, und Google-DeepMind-CEO Demis Hassabis bestätigte im April 2025 die Unterstützung durch Gemini und das SDK. Das Protokoll verwendet ein JSON-RPC-Client-Server-Design: Ein Server stellt Funktionen bereit, ein Client verbindet sich mit ihm und macht diese Funktionen für das KI-Modell verfügbar. Die vollständigen Details stehen in der MCP-Dokumentation.

Ohne gemeinsames Protokoll braucht jede KI-App eine individuell geschriebene Integration für jedes angebundene System. Mit MCP implementiert ein System einen Server, den kompatible IDEs, Chat-Apps und Agenten-Runtimes aufrufen können.

Die Einrichtungswege sind getrennt. Die Dokumentation erklärt die Einbindung externer MCP-Tools für die Client-Seite und die MCP-Server-Verbindung zur Veröffentlichung von Agenten als Tools.

Was ist eine MCP-Verbindung? Server- und Client-Seite

Im Alltag ist eine MCP-Verbindung ein vorkonfigurierter MCP-Server mit Endpoint-URL, Authentifizierung und Tools. In diesem Sinn verwenden Chat-Apps den Begriff: Hinter Verbindungen, die Clients wie Claude oder ChatGPT hinzugefügt werden, stehen MCP-Server (Liste unterstützter MCP-Clients). Server- und Client-Seite haben unterschiedliche Aufgaben:

Auf einer KI-Agenten-Plattform kommen beide Richtungen vor. Ein Agent nutzt externe MCP-Server, um Tools zu erhalten; dadurch wird die Agenten-Runtime zum Client. Die Plattform kann den Agenten auch selbst als MCP-Tool veröffentlichen. Dann steht er hinter einem Server, den andere Apps aufrufen. Ein produktiver Agent kann beide Rollen gleichzeitig nutzen.

MCP-Verbindung vs. eigene API-Integration: Wann passt was?

MCP ersetzt bestehende APIs nicht. Es beschreibt API-Operationen als Tools in einer Form, die jeder MCP-Client versteht. Die Entscheidung lautet, ob eine API in das Protokoll gekapselt oder individuell angebunden wird.

Eine typisierte Python-Funktion als Custom Tool ist einfacher, wenn die Integration keinen MCP-Server benötigt.

MCP-Tool-Calls werden während eines Runs vom Client initiiert. Ein Server kann das Ergebnis direkt zurückgeben; optionale Erweiterungen können längere Workflows abbilden. MCP dient nicht der Zustellung von Ereignissen. Soll ein externes Ereignis einen Agenten auslösen, etwa eine Stripe-Zahlung, eine Kafka-Nachricht oder eine PostgreSQL- NOTIFY-Nachricht, ist eine Ereignisverbindung mit den passenden Zustellgarantien erforderlich. Bei dieser Entscheidung hilft der Vergleich von Webhook, Kafka, SQS und Postgres als Trigger. Den größeren Zusammenhang erklärt unser Artikel über vorgefertigte Verbindungen. MCP ergänzt diese Verbindungsmuster.

Wie MCP-Verbindungen auf einer KI-Agenten-Plattform funktionieren

Wir implementieren beide Richtungen. Die folgenden Beispiele zeigen, wie jede Seite einer Verbindung in der Praxis aussieht.

MCP-Server nutzen: der Agent als Client

Um einem Agenten Tools von einem MCP-Server bereitzustellen, wird der Server in der Agenten-YAML aufgelistet. Zur Laufzeit verbindet sich die Plattform mit jedem Server, entdeckt dessen Tools und stellt sie dem KI-Modell neben den lokalen Agent-Tools zur Verfügung. Jeder MCP-Tool-Call wird im Trace erfasst und ist in den Run-Details sichtbar. Die Dokumentation zu Tool-Calls im Ausführungs-Trace erläutert die Details.

version: "1.0"

name: docs-assistant
type: llm
model: connic/kimi-k2.7-code-fast
description: "An assistant with access to library documentation via MCP"
system_prompt: |
  You are a helpful coding assistant with access to up-to-date
  library documentation through MCP tools.

# Connect to an MCP server
mcp_servers:
  - name: context7
    url: https://mcp.context7.com/mcp

Beim Verbindungsaufbau handelt Connic automatisch eine kompatible aktuelle oder ältere MCP-Protokollversion aus. Tool-Annotations, Structured Results und UI-Resource-Metadaten an Tools bleiben erhalten. Bestehende Auth-Header, Tool-Filter und das Routing über Bridge greifen weiterhin. Das ist unabhängig von der MCP-Server-Verbindung aus dem vorherigen Abschnitt, die einen Connic-Agenten für andere Clients bereitstellt.

Die Konfiguration deckt die genannten Aufgaben der Client-Seite ab: Auth-Header mit Secrets aus Variablen, ein Tool-Filter, der den Agenten auf bestimmte Tools beschränkt, und ein Discoverable-Flag für Server mit vielen Tools. Dieses Flag indexiert Tools für eine Suche bei Bedarf, statt alle in den Kontext des KI-Modells zu laden. Server in einem privaten Netzwerk sind über Connic Bridge erreichbar, ohne sie öffentlich freizugeben. In der MCP-Integrationsreferenz ist jedes Feld dokumentiert.

Agenten als Tools bereitstellen: die MCP-Server-Verbindung

Für die Gegenrichtung wird eine MCP-Server-Verbindung erstellt. Sie veröffentlicht verknüpfte Agenten als MCP-Tools. Beim Erstellen generiert die Verbindung eine Endpoint-URL und ein Secret. Jeder verknüpfte Agent wird zu einem Tool, dessen Schema eine erforderliche Nachricht und eine optionale strukturierte Payload akzeptiert. Derselbe Endpoint unterstützt das aktuelle zustandslose Protokoll 2026-07-28, frühere Streamable-HTTP-Revisionen und den ursprünglichen HTTP/SSE-Transport. Aktuelle Clients können vor ihrem ersten Tool-Request die optionale Methode server/discover aufrufen; Connic implementiert sie. Legacy-Clients beginnen mit initialize.

POST /mcp HTTP/1.1
Authorization: Bearer <connector-secret>
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: invoice_processor

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "invoice_processor",
    "arguments": {
      "message": "Process this invoice and extract the total",
      "payload": {
        "invoice_id": "INV-12345",
        "customer": "Acme Corp"
      }
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "your-mcp-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Das Beispiel zeigt die Streamable-HTTP-Header für einen Tool-Call mit 2026-07-28. Der Header MCP-Protocol-Version wählt die Revision, Mcp-Method spiegelt tools/call und Mcp-Name den Tool-Namen. Die Metadaten in clientInfo werden für Logging und Debugging empfohlen, sind unter 2026-07-28 aber nicht erforderlich.

Der Sync-Modus wartet bis zu fünf Minuten, bis der Agenten-Run abgeschlossen ist, und gibt das Ergebnis an den Aufrufer zurück. Der Inbound-Modus gibt sofort eine Run-ID zurück und lässt den Agenten im Hintergrund arbeiten. Inbound ist das Fire-and-forget-Verhalten von Connic und nicht die optionale MCP-Erweiterung für Tasks. Requests werden mit einem statischen Secret in einem Authorization-Bearer- oder X-Connic-Secret-Header authentifiziert; die Verbindung bietet keinen MCP-OAuth-Flow. Die Authentifizierung ist standardmäßig aktiv und sollte nur in vertrauenswürdigen Netzwerken deaktiviert werden. Das Setup der MCP-Server-Verbindung beschreibt die Anbindung eines Clients.

Unsere MCP-Server-Verbindung stellt ausschließlich MCP-Tools bereit. Resources, Prompts oder Subscriptions werden nicht bereitgestellt; auch die optionalen Erweiterungen für Tasks und MCP Apps sind nicht implementiert.