Eigenen Konnektor anbinden
Ein eigenes System wird als Konnektor angebunden: ein Dienst, der eine überschaubare Zahl von Werkzeugen anbietet und dahinter die Schnittstelle Ihres Systems aufruft. Angelegt und freigegeben wird er im Admin-Panel, ohne Zugriff auf den Server.
Was Sie vorher klären
Abschnitt betitelt „Was Sie vorher klären“- Der technische Name. Unter diesem Namen läuft der Konnektor in Ihrer Instanz. Er lässt sich später nicht ohne Weiteres ändern. Wählen Sie ihn also sprechend und dauerhaft.
- Die Adresse, unter der der Konnektor MCP spricht. Der Dienst muss aus Ihrer Instanz heraus erreichbar sein.
- Die Zugangsdaten zum Zielsystem. Sie gehören nie im Klartext in die Konfiguration, sondern ausschliesslich als Referenz auf einen hinterlegten Schlüssel.
- Das Konto hinter den Zugangsdaten. Es ist die eigentliche Datengrenze. Geben Sie ihm im Zielsystem genau die Rechte und genau die Bereiche, die der Anwendungsfall braucht, siehe Muster für Konnektoren.
- Eine kurze Anleitung in Prosa dazu, wann dieses Werkzeug benutzt werden soll und was es nicht kann. Sie wird nur eingefügt, wenn der Konnektor aktiv ist, und verbessert die Trefferquote spürbar.
Woher bekomme ich einen MCP-Server für mein System
Abschnitt betitelt „Woher bekomme ich einen MCP-Server für mein System“Es gibt fertige Server für viele Produkte. Weil MCP ein offener Standard ist, veröffentlichen Hersteller und Communities Konnektoren für gängige Software. Suchen Sie nach dem Produktnamen zusammen mit „MCP server“. Für Systeme mit eigener Programmierschnittstelle ist die Chance gut, dass jemand die Brücke schon gebaut hat.
Sie können einen eigenen bauen. Ein Konnektor ist ein kleiner Dienst, der eine Handvoll Werkzeuge anbietet und dahinter die Schnittstelle Ihres Systems aufruft. Für einen begrenzten Zweck, etwa „fünf Leseabfragen auf unsere Fachanwendung“, ist das überschaubar. Eine bewusst schmal gebaute Brücke ist im Kontext deutlich günstiger als ein fertiger Server mit hundert Werkzeugen.
Prüfen Sie einen fremden Server, bevor Sie ihn anschliessen. Ein Konnektor bekommt Zugriff auf Ihre Daten, das ist keine Formalität. Vier Fragen:
- Welche Werkzeuge exponiert er? Lesen Sie die Liste vollständig. Schreibende Werkzeuge, die Sie nicht brauchen, sind reines Risiko und kosten dazu Kontext.
- Gibt es einen Nur-Lese-Modus? Ein Schalter, der Schreibzugriffe im Code abschaltet, ist deutlich mehr wert als der Vorsatz, sie nicht zu benutzen.
- Ist er für mehrere Nutzer geeignet? Konnektoren, die sich einen Zustand über mehrere Aufrufe merken, funktionieren im Mehrbenutzer-Betrieb nicht zuverlässig.
- Wo liegen die Zugangsdaten und wie ist die Lizenz? Ein Konnektor, der selbst Schlüssel hält, gehört ausschliesslich ins interne Netz.
Das Ergebnis dieser Prüfung kann durchaus „wir bauen selbst“ lauten, gerade wenn ein fertiger Server neben dem Lesen auch Neustarts, Skriptläufe oder schreibende Änderungen anbietet und sich das nicht abschalten lässt. Wie eine schmale Brücke zugeschnitten wird, steht unter Muster für Konnektoren.
Freigabe ist ein eigener Schritt
Abschnitt betitelt „Freigabe ist ein eigener Schritt“Ein angelegter Konnektor ist noch kein freigegebener Konnektor.
Prüfen Sie die Freigabe zum Schluss mit zwei Testpersonen mit unterschiedlichen Rechten. Sehen beide dasselbe, greift Ihre Rechtegrenze nicht.
Wenn etwas nicht funktioniert
Abschnitt betitelt „Wenn etwas nicht funktioniert“- Ein Werkzeug meldet „Zugriff verweigert“. Das ist kein Fehler, sondern die Rechteregel. Prüfen Sie die Freigaben für die betroffene Person, siehe Rechte und Freigaben.
- Der Konnektor antwortet nicht. Prüfen Sie zuerst, ob der Dienst aus Ihrer Instanz heraus erreichbar ist, und danach die hinterlegten Zugangsdaten zum Zielsystem.
- Die Prüfschritte im Einzelnen beschreibt die Anleitung, die Ihrer Auslieferung beiliegt. Sie führt auch den Verbindungstest auf, der eine Anbindung unabhängig von den Rechten prüft.