kaigo_mcp

Ein MCP-Server, der japanische Pflege-Angebots- und Nachfragedaten als Werkzeug für KI-Agenten bereitstellt.

Wenn man sich von Claude Code oder Claude Desktop verbindet, kann man auf Basis öffentlicher Daten beantworten, ob in dieser Stadt genügend Spezialpflegeheime vorhanden sind.

Status: Phase 1 (Server-Kern) funktioniert. Agent-Kern und Eval sind noch nicht begonnen.

Was es tut

MCP (Model Context Protocol) ist ein Standard, um LLMs mit Werkzeugen auszustatten. Dieses Repository erstellt die Werkzeugseite und enthält kein LLM selbst. Der Server ruft allein keine APIs auf und verursacht keine Kosten.

[考える側]                    [このリポジトリ]
Claude Code / 自作エージェント  ←stdio→  kaigo-gap サーバー
「どの道具を使うか」を判断              呼ばれたらデータを返す

Related MCP server: Japan Data MCP

Werkzeuge

Der Hauptindikator ist die Anzahl der Spezialpflegeheim-Plätze pro 100 anerkannte Personen mit Pflegegrad 3 oder höher (landesweit 24,6, Median 26,7). Definition und Quellen befinden sich auf der Seite von kaigo_gap_analysis.

Aggregation wird hier nicht geschrieben

Die Daten werden von Plan 4 (kaigo_gap_analysis) mit export_web.py exportiert und vom öffentlichen Dashboard bereitgestellt. Wir kopieren und verwenden dieselbe insurers.json. Hier wird keine Division neu geschrieben.

Wenn die Definition des Indikators an zwei Stellen liegt, kann man bei Abweichungen zwischen der Antwort des Agenten und den Zahlen des Dashboards nicht mehr feststellen, welche richtig ist. Da dataset.py von Plan 4 nach dem Prinzip „eine Definition an einer Stelle“ geschrieben ist, halten wir das über die Grenzen hinweg ein. Aktualisierung erfolgt mit python scripts/sync_data.py.

Worauf beim Design der Werkzeuge geachtet wurde

Nur Zahlen zurückzugeben reicht nicht zur Beurteilung. Selbst wenn man „12,4“ übergibt, weiß das LLM nicht, ob das hoch oder niedrig ist. Deshalb sind der nationale Rang und der nationale Wert in der Beschreibung des Werkzeugs enthalten.

Gleichnamige Gemeinden nicht auf eine einzige festlegen. „Fuchū-shi“ gibt es in Tokio und in der Präfektur Hiroshima. Beide Kandidaten werden zurückgegeben, die Eingrenzung überlassen wir dem Aufrufer.

Eine Spezialpflegeheim-Kapazität von 0 nicht als „landesweit letzter Platz“ interpretieren lassen. Es gibt 90 betroffene Versicherer, die alle gleichauf auf Platz 1 liegen. Die Anzahl der Gleichstände muss immer mitgeliefert werden, und zusätzlich ein Hinweis: „In kleinen Gemeinden ist das nicht ungewöhnlich; die Bewohner nutzen oft Einrichtungen in Nachbargemeinden.“ Ohne diesen Hinweis würde aus dem Ergebnis von rank_insurers die falsche Schlussfolgerung entstehen, dass „Shingō-mura die schlechteste Region des Landes“ sei.

Wenn man das Domänenwissen nicht in die Antworten der Werkzeuge einbettet, tritt derselbe Fehlschluss bei jedem Modellwechsel auf der Aufruferseite erneut auf. Deshalb wird es nicht im Prompt, sondern auf der Werkzeugseite platziert.

Verwendung

pip install -r requirements.txt
python scripts/sync_data.py     # 案4からデータを取り込む
python scripts/smoke_test.py    # 通信の疎通確認

Um es von Claude Code aus zu verwenden, genügt es, in diesem Verzeichnis zu starten; dann wird .mcp.json gelesen. Für die Registrierung in anderen Clients die folgende Konfiguration:

{
  "mcpServers": {
    "kaigo-gap": {
      "command": "python",
      "args": ["-m", "kaigo_mcp"],
      "cwd": "C:\projects\kaigo_mcp"
    }
  }
}

Agent (Phase 2, bis zur Funktionsprüfung)

python -m kaigo_mcp.agent --list
python -m kaigo_mcp.agent "尼崎市は特養が足りてる？" --verbose

Die Werkzeuge werden über den MCP-Server aufgerufen (keine direkten Funktionsimporte). Wenn man es mit Import erledigt, läuft es nicht über MCP, und die Behauptung „einen MCP-Server erstellt zu haben“ wäre nicht verifizierbar.

Die vier zu vergleichenden Spalten

B und C sind beide aus der Qwen-Familie. Dadurch lässt sich der Unterschied B→C als „Effekt nur der Modellgröße“, C→D als „Unterschied der Modellfamilie“ und A→B als „Effekt von Hardware und Generation“ lesen.

Es wird nur eine einzige Schleife geschrieben. Wenn man für eine Seite den SDK-Tool-Runner und für die andere eine handgeschriebene Schleife verwendet, lässt sich nicht mehr trennen, ob die Unterschiede zwischen den Spalten auf das Modell oder auf die Schleifenimplementierung zurückgehen. Das Backend ist nur für die Umwandlung des Verlaufs zuständig.

Messungen (Spalte A und B)

Je 6 Läufe, gemessen mit python scripts/probe_tool_calling.py.

Dass Temperatur 0 nötig ist, war nur dem 7B eigen

Bei qwen2.5:7b bricht bei Standardtemperatur das Start-Tag von <tool_call> (es werden ein paar Zeichen wie olith pering vorangestellt), sodass der ollama-Parser es nicht erkennt und der Aufruf in den Fließtext ausläuft. Erkennbar daran, dass nur das schließende Tag </tool_call> übrig bleibt. Mit Temperatur 0 verschwindet das.

Bei qwen3.5:9b sind es auch bei Standardtemperatur 6/6. Dieses Fehlverhalten ist kein allgemeines Problem lokaler Ausführung, sondern spezifisch für Generation und Größe dieses Modells.

Der größere Unterschied liegt darin, ob Anweisungen befolgt werden

Das Systemprompt weist an: „Bevor du antwortest, prüfe den nationalen Basiswert mit get_national_baseline.“ Das 9B folgt in 6/6 Fällen, das 7B in 0/6 Fällen, also nie. Außerdem ruft das 9B zwei Werkzeuge in einem Schritt parallel auf.

Dass das 7B die richtige Antwort liefern konnte, lag daran, dass es den im Werkzeugtext eingebetteten nationalen Wert (24,6) aufgriff, aber es befolgte die angewiesene Vorgehensweise nicht. Es ist also kein Unterschied in der Stabilität, sondern in der Befolgung von Anweisungen, und das wirkt sich umso stärker aus, je mehr Werkzeuge vorhanden sind.

Grenzen dieses Vergleichs

Bei A→B ändern sich Hardware und Modellgeneration gleichzeitig, daher lässt sich nicht trennen, ob die Verbesserung auf die GPU oder auf das 9B zurückgeht. Zur Trennung müsste man qwen2.5:7b auch auf der GPU-Maschine laufen lassen (kostenlos, wenige Minuten).

Auch die Sekunden werden durch das anfängliche Laden des Modells nach oben gezogen. Bei Spalte A betrug die Messung erster Lauf 102,6 s, danach 7,6 s (Durchschnitt 23,4 s). Das Skript wurde so korrigiert, dass es Median und ersten Lauf getrennt ausgibt, aber die Werte für Spalte B stammen noch vom alten Skript, daher ist eine Neuvermessung nötig.

Nächste Schritte

• Neuvermessung von Spalte B (Sekunden mit dem verbesserten Skript erneut erfassen)

• qwen2.5:7b auf der GPU-Maschine laufen lassen, um Hardware- und Modellgenerationseffekte zu trennen

• Spalten C und D noch nicht ausgeführt (da Kosten anfallen, nur einmal, sobald die Spalten vollständig sind)

• Phase 3: Eval-Kern (Erfolgsquote und Abschlussquote über mehrere Fragen × mehrere Läufe)

Verwandte Links

• kaigo_matching — Strukturierte Extraktion von Pflegeaufzeichnungen (Plan 1)

• kaigo_gap_analysis — Angebots- und Nachfragelückenanalyse nach Versicherer (Plan 4, Quelle dieser Daten)