search_care_facilities全国の介護サービス事業所（約19万件）を、施設名または住所のキーワード、都道府県、サービスの種類（訪問介護、通所介護、居宅介護支援など35種）で検索します。query、prefecture、service の少なくとも一つが必要です。各事業所が提供するサービスの一覧も返します。データ出典：介護サービス情報公表システム オープンデータ（厚生労働省）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 最大件数（既定50、上限200） | |
| query | No | 検索キーワード（事業所名・住所への部分一致） | |
| service | No | サービスの種類。例: 訪問介護、通所介護、訪問看護、居宅介護支援、介護老人福祉施設 | |
| prefecture | No | 都道府県名。例: 東京都 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that each result includes the list of services the facility offers and cites the data source (MHLW open data), which is useful provenance. However, it says nothing about result ordering, pagination beyond the schema's limit, or whether results are truncated at 200 — relevant for a ~190k-record dataset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what the tool searches and its scale, then the invocation constraint, then return content and provenance. It is efficient overall; the data-source citation is defensible for trust but is the one element that does not aid tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, yet the description covers scope, scale, the min-one-input rule, and what is returned (facilities plus their service lists). The main residual gap is behavior at the result cap, but for a straightforward keyword-search tool this is close to sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns an extra point by adding a cross-parameter constraint the schema does not express (at least one of query/prefecture/service must be supplied, despite none being marked required). It also quantifies the service-type vocabulary (35 types) beyond the schema's four examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb and resource (search care-service facilities nationwide, ~190k records) and enumerates the three search axes: keyword on name/address, prefecture, and 35 service types. This distinguishes the tool from its single-facility siblings by scope (nationwide keyword sweep rather than by-ID lookup), though it never explicitly names a sibling such as search_care_nearby to complete the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"query、prefecture、service の少なくとも一つが必要です" gives an explicit precondition for calling, which is valuable given the schema declares zero required parameters. It still lacks exclusions: nothing tells the agent when to prefer search_care_nearby (radius search) or get_care_facility (detail lookup) over this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.