Zum Hauptinhalt springen
Connic
Zurück zum BlogAnkündigung

Connic MCP ist da: Connic mit einem Coding-Agenten steuern

MCP-Coding-Agenten wie Codex, Claude Code oder Cursor lassen sich mit einem Connic-Projekt verbinden. Sie können Runs debuggen, Deployments veröffentlichen und Agenten direkt aus dem Editor verwalten.

10. August 20267 Min. LesezeitAutor: Connic Engineering

Heute veröffentlichen wir Connic MCP: die direkte Verbindung zwischen einem Coding-Agenten und einem Connic-Projekt. MCP-fähige Clients wie Codex, Claude Code und Cursor können jetzt Live-Runs, Traces und Logs lesen, Deployments veröffentlichen und das Projekt in demselben Chat verwalten, in dem sie die Agenten schreiben. Der Umweg über das Dashboard entfällt.

Der gesamte Entwicklungsablauf in einem Chat

Coding-Agenten konnten Connic-Agenten bereits gut schreiben: YAML, Tools und Middleware. Beim Betrieb sah es anders aus. Um herauszufinden, warum ein Run fehlgeschlagen war oder welches Ergebnis die Tests eines Deployments geliefert hatten, mussten Entwickler vom Editor ins Dashboard wechseln, die Antwort lesen und eine Zusammenfassung zurück in den Chat schreiben. Der Client, der den Code erstellt hatte, konnte das laufende System nicht sehen. Jetzt kann er direkt nachfragen. Praktisch möglich wurde das mit dem MCP Release vom 28.07.2026. Es ist die erste Protokollrevision, der wir zwischen einem Coding-Agenten und dem Produktivbetrieb vertrauen. Connic MCP basiert darauf und bietet einen Fallback für Clients mit dem älteren Protokoll.

Einen Agenten auf Connic zu entwickeln war bereits schnell. Langsam war alles drumherum: prüfen, ob die Tests des Deployments erfolgreich waren, die fehlgeschlagenen Runs der vergangenen Nacht untersuchen oder bestätigen, dass sich die neue Version tatsächlich besser als die alte verhält. Connic MCP holt diese Arbeit in den vorhandenen Entwicklungs-Chat.

Direkt im Kontext debuggen
„Warum ist der Refund Agent vergangene Nacht fehlgeschlagen?“ Der Coding-Agent lädt die fehlgeschlagenen Runs, liest die Traces, findet den fehlerhaften Tool Call und schlägt im selben Gespräch eine Korrektur vor.
Veröffentlichen und prüfen
Die Korrektur geht ohne Fensterwechsel live: Deployment erstellen, Tests beobachten und die neue Version nach erfolgreichem Abschluss aktivieren.
Fragen statt suchen
Gestrige Kosten pro Agent, die Queue in Staging oder der Zustand einer Verbindung: Fragen, für die zuvor Dashboard-Tabs nötig waren, brauchen jetzt eine Zeile im Chat.

Ein Agent, der echte Traces sieht, schreibt bessere Korrekturen als einer, der nur die Umschreibung eines Fehlers kennt. Kann er Deployment Tests beobachten, iteriert er bis zum Erfolg, statt die Prüfung an einen Entwickler zurückzugeben. Jeder selbst verifizierte Schritt beseitigt eine manuelle Übergabe.

Was ein Coding-Agent tun kann

Die Verbindung deckt die Connic-Plattform durchgängig ab. Sie liest und verändert dieselben Bereiche, die auch im Dashboard verfügbar sind:

BereichAnzeigenAktionen
Agenten und RunsRuns, Traces, Logs sowie Vorschauen von Input und OutputEinzelne oder mehrere Runs abbrechen oder erneut ausführen
DeploymentsDeployments, Tests und Deployment RunsErstellen, abbrechen, aktivieren und erneut deployen
VerbindungenDefinitionen, Verknüpfungen, Runs, Statistiken und LogsErstellen, aktualisieren, löschen und mit Agenten verknüpfen
RetrievalNamespaces, Einträge, Quellen und StatistikenInhalte hochladen sowie Quellen verwalten und synchronisieren
DatabaseStatistiken, Collections, abgeleitete Schemas sowie vollständige Dokumentabfragen und ZählergebnisseVorhandene Zeilen aktualisieren; Dokumente und Collections löschen
SessionsGespeicherter Session-Zustand, Agenten- und Nutzeridentität sowie ZeitstempelSuchen und filtern; einzelne oder passende Sessions löschen
Approvals und ChannelsAusstehende Approvals, Routing und ChannelsCalls genehmigen oder ablehnen, Routing und Channels verwalten
Judges und A/B TestsJudge-Statistiken und -Runs, Varianten und VergleicheJudges und Tests verwalten, Bewertungen zur Ausführung vormerken
Budgets und AuditKostenübersichten, Rankings und Audit EventsBudget Alerts verwalten
Environments und KI-GovernanceEnvironments, Health und KI-Governance RecordsEnvironments und Governance Records verwalten

Einen Client mit einem Befehl verbinden

Zur Einrichtung genügt ein Befehl, gefolgt von der Anmeldung mit einem Connic-Account im Browser:

# Codex
codex mcp add connic --url https://mcp.connic.co/mcp
codex mcp login connic

# Claude Code
claude mcp add --transport http --scope user connic https://mcp.connic.co/mcp

# Cursor Agent, after installing the Connic plugin
cursor-agent mcp login connic

Wir empfehlen das Connic-Plugin. Es bündelt diese Verbindung mit dem Connic-Skill, sodass der Client sowohl Connic-Agenten schreiben als auch das Projekt bedienen kann, in dem sie laufen. Der Einrichtungsleitfaden erklärt die Installation des Plugins in Codex, Claude Code, Cursor und OpenCode sowie die manuelle Verbindung anderer MCP-kompatibler Clients.

Verbinde einen Coding-Agenten mit Connic

Das Connic-Plugin oder eine direkte Connic-MCP-Verbindung ermöglicht dem Client, an dem System zu arbeiten, das er entwickelt.

Coding-Client einrichten

Projektmitglieder behalten die Kontrolle

Einen Client zu verbinden, übergibt ihm nicht automatisch uneingeschränkten Zugriff auf ein Projekt. Bei der Genehmigung legen Projektmitglieder das sichtbare Projekt, die Environments und die erlaubten Aktionen fest. Ein Client kann nie mehr als der genehmigende Account; ändert sich dessen Zugriff, ändert sich auch der des Clients. Unter den Projekt-Settings stehen für jede Verbindung die Berechtigungen und der Zeitpunkt der letzten Nutzung. Über MCP ausgelöste Projektaktionen folgen demselben Audit-Verhalten wie entsprechende API-Aktionen, während Traffic auf Request-Ebene in Service Logs bleibt. Ein Klick widerruft die Verbindung.

Einige Möglichkeiten sind bewusst nicht vorhanden. Ein verbundener Client kann weder Projektgelder ausgeben noch Zugangsdaten lesen, ein Projekt löschen oder Agenten-Runs starten. Wenn externe Systeme Agenten auslösen sollen, ist eine Verbindung der dafür vorgesehene Weg im Produktivbetrieb. API-Keys sind ebenfalls nicht beteiligt und gehören weder in eine MCP-Konfiguration noch in einen Chat.

Drei Einsatzmöglichkeiten für MCP

Wir unterstützen MCP jetzt an drei Stellen. Jede davon erfüllt einen anderen Zweck:

MCP-Server in Agenten
Ein bereitgestellter Agent nutzt externe MCP-Server als Tools, die in seiner YAML unter mcp_servers deklariert sind. Der Agent kann die Tools dieser Server aufrufen.
MCP-Server-Verbindung
Die Verbindung stellt bereitgestellte Agenten als MCP-Tools bereit, die externe Clients aufrufen können. Externe Clients können diese Agenten als Tools aufrufen.
Connic MCP
Ein Coding-Client bedient die Plattform selbst: Runs, Deployments, Verbindungen und Budgets. Der Client führt die freigegebenen Verwaltungsaktionen im Projekt aus.

Connic MCP fügt einem bereitgestellten Agenten keine Tools hinzu und stellt einen Agenten nicht als Tool bereit. Die beiden Anwendungsfälle beschreiben der Leitfaden zu MCP-Servern für Agenten und die Referenz zur MCP-Server-Verbindung.

Erste Schritte

  • 1.Installiere das Connic-Plugin für den Client oder füge https://mcp.connic.co/mcp direkt hinzu. Der Leitfaden zur Einrichtung von KI-Agenten enthält die genauen Befehle.
  • 2.Genehmige die Verbindung im Browser: Wähle Projekt und Environments und lege die erlaubten Aktionen fest.
  • 3.Stelle dem Agenten eine Frage, für die bisher das Dashboard geöffnet werden musste: der letzte fehlgeschlagene Run, der Status eines Deployments oder die gestrigen Kosten pro Agent.

Häufig gestellte Fragen

Connic MCP verbindet Coding-Agenten wie Codex, Claude Code und Cursor direkt mit einem Connic-Projekt. Der Agent kann innerhalb des bei der Genehmigung gewährten Zugriffs Runs, Traces und Logs lesen, Deployments und Verbindungen verwalten, über Approvals entscheiden und Kostenfragen direkt im Chat beantworten.

Für Codex, Claude Code, Cursor und OpenCode ist die Einrichtung mit einem Befehl dokumentiert. Auch jeder MCP-kompatible Client funktioniert, der sich mit Remote-Servern und einer Anmeldung im Browser verbinden kann. Der Leitfaden zur Einrichtung von KI-Agenten auf connic.co deckt jeden Client ab.

Nein. Die Einrichtung verwendet eine Anmeldung mit einem Connic-Account im Browser und eine anschließende Genehmigung der Verbindung. Ein Connic API-Key gehört niemals in eine MCP-Konfiguration oder einen Chat; kein Einrichtungsweg benötigt einen.

Nein. Über Connic MCP lässt sich bewusst kein Agenten-Run starten. Ereignisgesteuerte Runs nutzen Verbindungen, den für externe Trigger im Produktivbetrieb vorgesehenen Weg. Wo es erlaubt ist, kann Connic MCP vorhandene Runs abbrechen und erneut ausführen.

Genau auf den bei der Genehmigung erlaubten Bereich: ein Projekt, alle oder ausgewählte Environments und Read-only- oder Read-and-act-Zugriff. Ein Client kann nie mehr als der genehmigende Account. Unter Projekt-Settings lässt sich jede Verbindung prüfen oder widerrufen.

Nein. Die MCP-Server-Verbindung stellt bereitgestellte Agenten als MCP-Tools bereit, die externe Clients aufrufen können. Connic MCP zeigt in die andere Richtung: Es gibt einem Coding-Client abgegrenzten Zugriff auf die Plattform, auf der die Agenten laufen. Beide funktionieren unabhängig voneinander und lassen sich gemeinsam verwenden.

Mehr aus dem Blog

Ankündigung

Connic KI-Modelle: EU-Hosting ohne zusätzliche Konfiguration

Connic KI-Modelle bündeln 30 EU-gehostete Modelle von neun Providern hinter einheitlichen connic/*-IDs. In der Agenten-YAML reicht eine Zeile aus; Provider-Konto, API-Key und Regionsangabe entfallen.

30. Juli 202610 Min. Lesezeit
Ankündigung

Der Connic Marketplace ist da

Im Connic Marketplace finden sich Agenten-Templates, Verbindungen und Retrieval-Quellen in einem Katalog mit Publisher-Modell und Installation per CLI.

5. Juli 20265 Min. Lesezeit
Branchen-Insights

Webhook vs. Kafka vs. SQS vs. Postgres als Auslöser für KI-Agenten

Webhook, Kafka, SQS und Postgres LISTEN/NOTIFY als Auslöser für KI-Agenten im Vergleich: Zustellgarantien, Reihenfolge, erneute Verarbeitung, Latenz und Fehlerverhalten.

29. Juni 20269 Min. Lesezeit
Changelog

Was wir im Mai 2026 veröffentlicht haben

Testframework für Agenten, Deployment Gates mit Pull-Request-Tests, detaillierteres Tracing für ausgelöste und untergeordnete Runs, Usage- und Budget-Dashboards, eigene Domains für Verbindungen und Reasoning Effort pro Agenten mit vererbten Standardwerten.

1. Juni 20267 Min. Lesezeit
Produkt im Fokus

Connic Tests: Regressionen vor dem Produktivbetrieb erkennen

Ein YAML-basiertes Testframework für KI-Agenten mit schwankenden Ergebnissen: wiederholte Testläufe, flexible Assertions, Mocks und multimodale Fixtures. Fehlgeschlagene Tests blockieren standardmäßig das Deployment.

6. Mai 20268 Min. Lesezeit
Produkt im Fokus

Connic Bridge: KI-Agenten für private Infrastruktur

Connic Bridge stellt einen sicheren ausgehenden Tunnel bereit, über den KI-Agenten private Kafka-Cluster, Datenbanken und interne Dienste ohne offene eingehende Ports erreichen.

19. Februar 20267 Min. Lesezeit
Changelog

Was wir im Januar 2026 veröffentlicht haben

Eigene Observability-Dashboards mit Drag-and-drop-Widgets, KI-Modellpreise zur Kostenkontrolle, überarbeitete Verbindungs- und Runs-UI sowie Unterstützung für llms.txt.

10. Februar 20265 Min. Lesezeit
Produkt im Fokus

Observability für Agenten: Kosten, Tokens und Runs erfassen

Eigene Dashboards machen LLM-Kosten pro KI-Modell und Fehler sichtbar, bevor Nutzer die Folgen bemerken.

23. Januar 20268 Min. Lesezeit
Changelog

Was wir im September 2025 veröffentlicht haben

Vollständige Audit Logs mit Vorher-Nachher-Diffs, eine wählbare Datenresidenzregion, verteilte Rate Limits für Verbindungen und eine detaillierte Kostenaufschlüsselung im Billing.

1. Oktober 20254 Min. Lesezeit