MCP-Tools

kanman stellt einen kleinen MCP-Server (Model Context Protocol) bereit, über den Coding-Agenten nach den Regeln Ihres Teams an einer Story arbeiten. In einem Run verbindet kanman ihn automatisch mit dem Coding-Agenten. Sie können ihn auch in Claude Code oder Codex auf Ihrem eigenen Rechner einrichten und im Terminal an einer kanman-Story arbeiten; die Änderung durchläuft trotzdem das Outcome-Gate und bekommt ein Nachweispaket. Die Einrichtung beschreibt kanman aus Claude Code oder Codex nutzen.

Endpunkt und Authentifizierung

Claude Code:

claude mcp add --transport http kanman \
  https://api.kanman.ai/functions/v1/executor-mcp/stories/SBX-12 \
  --header "Authorization: Bearer $KANMAN_API_KEY"

Codex (~/.codex/config.toml, mit dem Token in der Umgebungsvariable KANMAN_API_KEY):

[mcp_servers.kanman]
url = "https://api.kanman.ai/functions/v1/executor-mcp/stories/SBX-12"
bearer_token_env_var = "KANMAN_API_KEY"

Die Tools im Überblick

Der Coding-Agent erklärt eine Story nie selbst für fertig. kanman führt die Gates aus und nimmt jede abgesicherte Verschiebung selbst vor. Siehe Das Outcome-Gate und Nachweise.

get_story

Liefert die Story, ihre Akzeptanzkriterien und den Demonstrate-Block, den Testplan, den aktuellen Run und eine Zusammenfassung der Team-Richtlinie. Keine Eingaben.

Beispielergebnis:

{
  "story": {
    "key": "SBX-12",
    "title": "Export invoices as CSV, filtered by date range",
    "description": "Customers need to export their invoices for their accountant.",
    "acceptanceCriteria": [
      {
        "id": "ac-1",
        "text": "Given a customer with 3 invoices in March, When they export March as CSV, Then the file has 3 rows and the columns date,number,amount"
      }
    ],
    "demonstrate": {
      "kind": "ui",
      "steps": ["open /invoices", "pick 2026-03-01..2026-03-31", "click Download CSV"],
      "expected": "a CSV downloads with columns date,number,amount"
    },
    "testPlan": ["unit: CSV serializer", "e2e: download flow"],
    "affectedAreas": ["src/invoices/**"]
  },
  "run": {
    "runKey": "run-7f3k",
    "attempt": 1,
    "phase": "implement",
    "stage": "implementing",
    "branch": "kanman/sbx-12-export-invoices-as-csv-filtered-by-date-range",
    "status": "running"
  },
  "policy": {
    "preset": "balanced",
    "deniedPaths": ["infra/**", "**/*.tf", ".github/workflows/**", ".kanman/acceptance/**"],
    "maxChangedFiles": 30,
    "maxChangedLines": 800,
    "runBudgetCents": 200,
    "planApproval": "always",
    "requireAcceptanceSpec": true,
    "repositories": ["kanman-ai/pilot-sandbox"]
  }
}

run ist null, solange es keinen Run gibt. phase ist plan, während ein Run auf die Plan-Freigabe wartet, danach implement.

start_work

Verschiebt die Story aus Backlog, Refining oder Ready in die Spalte In Progress und liefert den Run. Lokal eröffnet der erste Aufruf einen Run für die Story, damit Fortschritt, Prüfung und Nachweispaket wie bei kanmans eigenen Runs funktionieren. Keine Eingaben.

Solange ein kanman-Run noch plant (das Team verlangt eine Plan-Freigabe und der Plan ist noch nicht freigegeben), lehnt start_work ab: Der Agent schreibt den Plan und beendet seinen Zug, und der Plan geht in den Entscheidungseingang. Lokale Runs haben keine Planungsphase.

report_progress

Schreibt eine Zeile in die Fortschrittsmeldungen der Run-Seite und setzt die Phase des Runs.

Ergebnis: { "recorded": true }.

request_human_input

Stellt eine Frage im Entscheidungseingang (Entscheidungsart clarification) und pausiert den Run, bis jemand antwortet. Die Antwort geht als Vorgabe an den Run, wenn er weiterläuft.

{ "decisionKey": "dec-4h2k", "next": "Your question is in the team inbox. End your turn now; the run continues with the answer." }

check_policy

Fragt, ob eine Aktion erlaubt ist, bevor der Agent sie versucht, zum Beispiel „darf ich infra/ anfassen?“. Die Antwort folgt denselben Regeln, die kanman später auf den fertigen Diff anwendet. Jeder Aufruf steht im Audit-Log als policy_decision.

{
  "allowed": false,
  "authority": "ESCALATE",
  "reasonKey": "policy.path.denied",
  "reasonParams": { "path": "infra/alarms.tf", "glob": "infra/**", "preset": "balanced" },
  "decisionKind": "touch_denied_path",
  "decisionKey": null
}

submit_for_review

Teilt kanman mit, dass die Arbeit committet und gepusht ist. Die Zusammenfassung landet im Nachweispaket. In einem kanman-Run beginnt die Prüfung, wenn der Agent seinen Zug beendet; ein lokaler Run wird sofort abgeschlossen, und die Prüfung beginnt. kanman führt dann die Gates aus (die Akzeptanz-Spec in einer frischen Umgebung, den Diff-Wächter und die Diff-Grenzen, CI und das Review) und verschiebt die Story erst nach Review, wenn sie bestehen. Das Ergebnis erscheint auf der Run-Seite.

{ "submitted": true, "next": "Verification has started; the run page shows the evidence." }

Scheitert ein Gate, startet kanman einen automatischen Nacharbeitsversuch mit der Ausgabe des Gates, soweit die Richtlinie es erlaubt.

complete_work

Verschiebt die Story in die nächste Spalte (Review, oder Done, wenn das Team keine Review-Spalte hat). kanman lehnt ab, solange der Run keinen Prüfnachweis hat, in dem kein Gate gescheitert ist und, wenn das Team eine Akzeptanz-Spec verlangt, die Spec das Ergebnis belegt. Keine Eingaben.

Ergebnis: { "completed": true, "movedTo": "<spalte>" }.

Fehler

Ein Tool, das nicht tun kann, was verlangt ist, liefert ein Tool-Ergebnis mit isError: true und einer lesbaren Meldung. Der Agent sollte sie lesen und danach handeln. Typische Meldungen:

Anfragen, die der Server gar nicht annehmen kann (fehlendes oder ungültiges Token, eine Story außerhalb des Workspaces des Tokens), beantwortet er mit HTTP 401. Siehe Fehler und Rate Limits.

Verwandte Seiten

• kanman aus Claude Code oder Codex nutzen
• Runs
• Entscheidungen
• Richtlinien-Einstellungen