MCP-Server

Beschreibung

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 — und, wo freigeschaltet, Ziele anlegen und ändern, Bewertungen abgeben, Aufgaben anlegen und abschließen sowie Kommentare schreiben.

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

Standardmäßig nur lesend — schreiben lassen sich nur Ziele (create_goal, update_goal), die eigenen Aufwands- und Wirkungsbewertungen des Nutzers (set_effort_vote, set_impact_vote), Verknüpfungen zwischen Zielen (add_goal_dependency, remove_goal_dependency), Aufgaben (create_task, update_task) sowie Kommentare (create_comment), und nur mit ausdrücklich erteiltem und für die Organisation freigeschaltetem Schreibzugriff
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.
count_goals — Zählt die Ziele auf dem Pipeline-Board exakt — mit Aufschlüsselung nach Phase, in einem Aufruf und ohne Zeilenlimit. Nimmt dieselben Filter wie search_goals und liefert { total, byStage }; byStage nennt jede betrachtete Phase, auch mit 0. Damit beantwortest Du „Wie viele Ziele gibt es?“ und „…pro Phase?“, ohne eine gekürzte Liste abzuzählen.
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. Gibt es mehr Aufgaben als auf eine Seite passen, enthält die Antwort nextCursor; den Wert gibst Du als cursor zurück, um weiterzublättern.
get_notifications — Liefert den aktuellen Benachrichtigungs-Feed des verbundenen Nutzers in dieser Organisation (Erwähnungen, Kommentare, abgeschlossene Aufgaben), neueste zuerst. Markiert nichts als gelesen. Gibt es mehr Benachrichtigungen als auf eine Seite passen, enthält die Antwort nextCursor; den Wert gibst Du als cursor zurück, um weiterzublättern.
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, und ein channel (ui, mcp, cli, sync, system), der sagt, wie er entstand — so erkennt ein Agent seine eigenen Änderungen. 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)
create_goal — Legt genau ein neues Ziel in der verbundenen Organisation an, im Namen des verbundenen Nutzers: Es landet in der Phase Ideation am Ende der Spalte und bekommt einen Eintrag „erstellt“ in seiner Änderungshistorie. Du übergibst einen Titel, optional eine Beschreibung, optional einen Owner (ownerId, ein Mitglied der Organisation — er folgt dem Ziel dann automatisch) und optional den eigenen geplanten Aufwand des Nutzers (S–XXL) — er zählt genau wie eine Aufwandsschätzung über set_effort_vote und wird zum Aufwand des Ziels, wenn der Nutzer selbst Owner ist. Ein Owner, der kein Mitglied ist, ergibt { error: "invalid_field", field: "ownerId", reason }. Zurück kommt das neue Ziel mit id und updatedAt. Nur verfügbar, wenn die Verbindung Schreibzugriff (goals:write) erhalten hat UND Schreibzugriff für die Organisation freigeschaltet ist — sonst taucht das Werkzeug gar nicht erst auf.
update_goal — Ändert genau ein Ziel der verbundenen Organisation: Phase, Konfidenz (0–100), Titel, Beschreibung, Reflexion und/oder Owner (ownerId: ein Mitglied der Organisation, das dem Ziel dann automatisch folgt; null entfernt den Owner; ein Nicht-Mitglied ergibt { error: "invalid_field", field: "ownerId", reason }) — geschrieben wird nur, was Du übergibst, im Namen des verbundenen Nutzers und mit Eintrag in der Änderungshistorie des Ziels. Eine reine Phasenänderung setzt das Ziel wie beim Ziehen auf dem Board ans Ende der neuen Spalte. Ändert sich die Phase, enthält die Antwort zusätzlich den Stand des Qualitäts-Gates (qualityGate) wie auf dem Board — nur zur Anzeige: Ein rotes Gate blockiert keinen Wechsel. Für Lesen-Ändern-Schreiben übergibst Du das updatedAt aus get_goal als expectedUpdatedAt: Hat sich das Ziel inzwischen geändert, wird nichts geschrieben und Du bekommst { error: "conflict", currentUpdatedAt }. Nur verfügbar, wenn die Verbindung Schreibzugriff (goals:write) erhalten hat UND Schreibzugriff für die Organisation freigeschaltet ist — sonst taucht das Werkzeug gar nicht erst auf.
set_effort_vote — Gibt die eigene Aufwandsschätzung des verbundenen Nutzers für ein Ziel ab — nie die eines anderen. planned ist die Schätzung vor der Arbeit, actual der tatsächliche Aufwand. Pro Nutzer, Ziel und Phase gibt es genau eine Schätzung; ein erneuter Aufruf ersetzt sie. Gehört dem Nutzer das Ziel, wird seine geplante Schätzung zugleich zum Aufwand des Ziels. Nur verfügbar, wenn die Verbindung Schreibzugriff (goals:write) erhalten hat UND Schreibzugriff für die Organisation freigeschaltet ist — sonst taucht das Werkzeug gar nicht erst auf.
set_impact_vote — Gibt die eigene Bewertung des verbundenen Nutzers ab, wie stark ein Ziel einen Driver oder Lever der Wertlandkarte bewegt — nie die eines anderen. Du übergibst genau eines von driverId oder leverId (den Namen des Knotens), die Phase (planning = erwartete, retrospective = tatsächliche Wirkung) und einen Wert von -XL bis +XL. Pro Nutzer, Ziel, Knoten und Phase gibt es genau eine Bewertung; ein erneuter Aufruf ersetzt sie. Eine Bewertung direkt auf einen Driver zählt als dieselbe Stufe auf jedem seiner Lever; dieselbe Person bewertet einen Driver entweder direkt oder über seine Lever, nie beides — ein Widerspruch liefert { error: "conflicting_impact_vote", existing }, die bestehende Bewertung lässt sich nur in der App entfernen. Unbekannte Ziele oder Knoten liefern { error: "not_found", field }. Nur verfügbar, wenn die Verbindung Schreibzugriff (goals:write) erhalten hat UND Schreibzugriff für die Organisation freigeschaltet ist — sonst taucht das Werkzeug gar nicht erst auf.
add_goal_dependency — Verknüpft ein Ziel mit einem anderen Ziel derselben Organisation: DEPENDS_ON heißt, goalId braucht zuerst targetGoalId; CONTRIBUTES_TO heißt, goalId zahlt auf targetGoalId ein. Eine bereits bestehende Verknüpfung bleibt unverändert (created: false). Verknüpfungen eines Ziels mit sich selbst (invalid_target) und Verknüpfungen, die über Kanten desselben Typs einen Kreis schließen würden (cycle), werden abgelehnt. Wie in der App entsteht kein Eintrag in der Änderungshistorie. Nur verfügbar, wenn die Verbindung Schreibzugriff (goals:write) erhalten hat UND Schreibzugriff für die Organisation freigeschaltet ist — sonst taucht das Werkzeug gar nicht erst auf.
remove_goal_dependency — Entfernt eine Verknüpfung (DEPENDS_ON oder CONTRIBUTES_TO) von goalId zu targetGoalId. Die Richtung zählt: Die bestehenden Verknüpfungen liefert get_goal. Fehlt die Verknüpfung, ist das kein Fehler (removed: false). Wie in der App entsteht kein Eintrag in der Änderungshistorie. Nur verfügbar, wenn die Verbindung Schreibzugriff (goals:write) erhalten hat UND Schreibzugriff für die Organisation freigeschaltet ist — sonst taucht das Werkzeug gar nicht erst auf.
create_task — Legt genau eine Aufgabe an, im Namen des verbundenen Nutzers. Mit objectiveId hängt sie an diesem Ziel (das darf jedes Mitglied): Sie geht an assigneeId — ein Mitglied der Organisation — oder, ohne Angabe, an Dich und erscheint in „Meine Arbeit” der zuständigen Person; Ziel-Owner und Zuständige folgen ihr, und die Änderungshistorie des Ziels erhält einen Eintrag. Ohne objectiveId entsteht eine persönliche Aufgabe, die nur Du siehst und die niemandem zugewiesen werden kann. Ungültige Eingaben benennen das Feld ({ error: "invalid_field", field, reason }). Nur verfügbar mit Schreibzugriff (goals:write), für die Organisation freigeschaltetem Schreiben und aktivierten Aufgaben — sonst taucht das Werkzeug nicht auf.
update_task — Ändert genau eine Aufgabe: Titel, Fälligkeit, Zuständigkeit und/oder Status — "done" schließt sie ab, "open" öffnet sie wieder. Geschrieben wird nur, was Du übergibst. Erlaubt für die zuständige Person, den Ziel-Owner und die Person, die die Aufgabe angelegt hat; eine persönliche Aufgabe nur für Letztere — wer sie nicht sehen darf, bekommt { error: "not_found" }, wer sie sieht, aber nicht ändern darf, { error: "forbidden" }. Abschließen benachrichtigt die Follower wie in der App. Für Lesen-Ändern-Schreiben übergibst Du das updatedAt aus search_tasks als expectedUpdatedAt: Hat sich die Aufgabe inzwischen geändert, wird nichts geschrieben und Du bekommst { error: "conflict", currentUpdatedAt, task } mit dem aktuellen Stand. Nur verfügbar mit Schreibzugriff (goals:write), für die Organisation freigeschaltetem Schreiben und aktivierten Aufgaben.
create_comment — Schreibt genau einen Kommentar an ein Ziel oder eine Aufgabe, im Namen des verbundenen Nutzers — in der App erscheint er mit „via Agent” (bzw. „via CLI”) und lässt sich dort wie jeder eigene Kommentar bearbeiten oder löschen. Kommentieren darf, wer den Gegenstand sehen darf; die persönliche Aufgabe eines anderen liefert { error: "not_found" }. Der Text ist reiner Text: Markdown oder HTML wird nicht interpretiert, jede Zeile wird ein Absatz. Erwähnungen schreibst Du als @{userId} an die gewünschte Stelle; IDs in mentions ohne Token werden ans Ende gehängt. Erwähnungen von Nicht-Mitgliedern oder Dir selbst werden verworfen, nie als Fehler — die Antwort nennt applied und dropped. Erwähnte bekommen Benachrichtigung und E-Mail, Follower werden wie in der App benachrichtigt. Zu langer Text (über 5000 Zeichen) liefert { error: "invalid_field", field: "text", reason }. Nur verfügbar mit Schreibzugriff (goals:write), für die Organisation freigeschaltetem Schreiben und aktivierten Kommentaren.
run_skill — Führt genau einen Evident-Flow-Coaching-Skill im Modus server serverseitig aus und liefert nur dessen Ergebnis — die Anweisungen des Skills verlassen den Server nie. Skills im Modus local lehnt das Werkzeug ab ({ error: "skill_exposed" }); sie holt der Agent mit get_skill. Der Skill liest die Daten der verbundenen Organisation mit denselben Leserechten wie die übrigen Werkzeuge und kann nichts ändern. Du übergibst den genauen Namen des Skills und die Anfrage des Nutzers; zurück kommt die Antwort plus eine Herkunftszeile (Skill, Revision, Modell). Stoppt ein Zeit-, Token- oder Schrittbudget den Lauf, ist das Ergebnis ausdrücklich als abgebrochen markiert ({ error: "truncated" }) und nie eine stillschweigend unvollständige Antwort.
list_skills — Listet die Evident-Flow-Coaching-Skills: je Skill Name, Beschreibung (wofür er gedacht ist) und Modus. local heißt, der Agent holt den Skill mit get_skill und führt ihn selbst aus; server heißt, er läuft über run_skill auf dem Server und nur das Ergebnis kommt zurück.
get_skill — Holt einen freigegebenen Evident-Flow-Coaching-Skill (Modus local), damit der Agent ihn selbst ausführt: eine kurze Einleitung, die Anweisungen des Skills und die verbindlichen Coaching-Leitplanken, dazu die Liste weiterer Dateien, die einzeln über path abrufbar sind. Skills im Modus server gibt das Werkzeug nicht heraus — sie laufen über run_skill.

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.

Kommandozeile (CLI)

Die Kommandozeile flowagent nutzt diesen Server mit denselben Werkzeugen und Berechtigungen wie jeder andere MCP-Client. Installation und Anmeldung: CLI installieren.