MCP-Server

Mit KI installieren

Am schnellsten richtest du Tekk mit einem einzigen Befehl im Root deines Repositorys ein. Du kannst ihn selbst eintippen oder deinem Coding-Agent übergeben.

TerminalIn deinen Agent einfügen

$npx @tekk_coach/cli@latest initKopieren

Was er macht:

1. Meldet dich über den Browser an. Es gibt keinen API-Key zum Kopieren.
2. Wählt deinen Tekk-Workspace aus und fragt nur nach, wenn du mehrere hast.
3. Verbindet das Repository, in dem du ihn ausführst, als Tekk-Projekt – ermittelt aus seinem Git-Origin auf GitHub oder GitLab –, nachdem er gezeigt hat, was er anlegt. Ist dein GitHub- oder GitLab-Account noch nicht mit Tekk verknüpft, holt er das im selben Browser-Tab nach.
4. Richtet deine Coding-Agents ein. Claude Code bekommt das Tekk-Plugin mit seinen Skills und dem MCP-Server. Codex und Cursor bekommen den Tekk-MCP-Server und die Skills.
5. Fügt deiner CLAUDE.md oder AGENTS.md einen markierten Tekk-Abschnitt hinzu, damit jede Agent-Session weiß, wie sie mit deinem Board arbeitet.

Bevor er etwas ändert, zeigt er jede Datei, die er ändert, und jeden Befehl, den er ausführt, mit Diff, und fragt einmal nach. Ein erneuter Lauf holt nur nach, was fehlt, und npx @tekk_coach/cli doctor prüft das Setup. Beim Setup läuft keine KI: Es ist deterministisch und kostet keine Credits.

Wenn er fertig ist, führ in deinem Agent /ideate-loops aus, um die Loops auszuwählen, die sich lohnen, /grill-to-steer, um sie auf das auszurichten, was dir wichtig ist, und /sweep, um abzuarbeiten, was sie finden.

Tekk stellt einen Model-Context-Protocol-Server (MCP-Server) bereit, damit du direkt aus dem Coding-Agent heraus, den du ohnehin nutzt, mit deinem Board arbeiten kannst – Claude Code, Codex, Cursor oder jeder andere MCP-fähige Client. Lies und schreibe Specs, starte eine Flotte paralleler Sessions, prüfe Tekks Proposals und lies den Kontext des Workspaces, ohne das Terminal zu verlassen.

Jede Verbindung ist an einen Workspace gebunden, festgelegt durch die URL, mit der du dich verbindest, und deine Mitgliedschaft – deshalb fragt kein Tool je, welcher Workspace gemeint ist.

Installation in Claude Code

Am schnellsten geht es mit dem Tekk-Plugin, das diesen Server verbindet und die zehn Skills installiert, mit denen du dein Board steuerst – sweep, blitz, triage, spec, feedback, night-shift, grill-to-steer, steer-loops, grill-to-loop und ideate-loops:

/plugin marketplace add guccikudo92615/tekk-skills
/plugin install tekk@tekk

Das ist schon das ganze Setup: Das Plugin deklariert den MCP-Server, es gibt also keinen separaten Verbindungsschritt und nichts, was du in deine eigene Konfiguration einfügen musst. Was jeder davon tut, steht unter Loops und ihre Skills.

Der Rest dieser Seite beschreibt den manuellen Weg – um einen bestimmten Workspace festzulegen, für andere Clients und für CI.

Den Server allein verbinden

Hol dir deine Workspace-URL unter Settings → API keys in der App (sie sieht aus wie https://app.tekk.coach/api/mcp/<workspace-slug>) und führe dann aus:

claude mcp add --transport http tekk https://app.tekk.coach/api/mcp/<workspace-slug>

Kein Token, kein Header, nichts einzufügen. Dann authentifizierst du dich:

claude mcp login tekk

Dein Browser öffnet Tekks Zustimmungsseite; bestätige sie, und du bist verbunden. In einer laufenden Session geht das auch über das Panel /mcp – wähle tekk → Authenticate. Claude Code übernimmt Discovery, Client-Registrierung und PKCE für dich und speichert ein kurzlebiges, widerrufbares Token – nie einen Key.

Ob es geklappt hat, prüfst du mit claude mcp list oder in einer Session mit /mcp – dort sollte tekk mit seinen Tools als verbunden erscheinen.

Hänge --scope user an den Befehl an, damit Tekk in jedem Projekt auf deinem Rechner verfügbar ist statt nur im aktuellen. Mit --scope project committest du den Server für das ganze Team in .mcp.json – hier unbedenklich, weil mit OAuth kein Secret in der Datei steht.

Neu authentifizieren kannst du dich jederzeit mit claude mcp login tekk; claude mcp logout tekk löscht das lokale Token. Um einem Client von Tekks Seite aus den Zugang zu entziehen, nutze Settings → Connected apps.

Dein Team verbindet sich genauso

Die Workspace-URL ist weder geheim noch persönlich – sie ist für alle dieselbe. Alle im Team führen dieselben zwei Befehle aus und bestätigen die Zustimmungsseite mit ihrem eigenen Tekk-Account, und ihre Aktionen landen unter ihrem eigenen Namen auf dem Board. Nichts wird geteilt, und es gibt keine Einrichtung pro Seat: Lade sie in den Workspace ein, und ihr Zugang beginnt mit ihrer nächsten Anfrage (und endet in dem Moment, in dem du sie entfernst).

Andere Clients

• Custom Connectors auf claude.ai – füge dieselbe Workspace-URL ein und bestätige im Browser.
• Cursor, VS Code, Zed und andere OAuth-fähige MCP-Clients – richte sie als Streamable-HTTP-Server auf die Workspace-URL ein; sie durchlaufen denselben Browser-Flow.
• Alles andere – siehe API-Key weiter unten.

Die Skills außerhalb von Claude Code

Nur Claude Code hat Plugins, deshalb installierst du die Skills überall sonst ohne Plugin und verbindest den Server separat (siehe oben):

npx skills add guccikudo92615/tekk-skills -a codex

Ersetze -a codex durch -a cursor oder einen anderen Agent, den der Installer unterstützt. Die Skills landen im Ordner .agents/skills/, den diese Agents lesen, und es sind dieselben Dateien, die das Claude-Code-Plugin mitliefert.

Mit einem API-Key

Für CI, Skripte und Clients ohne OAuth. Der Key ist ein Bearer-Secret – behandle ihn wie ein Passwort.

1. Lege unter Settings → API keys einen Key an. Er gilt für den aktuellen Workspace und wird nur einmal angezeigt.
2. Leg ihn in einer Umgebungsvariable ab und referenziere ihn so, dass er erst zur Laufzeit eingesetzt und nie im Klartext in eine Datei geschrieben wird.

Claude Code – setze den Header in einfache Anführungszeichen, damit der Platzhalter ${TEKK_API_KEY} wörtlich in deiner Konfiguration gespeichert und erst zur Laufzeit aus der Umgebung eingesetzt wird:

export TEKK_API_KEY=tekk_...
claude mcp add --transport http tekk https://app.tekk.coach/api/mcp \
  --header 'Authorization: Bearer ${TEKK_API_KEY}'

Nimm einfache Anführungszeichen. Bei doppelten setzt deine Shell die Variable schon beim Hinzufügen ein und schreibt den echten Key fest in die Konfigurationsdatei – genau das, was du vermeiden willst.

Codex (~/.codex/config.toml) – liest den Key aus der Umgebung, es wird also nichts Sensibles in die Datei geschrieben:

[mcp_servers.tekk]
url = "https://app.tekk.coach/api/mcp"
bearer_token_env_var = "TEKK_API_KEY"

Jeder andere MCP-Client – richte ihn auf https://app.tekk.coach/api/mcp ein, mit dem Header Authorization: Bearer tekk_..., gespeist aus einer Umgebungsvariable, wo immer der Client das zulässt.

Ein Key trägt seinen Workspace in sich, deshalb reicht die blanke URL /api/mcp – und ein Key gewährt nie eine Wahl des Workspaces: Bei einer Workspace-URL muss er zum Workspace im Pfad passen.

Committe .mcp.json nie (und auch keine andere Datei mit dem Key) in die Versionsverwaltung. Wird ein Key jemals offengelegt, widerrufe ihn unter Settings → API keys – der Widerruf greift bei der nächsten Anfrage.

Gib deinem Agent den Workflow

Die Tools sind nur die halbe Miete – dein Agent arbeitet viel besser, wenn er weiß, wie er sie einsetzt.

Wenn du das Plugin oder die Skills installiert hast, hast du das schon und kannst den Rest dieses Abschnitts überspringen: die Skills bringen den Workflow mit, und sie werden aktualisiert, wenn wir sie verbessern.

Nur wenn du keins von beiden nutzt, füge das hier in die CLAUDE.md oder AGENTS.md deines Repos ein. Beachte, dass eine eingefügte Kopie eingefroren ist – sie wird nicht besser, wenn Tekk besser wird:

## Tekk (MCP: tekk)

Tekk runs autonomous loops over this project's codebase, raises what
they find as proposals, and keeps the spec board. The MCP is
connected to ONE workspace, fixed by the connection: never ask which.

Two slash commands carry most of the work, in this order:
- `/mcp__tekk__sweep` — work the WHOLE pending proposal inbox in one pass:
  re-check every finding against the code as it is now, say which no longer
  hold and why, then accept the survivors in a single batch.
- `/mcp__tekk__blitz` — turn the resulting specs into running coding
  sessions, as many at once as is collision-safe.

Workflow:
- Start with `get_workspace_overview`. Its `drift` block lists specs whose
  status disagrees with what actually merged — believe drift over a bare
  status.
- "What should I work on?" → `list_specs`, then `get_spec` for the full body
  and acceptance criteria before implementing. `get_spec` embeds `linkedPrs`,
  `checklistProgress` and a `drift` verdict.
- `update_spec_status` → in-progress the moment you start. Keeping status
  current is part of the work, not a separate step.
- Closing a spec from a PR is two things, both yours: tick the
  `## Build order` items you finished (`update_spec`), and put `Closes TEK-n`
  in the PR body. A PR that merely MENTIONS a spec links it for display and
  moves nothing.
- New work found mid-session → `create_spec`. Research the code first: the
  tool requires load-bearing claims to carry real locators (file:line, a URL,
  a measurement) before it accepts the spec. A feature with independently
  buildable parts becomes a parent plus one Sub-task per part (`parentSpec`),
  each with its own `touches` and `dependsOn`.
- Proposals — what the loops raised, awaiting a decision. `list_proposals`
  (each row carries `loopSkill`, the loop that raised it, and `evidenceCheck`,
  the last verdict on its evidence); `get_proposal` to read one in full;
  `verify_proposal` to re-check its evidence against the CURRENT checkout;
  `revise_proposal` to have Tekk redraft it in place from your feedback;
  `decide_proposals` to accept or reject many in one call, or
  `accept_proposal` / `reject_proposal` for one. Always give a reason when
  rejecting — reasons steer the loops.
- Running work in parallel → `plan_batch` for a collision-free batch, then
  `start_session` for each session you open. `fleet_status` is the one-read
  picture; `update_session` marks one blocked or abandoned. Never claim a
  session completed — completion is derived from the spec's merged closing PR.
- Loops → `list_loops` (what is enabled and with how much rope), `list_runs`
  and `get_run` (what ran, what it cost, how its finding was verified),
  `run_loop` to fire one on demand.
- `list_documents` / `read_document` expose the workspace knowledge Tekk
  reasons from (product, audience, business model). Read before making
  product-level decisions.

Was die Tools können

Bereich	Tools	Was du tun kannst
Orientierung	get_workspace_overview	Dir einen Überblick verschaffen – Projekte, wie viel offen ist, und alle Specs, deren Status nicht zu dem passt, was gemergt wurde.
Specs	list_specs, get_spec, create_spec, update_spec, update_spec_status	Das Board lesen, den vollständigen Text einer Spec samt Akzeptanzkriterien öffnen, neue Arbeit anlegen und Specs durch todo → in-progress → completed bewegen.
Struktur	add_dependency, remove_dependency	Festlegen, dass eine Spec fertig sein muss, bevor eine andere starten kann – eine harte Sperre, die der Batch-Planer respektiert.
Epics	list_epics, create_epic, archive_epic	Mehrere unabhängige Features unter einem Epic bündeln und es archivieren, wenn es erledigt ist.
Parallele Ausführung	plan_batch, dispatch_batch, start_session, update_session, list_sessions, fleet_status	Einen kollisionsfreien Batch von Specs planen, die gleichzeitig laufen, ihn starten und die Flotte ehrlich tracken.
Proposals	list_proposals, get_proposal, verify_proposal, revise_proposal, accept_proposal, reject_proposal, decide_proposals	Sehen, was Tekk vorschlägt und welcher Loop es gemeldet hat, einen Fund gegen deinen aktuellen Code neu prüfen, Tekk eines anhand deines Feedbacks neu entwerfen lassen und einen ganzen Batch in einem einzigen Aufruf entscheiden.
Loops	list_loops, list_runs, get_run, run_loop, set_loop, configure_loop, configure_workspace_loops	Sehen, welche Loops an sind und wie viel Spielraum sie haben, lesen, was ein Lauf gekostet hat und wie sein Fund verifiziert wurde, einen Loop bei Bedarf starten und die Autonomie oder die Stunde des nächtlichen Laufs einstellen.
Code-Index	get_index_status, queue_reindex	Prüfen, was die Loops tatsächlich sehen können – Aktualität und Abdeckung des Index pro Repo – und ein Repo neu indexieren, dessen Index veraltet ist.
Kontext	list_documents, read_document	Das Wissen des Workspaces lesen – Produkt, Zielgruppe, Geschäftsmodell –, auf das Tekk seine Überlegungen stützt.

Jeder Skill ist auch ein Slash-Command, /mcp__tekk__<name>, den der MCP-Server selbst bereitstellt; ein Client, der nichts installiert hat, hat sie also trotzdem. Zwei tragen den Großteil der Arbeit, und sie laufen nacheinander.

/mcp__tekk__sweep arbeitet deine ganze Inbox offener Proposals in einem Durchgang ab. Funde stapeln sich gerade deshalb, weil es sich nie lohnt, sie einzeln zu entscheiden – also prüft sweep jeden einzelnen gegen den Code, wie er jetzt ist, und trennt die zwei Dinge, die ein veralteter Fund bedeuten kann: Er wurde behoben (also Reject), oder der Code ist nur umgezogen (also Revise – der Fund kann weiterhin völlig zutreffen und nur auf die falschen Zeilen verweisen). Das verlangt gegensätzliche Antworten, und ein Refactoring ist kein Fix. Sweep berichtet, wartet auf dein Go und bringt dann den ganzen Batch mit einem Aufruf durch.

/mcp__tekk__blitz macht aus dem Ergebnis laufende Arbeit. Blitz liest, was deine Loops gemeldet haben, zusammen mit deinen offenen Specs, ermittelt den größten kollisionssicheren Batch und öffnet eine Coding-Session pro Spec – über ein Tool, das Sessions startet, wo dein Setup eines hat, sonst über eine Task-Karte mit einem Klick und in einem einfachen Terminal über einen Prompt zum Einfügen. Alles, was es öffnet, wird als Session registriert und taucht deshalb in fleet_status neben dem Rest der Flotte auf.

Keiner der beiden Befehle entscheidet ein Proposal oder startet etwas ohne ein ausdrückliches Ja von dir.

Ein paar Dinge sind Absicht:

• Das Vokabular ist Spec, nicht Task/Issue/Ticket – siehe Grundbegriffe.
• Verifizieren ist eine Tatsache, Entscheiden ein Urteil. Die Belege eines Proposals gegen deinen Code neu zu prüfen, schreibt ohne Rückfrage. Ein Proposal mit Accept anzunehmen, mit Reject abzulehnen oder mit Revise zu überarbeiten, braucht dein ausdrückliches Ja – ein Agent entscheidet nie an deiner Stelle.
• Goals werden in der App gesetzt, nicht über MCP. Auf dem Board arbeitet der Agent; die Richtung gibst du vor.
• Kein Tool nimmt einen Workspace als Argument. Das entscheidet die Verbindung.

Arbeit parallel laufen lassen

Das Board ist nicht nur eine Liste – es trägt genug Struktur, damit ein Agent mehrere Specs sicher gleichzeitig laufen lassen kann:

• Sub-Tasks statt loser Einzel-Specs. Ein Feature, das sich zerlegen lässt, wird zu einer übergeordneten Spec mit einem Sub-Task pro unabhängig baubarem Teil (create_spec mit parentSpec). Jeder Sub-Task bringt seinen eigenen PR mit; die übergeordnete Spec ist automatisch fertig, sobald ihre Sub-Tasks es sind.
• touches gibt den Codebereich an, den eine Spec ändern wird, als Globs. plan_batch weigert sich, zwei Specs mit überlappenden Bereichen gemeinsam einzuplanen – sie kommen in verschiedene Wellen, statt in denselben Dateien zu kollidieren.
• dependsOn ist eine harte Sperre. Eine Spec, die auf eine Voraussetzung wartet, kann erst gestartet werden, wenn diese Voraussetzung wirklich fertig ist.
• plan_batch wählt die nächste sichere Menge und liefert pro Spec ein startbereites Kickoff-Paket. Beschränke es mit parentSpec oder epic auf eine Welle. fleet_status beantwortet dann die Frage „Was machen meine Agents, und was muss ich noch starten?“
• Fertigstellung wird abgeleitet, nie behauptet. Eine Session ist fertig, wenn der schließende PR der Spec gemergt wird – deshalb zeigt list_sessions, was tatsächlich ausgeliefert wurde, und nicht, was ein Agent behauptet hat.

Sicherheit & Zugangsdaten

Die Agent-Schnittstelle ist so gebaut, dass du sie bedenkenlos verbinden kannst. Was das in der Praxis heißt:

• Nimm lieber OAuth. Es speichert ein widerrufbares Token statt eines langlebigen Secrets, setzt vor die erste Verbindung eine Zustimmungsseite, und jede verbundene App lässt sich unter Settings → Connected apps einzeln widerrufen.
• API-Keys sind Bearer-Secrets. Auf unserer Seite werden sie gehasht gespeichert und sind auf einen einzigen Workspace beschränkt – aber auf deinem Rechner ist der Key nur so sicher wie die Datei oder Umgebung, die ihn enthält. Bewahre ihn in einer Umgebungsvariable auf, nie direkt in einer committeten Datei (siehe die Key-Einrichtung oben).
• Gib jeder Person eigene Zugangsdaten. Ein Key bindet eine Person an einen Workspace, ein geteilter Key verbucht also die Arbeit aller unter einem Namen. Keys enden außerdem mit der Mitgliedschaft: Entfernst du jemanden aus dem Workspace, funktioniert der Key dieser Person ab der nächsten Anfrage nicht mehr.
• Widerruf wirkt sofort. Der Server ist zustandslos – eine frische Instanz pro Anfrage –, deshalb kappt der Widerruf eines Keys oder einer OAuth-Freigabe den Zugriff schon beim nächsten Aufruf.
• Bestätige nur Verbindungen, die du selbst gestartet hast. Weil jede App selbst einen OAuth-Client registrieren kann (auch unter einem zum Verwechseln ähnlichen Namen), zeigt unsere Zustimmungsseite den echten Ziel-Host statt des Namens, den die App sich gegeben hat, und warnt dich, nur zu bestätigen, wenn du die Verbindung selbst angestoßen hast.
• Eine Freigabe, dein ganzer Account. Eine bestätigte OAuth-Freigabe kann in jedem Workspace handeln, zu dem dein Account gehört – der Workspace wird durch die URL festgelegt, mit der du dich verbindest, aber die Freigabe folgt deiner Mitgliedschaft. Widerrufst du die App unter Settings → Connected apps, ist sie überall auf einmal getrennt.
• Rate-Limit. Jeder Key und jede OAuth-Freigabe hat ein eigenes Budget von 120 Anfragen pro Minute – großzügig für eine interaktive Session, und wer im Team viel arbeitet, frisst nie das Budget der anderen auf.

Wie das zum Rest von Tekk passt

Der MCP-Server ist die Terminal-Ansicht desselben Boards, in das die Loops einspeisen. Einem Loop fällt etwas auf, und er entwirft ein Proposal; du nimmst es mit Accept an, und es wird zu einer Spec; du (oder dein Agent über MCP) setzt sie um und markierst sie als erledigt. Ein Board, zwei Oberflächen.