_context

Kontext: intern/capabilities/mcps/

Zweck

Pro MCP-Server eine .md mit dem mcp_server-Schema (siehe schemas). Setup-Anleitung, verfuegbare Tools, Limits, typische Stolperer. Plus _index.md als Dashboard fuer das gesamte MCP-Inventar — wird via @import in CLAUDE.md geladen.

Was gehoert hier rein / NICHT rein

Hier rein:

• Eine Datei pro MCP-Server (eigene Forks und Eigenbauten gleichermassen)
• Setup-Schritte, Auth-Modell, Tool-Liste, Quirks
• Cross-Refs zu [[../repos/<name>]] wenn der MCP einen eigenen Source-Tree hat

NICHT hier rein:

• API-Tokens, OAuth-Secrets — .env.local der jeweiligen Tool-Instanz, niemals ins Repo
• Eigentlicher Source-Code → [[../repos/<name>]] als Pointer auf ~/source/mcps/<name>/
• Use-Case-Wissen (z.B. „YouTube-SEO-Workflow”) → intern/wissen/... oder Skill-Ordner

Fuer Agents

• Bevor du behauptest „MCP X kann Y nicht”: Capability erweitern statt Workaround. Die Sources liegen unter ~/source/mcps/<name>/, editable installiert — 2-Zeilen-Patch + Claude-Code-Reload reicht meist.
• HTTP ist Default-Transport bei eigenen MCPs. Stdio nur wenn so dokumentiert.
• Ports siehe _index.md und _meta/config.md.
• Bei Token-Problemen: erst .oauth2.*.json / .env.local pruefen, dann Anbieter-Dashboard, dann fragen.

Lokale Konventionen

• Frontmatter Schema 5.18: id, type=mcp, name, status (active|configured|broken|deprecated), purpose, auth (oauth|api_key|service-principal|none), auth_ref (Verweis auf Secret-Speicher, NIE der Wert), endpoint, used_by_skills, notes
• Status-Wechsel: configured solange Token fehlt, active wenn lauffaehig im Daily Driver, broken wenn defekt, deprecated wenn abgeloest
• Setup-Schritte als nummerierte Liste, Quirks als eigene Section