kaigo_mcp

将日本介护的供需数据，作为AI智能体可使用的工具公开的MCP服务器。

从 Claude Code 或 Claude Desktop 连接后，就能基于公开数据回答“这个市的特别养护老人之家是否充足”这样的问题。

状态：Phase 1（服务器本体）已运行。 智能体本体和 eval 尚未着手。

这是做什么的

MCP（Model Context Protocol）是让 LLM 拥有工具的标准。这个仓库构建的是工具这一侧，不包含 LLM 本身。服务器单独运行时不会调用任何 API，也不会产生费用。

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

工具

主要指标是每100名需要介护3级以上的认定者对应的特养定员数（全国24.6人・中位数26.7人）。 定义和出处位于 kaigo_gap_analysis 一侧。

不在本仓库中编写统计逻辑

数据由案4（kaigo_gap_analysis）通过 export_web.py 导出， 并复制使用与公开仪表板所分发的相同的 insurers.json。这里不重新编写除法逻辑。

如果在两个地方持有指标定义，当智能体的回答与仪表板的数字不一致时， 就无法判断哪一边是正确的。案4的 dataset.py 按照“定义只在一处”的方针编写， 因此跨仓库遵守这一原则。更新通过 python scripts/sync_data.py 执行。

工具设计中注意的事项

只返回数字无法做出判断。 即使把“12.4”交给 LLM，它也不知道是高是低， 因此在全国排名和工具说明文中都包含了全国值。

不将同名自治体硬性指定为一条。 “府中市”在东京都和广岛县都有。 同时返回两个候选，由调用方进行筛选。

不让特养定员为0被解读为“全国最差”。 符合条件的保险者有90个，全部会并列第1名。 必须附上并列数量，并加上“在小规模自治体中并不罕见，居民多使用邻近自治体的设施”这一注释。 如果没有这一点，就会从 rank_insurers 的结果中得出“新乡村是全国最差的地区”这一错误结论。

如果不把领域知识嵌入到工具的响应中，每次更换调用方的模型时， 同样的误读都会再次发生。之所以放在工具侧而不是提示词中，正是出于这个原因。

使用方法

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

要从 Claude Code 使用，在此目录中启动即可读取 .mcp.json。 注册到其他客户端时的配置：

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

智能体（Phase 2・至运行确认）

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

工具通过 MCP 服务器调用（不直接 import 函数）。如果通过 import 完成， 就不算经过 MCP，“制作了 MCP 服务器”这一主张就无法被验证。

用于比较的4列

B和C都使用同一Qwen系列。 这样 B→C 的差异可解读为“仅模型规模的效果”， C→D 为“模型系列的差异”，A→B 为“硬件与世代的效果”。

只编写一条循环。 如果一边只用 SDK 的工具运行器，另一边只用手写实现， 就无法区分列间差异是模型差异还是循环实现差异。 后端只负责历史记录的转换。

实测（列A・列B）

各6次・通过 python scripts/probe_tool_calling.py 测量。

需要温度0是 7B 特有的问题

qwen2.5:7b 在默认温度下，<tool_call> 的开始标签会损坏 （出现 olith pering 等几个字符开头的乱码），ollama 的解析器无法识别， 调用会漏到正文文本中。只有结束标签 </tool_call> 残留下来是标志。温度0可解决。

qwen3.5:9b 在默认温度下也是 6/6。 这种损坏方式并非本地运行的一般问题， 而是该模型的世代・规模所特有的。

更大的差异在于“是否遵循指令”

系统提示词指示“回答前先用 get_national_baseline 确认全国基准值”。 9B 在 6/6 中全部遵循，7B 在 6/6 中一次都没有遵循。 而且 9B 还能在一个步骤中并行调用两个工具。

7B 能给出正确答案，是因为拾取了工具说明文中嵌入的全国值（24.6）， 并没有按照指示的步骤执行。差异不在于稳定性，而在于指令遵循， 工具越多，这种差异就越明显。

此比较的局限性

A→B 中硬件和模型世代同时发生了变化， 因此无法分离改善是来自 GPU 还是来自 9B。 要分离，需要在 GPU 机器上也运行 qwen2.5:7b（免费・几分钟）。

秒数方面，首次的模型加载也会拉高平均值。列A的实测中 首次 102.6秒・之后 7.6秒（平均 23.4秒）。 脚本已修改为分别输出中位数和首次值， 但列B的数值是用旧脚本采集的，因此需要重新测量。

今后的计划

• 重新测量列B（用改进版脚本重新采集秒数）

• 在 GPU 机器上运行 qwen2.5:7b，分离硬件与模型世代的效果

• 列C・D 尚未执行（会产生费用，因此等各列齐备后只执行一次）

• Phase 3: eval 本体（多问题×多次的答对率・完成率）

相关

• kaigo_matching — 介护记录的结构化提取（案1）

• kaigo_gap_analysis — 按保险者的供需缺口分析（案4・本数据的来源）