feat(mcp): Ressourcen und Prompts fuer Claude Desktop, zwei Befunde behoben
MCP-ADAPTER 1.1
Werkzeuge ruft ein Modell von sich aus auf - Ressourcen und Prompts waehlt ein
MENSCH. In Claude Desktop sind das Anhang-Menue und Schraegstrich-Befehle, und
genau die fehlten.
- Vier Ressourcen: dc://roadmap (fertiger Markdown-Block),
dc://naechste-schritte, dc://projekte, dc://befunde.
- Vier Prompts: arbeit-aufnehmen, befunde-sichten, fehler-melden,
roadmap-pflegen. Ihr Wert liegt nicht in der gesparten Tipparbeit, sondern
darin, dass die Hausregeln mitkommen - erst nachsehen wer dransitzt,
Fremdmeldung nur mit Begruendung, Verworfenes nicht ohne neues Argument
wiedervorschlagen. Bisher standen die nur in Werkzeugbeschreibungen, und
die liest ein Modell erst, wenn es das Werkzeug schon gewaehlt hat.
- DC_PROJECT: worauf die Ressourcen zeigen. Werkzeuge nehmen project_slug je
Aufruf, Ressourcen haben keine Argumente.
- Ressourcen laufen durch dieselbe Fremddaten-Abgrenzung wie
Werkzeugergebnisse - sie sind eher ein Einfallstor, weil sie ungefragt im
Kontext landen.
- Einrichtung fuer claude_desktop_config.json dokumentiert.
Behoben: "initialize" spiegelte die verlangte Protokollfassung zurueck. Ein
Client, der 2025-06-18 anfragte, bekam sie bestaetigt, obwohl der Adapter
fuer 2024-11-05 geschrieben war. Jetzt wird gegen eine Liste tatsaechlich
bedienter Fassungen ausgehandelt.
Behoben: process.exit() mitten in schliessenden libuv-Handles. Unter Windows
eine Assertion und Rueckgabewert != 0 - ein sauber beendeter Server sah aus
wie ein abgestuerzter.
ZWEI BEFUNDE, DIE ERST DIE RESSOURCEN ZUTAGE FOERDERTEN
- roadmap.php?action=render lehnte fuer ein Werkbank-Token mit
"missing_project" ab. projectFilter() laesst es beim Lesen bewusst durch
(es soll die Landschaft sehen) und liefert null, also wurde der
Projektbezug "all". Betroffen war ausgerechnet der Tokentyp, den der
Adapter verlangt. Rueckfall ist jetzt das Heimatprojekt des Tokens.
- ProjectLinks::between() benutzte :a dreimal, forProject() :slug zweimal.
Bei ATTR_EMULATE_PREPARES = false unzulaessig -> HY093 und ein 500 auf
/api/bugtracker/v1/projects. Derselbe Fehler wie einst in der
Volltextsuche des Bugtrackers; ein Suchlauf ueber alle prepare()-Aufrufe
der Codebasis fand keine weitere Stelle.
WARUM BEIDE UNBEMERKT BLIEBEN
Beide Wege laufen nur mit einem Werkbank-Token (owner_type = dev_agent). Der
Testlauf hatte keines - es gibt keine API, so eines anzulegen, und in der
Produktion geschieht das von Hand. Ein Tokentyp, den kein Testfall benutzt,
ist ein Tokentyp, dessen Sonderwege niemand prueft.
testctl.php kann jetzt action=workbench_token; vier Testfaelle decken die Wege
ab, samt Gegenprobe, dass der Rueckfall aufs Heimatprojekt das Lesen ueber alle
Projekte nicht einschraenkt. 128 Faelle, alle gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Deploymentcenter Bot
co-authored by
Claude Opus 5
Claude Opus 5
parent
1d5ac92051
commit
8b6d6a307e
+78
-1
@@ -34,7 +34,7 @@ dieselbe, liesse sich nicht mehr sagen, wer was gemeldet hat — und das Signal
|
||||
"drei Projekte melden dasselbe" waere wertlos. Also **je Projekt ein eigenes
|
||||
Token**.
|
||||
|
||||
**2. In `.mcp.json` des Projekts eintragen:**
|
||||
**2a. Claude Code — in `.mcp.json` des Projekts:**
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -48,11 +48,54 @@ Token**.
|
||||
}
|
||||
```
|
||||
|
||||
**2b. Claude Desktop — in `claude_desktop_config.json`:**
|
||||
|
||||
Die Datei liegt unter Windows in `%APPDATA%\Claude\`, unter macOS in
|
||||
`~/Library/Application Support/Claude/`. Gibt es sie noch nicht, anlegen.
|
||||
Danach **Claude Desktop vollständig beenden und neu starten** — die
|
||||
Konfiguration wird nur beim Start gelesen, ein Fensterschließen genügt nicht.
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"deploymentcenter": {
|
||||
"command": "node",
|
||||
"args": ["J:\\Softwareprojekte\\Deploymentcenter\\mcp\\deploymentcenter-mcp.mjs"],
|
||||
"env": {
|
||||
"DC_TOKEN": "dc_...",
|
||||
"DC_PROJECT": "deploymentcenter"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Zwei Unterschiede zu Claude Code, beide wichtig:
|
||||
|
||||
- **Absoluter Pfad, Backslashes verdoppelt.** Desktop startet den Prozess ohne
|
||||
Projektverzeichnis; ein relativer Pfad findet nichts. In JSON ist `\` ein
|
||||
Fluchtzeichen, `C:\pfad` also `C:\\pfad`. Vorwärtsschrägstriche gehen unter
|
||||
Windows ebenso und ersparen das Verdoppeln.
|
||||
- **`DC_PROJECT` setzen.** Desktop arbeitet nicht in einem Projekt. Die Angabe
|
||||
bestimmt, auf welches Projekt die Ressourcen zeigen. Ohne sie nehmen sie das
|
||||
Heimatprojekt des Tokens — was auch in Ordnung ist, solange man nur eines
|
||||
betrachtet.
|
||||
|
||||
Findet Desktop `node` nicht, den vollen Pfad eintragen (`where node` unter
|
||||
Windows, `which node` sonst). `command: "node"` setzt voraus, dass Node im PATH
|
||||
des Anmeldedienstes steht, und das ist nicht überall so.
|
||||
|
||||
**Prüfen:** Nach dem Neustart erscheinen unten im Eingabefeld die vier
|
||||
Schrägstrich-Befehle (`arbeit-aufnehmen`, `befunde-sichten`, `fehler-melden`,
|
||||
`roadmap-pflegen`) und im Anhang-Menü die vier Ressourcen. Fehlt beides, steht
|
||||
der Grund im Desktop-Log: `%APPDATA%\Claude\logs\mcp-server-deploymentcenter.log`.
|
||||
|
||||
Umgebungsvariablen:
|
||||
|
||||
| Variable | Vorgabe | Zweck |
|
||||
|---|---|---|
|
||||
| `DC_TOKEN` | — | Pflicht. Werkbank-Token. |
|
||||
| `DC_PROJECT` | Heimatprojekt des Tokens | Auf welches Projekt die Ressourcen zeigen. Für Desktop empfohlen. |
|
||||
| `DC_BASE_URL` | `https://dc.mhdf.de` | Andere Instanz oder lokale Entwicklung. |
|
||||
| `DC_TIMEOUT_MS` | `15000` | Zeitgrenze je Aufruf. |
|
||||
|
||||
@@ -127,6 +170,40 @@ Endpunkte. Werkzeugdefinitionen liegen dauerhaft im Kontextfenster, anders als
|
||||
eine Doku, die man einmal liest — ein aufgeblaehter Adapter waere schlechter als
|
||||
die Prompt-Vorlage, die er ersetzt.
|
||||
|
||||
## Ressourcen und Prompts
|
||||
|
||||
Werkzeuge ruft ein Modell von sich aus auf. Ressourcen und Prompts wählt ein
|
||||
**Mensch** — in Claude Desktop über das Anhang-Menü bzw. als
|
||||
Schrägstrich-Befehl. Das ist der Unterschied, der sie lohnend macht.
|
||||
|
||||
**Ressourcen** (lesend, live aus dem Deploymentcenter):
|
||||
|
||||
| URI | Inhalt |
|
||||
|---|---|
|
||||
| `dc://roadmap` | Planungsstand als Markdown — derselbe Block, den `cli/roadmap.php` schreibt |
|
||||
| `dc://naechste-schritte` | Was als Nächstes ansteht und wer gerade woran sitzt |
|
||||
| `dc://projekte` | Projektlandschaft mit Beziehungen |
|
||||
| `dc://befunde` | Offene Befunde je Detektor |
|
||||
|
||||
**Prompts** (tragen die Hausregeln mit, nicht nur den Text):
|
||||
|
||||
| Befehl | Wofür |
|
||||
|---|---|
|
||||
| `arbeit-aufnehmen` | Erst nachsehen, wer schon dransitzt, dann übernehmen |
|
||||
| `befunde-sichten` | Befunde einstufen — echt, Artefakt oder Rauschen |
|
||||
| `fehler-melden` | Ins richtige Projekt melden, mit `evidence` bei fremden |
|
||||
| `roadmap-pflegen` | Einplanen und zurückstellen, mit der Auslöser-Regel |
|
||||
|
||||
Der Wert der Prompts liegt darin, dass die Regeln mitkommen: dass vor dem
|
||||
Anfangen nachgesehen wird, dass eine Fremdmeldung eine Begründung braucht, dass
|
||||
ein verworfenes Vorhaben nicht ohne neues Argument wiederkommt. Ohne sie stehen
|
||||
diese Regeln nur in der Werkzeugbeschreibung — und die liest ein Modell erst,
|
||||
wenn es das Werkzeug schon gewählt hat.
|
||||
|
||||
Ressourcen laufen durch dieselbe Abgrenzung wie Werkzeugergebnisse. Sie sind
|
||||
sogar eher ein Einfallstor: Sie landen ungefragt im Kontext, weil ein Mensch
|
||||
sie angehängt hat.
|
||||
|
||||
## Was der Agent darf und was nicht
|
||||
|
||||
| | eigenes Projekt | fremdes Projekt |
|
||||
|
||||
Reference in New Issue
Block a user