Zum Hauptinhalt springen
Hilfecenter

Wie MCP in teamspace funktioniert

Das Baukastenprinzip hinter den MCP-Konfigurationen: warum viele kleine Zugänge besser sind als ein großer – und warum immer deine eigenen Rechte gelten.

teamspace bringt einen eigenen MCP-Server mit. Er ist aber kein fertiges, unveränderliches Angebot, sondern ein Baukasten: Ein Administrator stellt sich daraus so viele Zugänge zusammen, wie das Unternehmen braucht – jeden mit eigenem Werkzeugkasten und eigener Freigabe.

Zwei Prinzipien erklären fast alles, was dir bei MCP begegnet. Wer sie verstanden hat, muss den Rest nur noch nachschlagen.

Prinzip 1: Viele kleine Zugänge statt einem großen

Es wäre technisch möglich, einen einzigen MCP zu bauen, der jedes Werkzeug für jeden Bereich enthält. Davon raten wir ab – und zwar nicht aus Vorsicht, sondern aus Geschwindigkeit.

Ein KI-Assistent bekommt beim Verbinden die Liste aller Werkzeuge übermittelt und muss sie bei jeder Anfrage mitdenken. Diese Liste kostet Platz im Arbeitsspeicher des Modells und Zeit bei jeder Antwort. Je mehr Werkzeuge ein MCP anbietet, desto länger dauert es, bis der Assistent überhaupt anfängt zu arbeiten – und desto größer die Chance, dass er zwischen zwanzig ähnlichen Werkzeugen das falsche greift.

Ein zugeschnittener MCP mit den zwölf Werkzeugen, die eine Abteilung wirklich braucht, ist deshalb spürbar schneller und treffsicherer als ein allmächtiger mit hundert. teamspace zeigt dir diesen Zusammenhang direkt beim Zusammenstellen an: Im Steckbrief einer MCP-Konfiguration steht eine Token-Schätzung – siehe Werkzeuge auswählen und zuschneiden.

Daraus folgt das übliche Vorgehen: Ein MCP pro Anwendungsfall, nicht pro Mandant.

  • Ein allgemeiner Zugang mit nur lesendem Zugriff auf unkritische Daten – freigegeben für alle Mitarbeiter.
  • Ein HR-Zugang mit Personalwerkzeugen – freigegeben nur für die Personalabteilung.
  • Ein Vertriebszugang mit CRM- und Vertriebswerkzeugen – freigegeben für das Vertriebsteam.

Jeder dieser Zugänge hat seine eigene Adresse. Wer in zwei Gruppen ist, verbindet in seinem Client einfach beide.

Prinzip 2: Es gelten immer deine eigenen Rechte

Das ist die wichtigste Aussage des ganzen Themas, deshalb steht sie so früh:

Ein MCP erweitert niemals Berechtigungen. Was ein Zugang an Werkzeugen anbietet, sagt nichts darüber aus, was du damit sehen oder ändern kannst. Bei jedem Aufruf interpretiert teamspace dein persönliches Berechtigungsprofil – genau dasselbe, das auch gilt, wenn du dich normal anmeldest.

Ein Beispiel: Der HR-Zugang bietet das Werkzeug „Mitarbeiter-Informationen”. Ruft die Personalleiterin es auf, bekommt sie die Personalakte. Ruft ein Entwickler dasselbe Werkzeug über denselben Zugang auf, bekommt er genau das, was er auch in der Oberfläche sehen dürfte – und keinen Datensatz mehr.

Die Werkzeugauswahl eines MCP ist also kein Sicherheitsmechanismus, sondern ein Zuschnitt auf den Anwendungsfall. Sicherheit entsteht an zwei anderen Stellen: durch die Freigabe des Zugangs an bestimmte Gruppen oder Personen und durch das Berechtigungsprofil des Benutzers selbst. Wie beides zusammenwirkt, steht in Sicherheit und Berechtigungen bei MCP.

Das hat eine angenehme Nebenwirkung: Du musst keine Berechtigungen doppelt pflegen. Wer aus dem Vertrieb ins Controlling wechselt, sieht über MCP ab sofort das Neue und nicht mehr das Alte – ohne dass jemand einen MCP anfasst.

Was daraus praktisch wird

Weil der Assistent in deinem Namen und mit deinen Rechten arbeitet, ist er kein Berichtsgenerator, sondern ein Kollege mit Zugriff. Typische Anwendungen:

  • Auswertungen ohne fertigen Bericht. „Welche Bug-Tickets sind seit über zwei Wochen unbearbeitet, gruppiert nach Status?” – eine Frage, für die niemand vorher einen Bericht gebaut hat.
  • Erfassen im Vorbeigehen. Aus der Diskussion im Chat direkt einen Offenen Punkt mit Frist und Verantwortlichem anlegen.
  • Modulübergreifend denken. Tickets, Projekte und Kontakte in einer einzigen Frage verbinden, ohne drei Ansichten zu öffnen.
  • Daten bewegen. Zwischen zwei Systemen abgleichen oder eine Migration begleiten – der Assistent liest aus dem einen und schreibt ins andere.

Für den letzten Punkt gilt besondere Sorgfalt: Schreibende Zugriffe sind mächtig, und ein Assistent hat kein Gefühl dafür, ob eine Änderung teuer war. Es ist deshalb üblich, den allgemeinen Zugang nur lesend zu bauen und Schreibwerkzeuge einem eigenen, enger freigegebenen Zugang vorzubehalten.

Hinweise

  • Ein MCP ist an einen Mandanten gebunden. Die Adresse enthält die Kennung der Konfiguration; ein Zugang aus einem Mandanten funktioniert nicht in einem anderen.
  • Ändert der Administrator die Werkzeuge, wirkt das sofort. Der Client bemerkt die neue Liste beim nächsten Verbinden – du musst den Konnektor nicht neu einrichten.
  • Ein deaktivierter Zugang ist sofort tot. Das Feld „Aktiv” in der Konfiguration ist der schnellste Notausschalter.
  • Die Sprache steht am Zugang, nicht am Benutzer. Jede Konfiguration hat eine Sprache, in der ihre Werkzeuge beschrieben sind. Für ein gemischtsprachiges Team lohnen sich zwei Zugänge.

Verwandte Themen