MCP-Server

Beschreibung

Nur-Lese-Zugriff auf die Daten einer Organisation über das Model Context Protocol (MCP). Verbindet Flow Agent mit KI-Clients wie Claude, damit diese Ziele, Wertlandkarte, Organisationskontext, Aufgaben, Benachrichtigungen und Kommentare lesen können.

Verbindung & Authentifizierung

Der Server ist unter api/mcp erreichbar und über OAuth abgesichert. Der Zugriff erfolgt mit einem Token, das an genau eine Organisation gebunden ist.

Organisations-Bindung

Die Organisation ergibt sich aus dem Token und ist nie ein Werkzeug-Parameter. Ein Client kann die Organisation weder wählen noch wechseln noch benennen — organisationsübergreifende Zugriffe sind damit strukturell ausgeschlossen.

Eigenschaften

• Nur-Lese-Zugriff — es lässt sich über MCP nichts anlegen oder ändern
• Fest an genau eine Organisation gebunden: die Organisation ergibt sich aus dem Token und ist nie ein Werkzeug-Parameter
• OAuth-abgesichert; jeder Zugriff wird protokolliert
• Jede Liste ist serverseitig auf 50 Zeilen begrenzt und markiert Kürzungen ausdrücklich
• 4 vorgefertigte Prompts für wiederkehrende Auswertungen

Werkzeuge

• get_guidance — Liefert die Methodik für das Lesen dieser Organisation: Ziel-Pipeline, Wertlandkarte, Organisationskontext, Aufgaben, Benachrichtigungen und Kommentare — und wie die Werkzeuge zusammenspielen. Sollte als Erstes aufgerufen werden.
• search_goals — Listet die Ziele auf dem Pipeline-Board — standardmäßig in manueller Board-Reihenfolge. Lässt sich nach Titeltext, Verantwortlichem, Phase, Konfidenz, Abschlusszeitraum und Änderungszeitraum filtern — auch kombiniert — und liefert Kurzfassungen; Details holst Du mit get_goal. Für einen Blick in die abgeschlossene Historie (z. B. als Grundlage für eine Aufwandsschätzung) nutzt Du orderBy: "completion" mit completedAfter/completedBefore und blätterst weiter, indem Du den Wert aus dem Feld nextCursor der Antwort als Parameter cursor zurückgibst. Bei orderBy: "completion" gilt: Hör beim ersten Ziel ohne Abschlussdatum auf — ab da ist kein Abschlussdatum erfasst, die Sortierung kann diese Ziele also nicht einordnen. Das heißt NICHT “nicht abgeschlossen”: ein abgeschlossenes Ziel, dessen Datum nie erfasst wurde, landet ebenfalls dort. Um abgeschlossene Ziele unabhängig von einem erfassten Datum aufzulisten, nutzt Du stage: ["done","reflect"]. Zeilen mit erfasstem Abschlussdatum tragen completedAt und completedAtSource, Zeilen ohne tragen keines von beiden. Prüfe completedAtSource, bevor Du einem Datum vertraust: stage_change ist exakt, change_event kann zu FRÜH liegen, und updated_at ist lediglich der Zeitpunkt der letzten Änderung — eine Näherung, KEIN echtes Abschlussdatum. Wichtig: updatedAfter/updatedBefore und die Recency-Sortierung beziehen sich auf die letzte Änderung, nicht auf einen Abschlusszeitpunkt — dafür sind completedAfter/completedBefore und orderBy: "completion" da. Das Feld effort ist hier die vom Verantwortlichen geplante Größe (ein Näherungswert eines einzelnen Schätzers), nicht der Ist-Aufwand: den tatsächlichen Aufwand (effort.actual.mean, über mehrere Schätzer gemittelt) liest Du über get_goal. Mit includeDescription bekommst Du zusätzlich eine gekürzte Vorschau der Beschreibung je Ziel, damit ein Vergleichsziel-Read für eine Aufwandsschätzung in einem Aufruf gelingt.
• get_goal — Liefert alle Details zu genau einem Ziel anhand seiner ID — innerhalb der verbundenen Organisation, inklusive Abhängigkeiten, Wirkungen und Aufwand in einem Aufruf. Jeder Abschnitt meldet seinen eigenen hydration-Status, damit ein leerer Abschnitt nicht mit einem nicht lesbaren verwechselt wird. completedAt ist null, solange für das Ziel kein Abschlussdatum erfasst ist — das ist KEIN Beleg dafür, dass es nicht abgeschlossen ist, denn auch ein Ziel in reflect oder done kann ohne erfasstes Datum vorliegen. Wie verlässlich ein vorhandener Wert ist, sagt completedAtSource: stage_change ist ein von der App beobachteter Übergang und exakt, change_event stammt aus einem protokollierten Phasenwechsel und kann zu FRÜH liegen, wenn das Ziel wieder geöffnet und erneut abgeschlossen wurde, und updated_at ist lediglich der Zeitpunkt der letzten Änderung — eine Näherung, KEIN echtes Abschlussdatum.
• get_value_map — Liefert die Wertlandkarte der Organisation: Outcomes (mit WTP-/WTS-Kennzeichnung), Driver und Lever als Graph-Knoten samt gewichteten Kanten. Damit wird nachvollziehbar, warum Ziele wichtig sind. Ohne Argumente kommt die ganze Karte — auf großen Organisationen greift dabei das Server-Limit, sodass Du nur einen beliebigen Ausschnitt siehst. Mit stakeholder bekommst Du stattdessen einen VOLLSTÄNDIGEN Teilbaum; nodeType: "Outcome" listet die verfügbaren Stakeholder auf. nodeType: "Driver" OHNE stakeholder liefert die Treiber nach strategyWeight sortiert, schwerste zuerst — bei gekürzten Ergebnissen bekommst Du also die schwersten Treiber statt eines beliebigen Ausschnitts. Teilbaum-Abfragen (stakeholder zusammen mit nodeType: "Driver") sind NICHT sortiert und kommen in Projektionsreihenfolge; ihre Reihenfolge sagt nichts über Priorität aus. Treiber ohne gepflegtes Gewicht fallen auf den Gleichverteilungs-Standardwert (1/N) zurück; ab zwei Treibern weist der Hinweistext darauf hin (bei genau einem Treiber gibt es keine Gewichtung zu vergleichen; der Sortierhinweis erscheint weiterhin, nur dieser Zusatzhinweis entfällt). Mit format: "tree" bekommst Du die Karte stattdessen als eingerückten TEXT-Baum: jeder Stakeholder mit seinen Treibern (samt strategyWeight) und deren Hebeln (samt dem Gewicht, das der Hebel unter genau diesem Treiber hat). Das geht allein — dann für die ganze Karte — oder zusammen mit stakeholder für einen einzelnen Stakeholder; in Kombination mit nodeType oder wtpWts wird die Abfrage abgelehnt. Wichtig: Treibergewichte sind über die GANZE Organisation normalisiert, Hebelgewichte dagegen jeweils innerhalb ihres Treibers — Hebelgewichte sind also nur unter Geschwistern vergleichbar. Reicht das Byte-Budget nicht, werden zuerst die leichtesten Geschwister eines Treibers weggelassen; welche Stakeholder gekürzt oder gar nicht ausgeklappt wurden, steht im Hinweistext. Die Darstellung ist bewusst verlustbehaftet und NICHT re-importierbar: Wenn Du die Karte als Daten brauchst, nimm format: "weights". Das liefert dieselbe Struktur als KOMPAKTES JSON für die maschinelle Weiterverarbeitung: Stakeholder, ihre Treiber mit strategyWeight, deren Hebel mit dem Gewicht unter genau diesem Treiber — jeder Eintrag mit kind, id und parentId, dazu unattachedDrivers für Treiber, die an keinem Outcome hängen. Ein Treiber unter mehreren Eltern erscheint einmal pro Elternteil mit demselben Gewicht: für eine Summe also vorher über id entdoppeln. Hebel sind KEINE Duplikate — jedes Vorkommen trägt ein eigenes Gewicht — und werden über (id, parentId) unterschieden. Die Antwort ist ein Textblock, dessen ERSTE ZEILE das vollständige JSON ist; danach folgen ggf. eine Leerzeile und Hinweistext. Es gelten dieselben Kombinationsregeln wie bei “tree”.
• get_org_context — Liefert Teams, Personen und Rollen der Organisation. Jede Person führt ihre Rollen, ihre Team-Zugehörigkeiten (teamNames), die Teams bzw. Einheiten, die sie leitet (leads), und ihre Führungskräfte (managers) – jeweils {name, userId, type, status}, wobei type “solid” (disziplinarisch, höchstens eine) oder “dotted” (fachlich, Matrix bzw. Dotted Line) ist. Die direkten Reports einer Person sind die Vereinigung aus: Personen, deren managers diese Person enthalten, und Personen, deren teamNames eines ihrer leads enthalten – ohne die Person selbst und dedupliziert über userId. Nimm bewusst die Vereinigung: In einer Organisation ohne gepflegte Berichtslinie ist managers leer, in einer teilweise gepflegten wäre managers allein unvollständig. status einer Führungskraft markiert sie als inaktiv, sobald er auf etwas anderes als “active” gesetzt ist; in den meisten Organisationen ist er nicht gesetzt. Ein Feld directReports gibt es bewusst nicht – abgeleitet aus managers bleibt es konsistent mit der serverseitig gekappten Personenliste. Enthält konstruktionsbedingt personenbezogene Daten wie Namen und E-Mail-Adressen.
• search_tasks — Listet Aufgaben der Organisation. Filterbar nach Ziel, nach Deiner eigenen Zuständigkeit und nach Fälligkeitszeitraum. Persönliche Aufgaben sieht nur, wer sie angelegt hat.
• get_notifications — Liefert den aktuellen Benachrichtigungs-Feed des verbundenen Nutzers in dieser Organisation (Erwähnungen, Kommentare, abgeschlossene Aufgaben), neueste zuerst. Markiert nichts als gelesen.
• list_comments — Liefert den einheitlichen Verlauf zu genau einem Gegenstand — einem Ziel oder einer Aufgabe: menschliche Kommentare und Changelog-Einträge (Feld-Änderungen wie Stage, Confidence, Owner), chronologisch zusammengeführt. Jeder Eintrag trägt ein kind (“comment” oder “change”), damit ein Systemereignis nie mit einer Wortmeldung verwechselt wird. Der Changelog ist zielbezogen, daher liefert eine Aufgabe nur Kommentare — die Feld-Historie einer Aufgabe wird am übergeordneten Ziel geführt. Zurückgegeben werden die neuesten Einträge in chronologischer Reihenfolge; gelöschte Kommentare bleiben außen vor. (erfordert die Kommentar-Funktion)

Prompts

Vorgefertigte Arbeitsabläufe, die Du im Client auswählst. Sie enthalten selbst keine Daten — sie weisen das Modell an, die obigen Werkzeuge in einer sinnvollen Reihenfolge aufzurufen.

• quarterly-review — Entwirft einen Quartalsrückblick aus den Zielen: Fortschritt gemessen an der Konfidenz, verknüpft mit der Wertlandkarte. Optionaler Zeitraum-Parameter.

  Draft a quarterly review of this organization from its goals: progress against confidence, tied to the value map. Optional timeframe argument (e.g. “Q3 2026”).

• pipeline-health — Hebt die Ziele hervor, die Aufmerksamkeit brauchen — niedrige Konfidenz, ins Stocken geraten oder über Budget — als priorisierter Gesundheitscheck der Pipeline.

  Surface the goals that need attention — low confidence, stalled, or over budget — as a prioritized health check of the pipeline.

• value-map-narrative — Erklärt, warum die aktuellen Ziele zählen: verfolgt die Wertlandkarte von Outcomes über Driver zu Levern und ordnet die Ziele den Outcomes zu, die sie bewegen.

  Explain WHY the current goals matter: walk the value map (Outcomes/WTP-WTS → Drivers → Levers) and tie goals to the outcomes they move.

• weekly-briefing — Fasst Deine Woche zusammen: die Aufgaben, die auf Dich laufen, plus Deine jüngsten Benachrichtigungen als kurzes Briefing.

  Summarize your own week: the tasks assigned to or owned by you plus your recent notifications, as a short briefing.