MCP Server
Connic veröffentlicht den Agenten mit automatisch generiertem Schema als MCP Tool. Cursor, Claude Desktop, Partner-Apps und andere Agenten können ihn direkt aufrufen: dieselbe Logik, keine zweite Implementierung.
Überblick
Über das Model Context Protocol entdecken KI-Anwendungen externe Tools und rufen sie auf. Die MCP-Server-Verbindung stellt Connic Agenten auf der Server-Seite dieses Protokolls bereit: Jeder verknüpfte Agent wird als Tool mit generiertem Input-Schema bereitgestellt. Ein standardmäßiger tools/list Aufruf listet die Tools auf, tools/call führt sie aus. MCP Clients wie Claude Desktop, Cursor, das Produkt eines Partners oder der Agent eines anderen Teams können den Agenten ohne eigene API-Integration verwenden.
Damit bedient ein Deployment gleichzeitig drei Zielgruppen. Das Team ruft den Agenten aus Coding Tools auf, Partner nutzen ihn als Funktion in ihren KI-Produkten und andere Agenten binden ihn zur Laufzeit ein. Logik, Tracing und Zugriffskontrolle des Agenten bleiben an einer Stelle; verschiedene Anwendungen können denselben Agenten aufrufen. Der Vergleich von MCP Server, Verbindung und Client hilft bei der Wahl der Integrationsrichtung.
So funktioniert es
Verbindung erstellen und Modus wählen
Füge im Verbindungsdiagramm des Agenten eine MCP-Server-Verbindung hinzu. Sync wartet auf den Abschluss des Agenten und gibt das Ergebnis zurück (bis zu 5 Minuten). Inbound gibt sofort eine Run ID zurück und verarbeitet längere Aufgaben im Hintergrund.
Agenten als Tools verknüpfen
Jeder verknüpfte Agent wird als MCP Tool mit standardisiertem Schema bereitgestellt: ein erforderliches message-Feld und ein optionales strukturiertes payload-Objekt, die der Agent über Template-Variablen liest. Namen der Agenten werden automatisch zu Tool-Namen.
Endpoint in einen MCP Client eintragen
Die Verbindung erzeugt eine eindeutige Endpoint URL und einen Secret Key. Nach dem Eintragen in den MCP Client erscheinen die Agenten in dessen Tool-Liste. Aktuelle und ältere MCP-Lifecycles werden unterstützt.
Muster für den Produktivbetrieb
Muster für den Produktivbetrieb, bei denen Connic Queues, Worker und Scheduler betreibt.
Partner ruft den Agenten auf
mcp://your-product/agentJeder Partner erhält eigene Zugangsdaten, Rate Limits und Metering. Dessen KI-Tools rufen den Agenten wie jede andere Funktion auf. So entsteht eine bezahlte API ohne eigene Implementierung.
Partner ruft den Agenten auf
mcp://your-product/agentJeder Partner erhält eigene Zugangsdaten, Rate Limits und Metering. Dessen KI-Tools rufen den Agenten wie jede andere Funktion auf. So entsteht eine bezahlte API ohne eigene Implementierung.
Haupt-Agent braucht Unterstützung
mcp://internal/pricingAgenten für Preisberechnung, Lagerbestand und Versand werden unabhängig voneinander veröffentlicht. Ein koordinierender Agent ruft sie als MCP-Tools auf, sodass jedes Deployment unabhängig bleibt und kein Monolith entsteht.
Haupt-Agent braucht Unterstützung
mcp://internal/pricingAgenten für Preisberechnung, Lagerbestand und Versand werden unabhängig voneinander veröffentlicht. Ein koordinierender Agent ruft sie als MCP-Tools auf, sodass jedes Deployment unabhängig bleibt und kein Monolith entsteht.
Kunde verbindet einen Agenten
mcp://customer/custom-logicKunden registrieren eigene Agenten als MCP Tools im Produkt und erweitern den Workflow um interne Logik, während die grundlegende Bedienung des Produkts gleich bleibt.
Kunde verbindet einen Agenten
mcp://customer/custom-logicKunden registrieren eigene Agenten als MCP Tools im Produkt und erweitern den Workflow um interne Logik, während die grundlegende Bedienung des Produkts gleich bleibt.
CRM Agent benötigt Abrechnungsdaten
mcp://billing/lookupDer CRM-Agent fragt die Zahlungshistorie beim Abrechnungsagenten ab, dieser wiederum offene Tickets beim Support-Agenten. Jedes Team besitzt seinen Agenten; MCP setzt sie zur Laufzeit zusammen.
CRM Agent benötigt Abrechnungsdaten
mcp://billing/lookupDer CRM-Agent fragt die Zahlungshistorie beim Abrechnungsagenten ab, dieser wiederum offene Tickets beim Support-Agenten. Jedes Team besitzt seinen Agenten; MCP setzt sie zur Laufzeit zusammen.
Authentifizierung und Zugriff
Jede Anfrage enthält den Secret Key der Verbindung entweder als Authorization: Bearer Header oder als X-Connic-Secret Header. Die Authentifizierung ist standardmäßig aktiviert und kann für vertrauenswürdige Netzwerke deaktiviert werden. Jede Verbindung besitzt einen eigenen Endpoint und ein eigenes Secret. Dadurch teilen Partner- und interne Integrationen keine Zugangsdaten, und das Sperren einer Integration betrifft keine andere.
Jeder Tool-Aufruf ist im Hintergrund ein normaler Agent Run: Er erscheint in der Run History mit vollständigen Traces, Token- und Kosten-Tracking sowie denselben Guardrails und Approval-Regeln wie jeder andere Trigger.
So sieht ein Tool-Aufruf aus
Unter MCP 2026-07-28 verwendet die Verbindung zustandslose Anfragen und server/discover für Capabilities, tools/list für verknüpfte Agenten und tools/call für den Aufruf. Derselbe Endpoint unterstützt frühere Streamable-HTTP-Versionen mit initialize und ping sowie den ursprünglichen GET/SSE-Transport für bestehende Clients. Ein Call enthält das erforderliche Feld message und optional ein payload Objekt, auf das der Agent als Template-Variablen zugreift. Der Agent kann dadurch direkt auf strukturierte Daten zugreifen, ohne sie erst aus einem Text auslesen zu müssen. MCP-Dokumentation: Anfrage- und Antwortformate.
Informationen
- Publisher
- Von Connic
- Verbindungen
- Verbindungen
- Modi
- Inbound, Sync
- Dokumentation
- MCP Server Docs
Häufig gestellte Fragen
server/discover, tools/list und tools/call; initialize und ping bleiben ausschließlich für ältere Clients verfügbar.Beschreibe die Event-Quelle, die Struktur der Payload, das Ziel für die Ergebnisse und die Anforderungen an private Netzwerke oder Freigaben. Wir helfen, MCP Server mit dem passenden Verbindungsmodus, Deployment und Monitoring in Connic einzurichten.
Sprich mit Sales