エージェント図鑑（医療・介護・保育）

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: it discloses that day/time default to the current time in JST, that department/service breakdowns are truncated to top 15 / top 10, and that childcare coverage is limited to Tokyo and Osaka-city pilot records with coordinates only. Remaining gaps are operational (latency, caching, error behavior), which are minor for an aggregation read.

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?

Front-loaded: the first clause states the operation, scope and use case before the long output enumeration. The enumeration is dense and unstructured (one continuous paragraph, no bullets), but with no output schema almost every listed field earns its place for an agent judging output fitness.

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, so the description must explain return values — and it enumerates them thoroughly across all four data domains, plus defaults, truncation limits and data-coverage caveats. For a complex, five-parameter aggregation tool this is complete enough to invoke correctly.

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 description coverage is 100%, so the schema already documents all five parameters including ranges and the HH:MM pattern. The description adds the meaningful link that day and time jointly define the 'open at that day/time' count metric, but it does not add syntax or interpretation beyond that.

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?

Specific verb+resource: aggregates medical/care/childcare facilities and population within radius_m of a lat/lon point, and names the use case (商圏分析・営業地域調査). It also explicitly differentiates from the sibling list-style tools with '個別施設の一覧ではなく集計値のみを返します', so an agent can tell it apart from search_nearby/get_facility without opening a schema.

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?

It gives a clear usage context (trade-area / sales-territory analysis) and a negative guide — it returns aggregates only, not individual facility lists — which steers an agent away from using it as a facility lookup. It never names a specific sibling (e.g. search_nearby) as the alternative, so the routing is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the tool returns all fields plus provided services with capacity and available weekdays, which is useful, but omits error behavior, permissions, and whether it is strictly read-only.

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?

A single sentence front-loads the identifier constraint and then states the action and return scope. It is efficient with no wasted wording, though slightly dense.

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?

For a simple one-parameter read tool with no output schema, the description explains both input format and return contents. It lacks failure-mode and sibling-differentiation details, but is largely complete for correct invocation.

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 description coverage is 100%, including a pattern and examples. The description restates the 10-character format and the A/B third-character option, adding verbal context but no meaning beyond the schema.

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 specific verb (取得, retrieve) and resource (介護事業所, care facility) tied to a unique identifier, and clarifies it returns one record. It does not explicitly distinguish itself from siblings like get_facility or get_childcare_facility, leaving domain scope to be inferred.

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?

Usage is implied: call this when you have a specific care facility number and need full details. There is no explicit when-not guidance or mention of alternatives like the search tools, so an agent must infer the routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It does disclose what is returned (all published fields: capacity, accepted ages, opening hours, corporate info), which is valuable since there is no output schema, but it says nothing about behavior on a nonexistent/invalid ID or about read-only semantics beyond the verb 取得.

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?

A single front-loaded sentence with no filler. The parenthetical field list earns its place by previewing the return payload, though the ID format detail duplicates the schema pattern.

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?

For a one-parameter read tool with no annotations and no output schema, the description covers the input format, the scope (one record), and the shape of the returned data. Only error/not-found behavior is left unstated, a minor gap at this complexity.

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 description coverage is 100%, and the schema already documents the ID, its 16-hex-digit pattern, and that it comes from search_childcare_facilities. The description restates the 16-digit hex format, adding redundancy rather than new meaning, so the baseline 3 applies.

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?

States a specific verb (取得) and resource (保育施設), and the scope is explicit: exactly one facility looked up by ID, returning all published fields. This clearly separates it from the search_* siblings, though it never names them.

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?

The description implies usage ('specify the ID to get one facility'), which makes the lookup-by-ID pattern inferable, and the schema notes that IDs come from search_childcare_facilities. There is no explicit when-to-use vs when-not guidance or named alternative in the description itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It does add real value by disclosing what is returned: all facility fields (address, phone, departments, coordinates) plus conditional hours and hours_snapshot when schedule data exists. It does not state what happens when the code matches no facility (empty result vs error), nor whether the call is a pure read with any rate limits.

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?

Two sentences, front-loaded with the identifier and the result shape, with no filler. The second sentence about conditional hours data is well placed, though slightly dense with parenthetical field names.

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?

For a single-parameter lookup with no output schema, the description is nearly complete: it explains the return payload, including the conditionally present hours/hours_snapshot. The only meaningful gap is not-found behavior, which matters for an agent deciding how to handle a miss.

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?

There is only one parameter, and schema coverage is 100%: the schema already documents the 10-digit pattern, the example 1310110049, and the medical-institution-code semantics. The description only repeats the '10-digit code' constraint, so it adds no meaning beyond the schema and the baseline 3 applies.

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 specific verb (取得) and resource (施設の全項目) along with the precise key (10桁の医療機関コード) and scope (1件取得). This clearly separates it from the sibling search_facilities/search_nearby tools, which return sets rather than a single record identified by code.

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?

Requiring a known 10-digit code implicitly signals that this is a direct-lookup tool rather than a discovery tool, but the description never names the alternatives (search_facilities, search_nearby, analyze_trade_area) or states the condition that selects them. The agent has to infer when to use this versus the search siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses result ordering (nearest first) and that the service filter restricts by service type, but says nothing about permissions, result shape, truncation by limit, or behavior at the radius boundary. Adequate but incomplete for an unannotated tool.

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?

Two short sentences, front-loaded with the core behavior (proximity search ordered by distance) before the optional narrowing filter. No redundant restatement of schema fields or defaults, and nothing that could be cut without losing information.

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?

With a simple five-parameter schema, no annotations, and no output schema, the essentials are covered. Gaps remain around what a result record contains, what happens on empty results, and which string values 'service' accepts, any of which an agent would need to call this reliably.

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 description coverage is 100%, so all five parameters including latitude, longitude, radiusKm, limit, and service are already documented in the schema with bounds and defaults. The description adds a small amount about the semantics of 'service' filtering and the radius concept, but no accepted values for the free-text service string, which is the one genuinely ambiguous parameter.

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 names a specific verb and resource: it returns care service facilities within a radius in kilometers of a latitude/longitude, ordered by proximity, with an optional service filter. This clearly separates it from name-based siblings like search_care_facilities. It stops short of naming a specific sibling to disambiguate against, which keeps it at 4 rather than 5.

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?

Usage is implied rather than stated: an agent infers it should call this when it has coordinates and wants nearby facilities, and that 'service' narrows results. There is no explicit when-not guidance, no mention of search_care_facilities or search_nearby as alternatives, and no note on what happens when no facilities are found in range.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full behavioral burden; it does disclose the data source (自治体公表リスト), the pilot-only geographic coverage, and the optional return fields (定員, 受入年齢). It omits ordering of results and what happens when zero facilities match, so an agent cannot fully predict the response shape.

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?

Four sentences, front-loaded with purpose followed by the constraint, coverage caveat, and return/source notes; no filler. The constraint sentence could have been merged with the purpose sentence for tighter structure, but nothing is redundant.

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, so the description must cover the return profile; it names two optional returned fields and the source but not the record shape or count behaviour beyond the limit parameter. The geographic narrowness is well flagged, making the definition usable, though not exhaustive for a tool with five parameters.

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 description coverage is 100%, so the baseline is 3. The description adds one genuinely valuable constraint not expressible in the schema — the at-least-one-of requirement across query/prefecture/city, which the empty required list does not convey — but adds no clarification on how the enum 'type' interacts with that rule.

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 specific verb (検索) plus resource (保育施設) and enumerates the covered facility categories, so the agent knows exactly what corpus is searched. It implicitly separates itself from the nearby-search siblings by emphasizing keyword/prefecture/city filtering, but never names an alternative tool outright.

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?

It gives an explicit precondition (at least one of query, prefecture, or city) and discloses the geographic pilot scope (東京都 and 大阪市, ~6,100 records) with a note that coverage is expanding, which directly informs when the tool will return nothing useful. It stops short of naming a sibling tool to use when a user wants radius-based lookup.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must carry behavioral disclosure. It does disclose non-obvious behavior: results are distance-sorted, facilities without coordinates are silently excluded, and the dataset is limited to two metro areas. It does not cover permissions, rate limits, or what happens when zero results match, leaving meaningful gaps for a no-annotation tool.

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 tight sentences, zero filler, with the core behavior (radius search sorted by distance) front-loaded before the filter note and the coverage caveat. Every clause carries information an agent needs.

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?

For a 5-parameter search tool with full schema coverage and no output schema, the description covers scope, ordering, filtering, and the geographic limitation. The notable remaining gap is that return-value shape and pagination are unaddressed, though the sibling set and schema make the contract fairly guessable.

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 description coverage is 100%, so every parameter (including defaults for limit=30 and radiusKm=1) is already documented in the schema. The description reinforces that type acts as a filter and that radius is in km, but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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 specific verb and resource ('緯度経度を中心に半径（km）以内の保育施設を近い順に返します') with the result ordering and the coordinate-only constraint. It implicitly separates itself from generic siblings like search_nearby and search_facilities by fixing both the resource (childcare facilities) and the geo-radius semantics, though it never names an alternative tool.

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?

It gives a real usage constraint — coverage is currently limited to Tokyo and Osaka City — which tells the agent when the tool will return nothing. It also notes the type filter and the coordinate requirement, but names no sibling alternative and gives no guidance on when to prefer search_childcare_facilities or search_nearby instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden, and it does disclose meaningful behavior: timezone is explicitly Japan time, open_now and day/time act as mutually distinct narrowing modes, and the response includes weekday hours with null for facilities lacking data. It omits result ordering and pagination/offset behavior beyond the limit parameter, so it is not fully complete.

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?

The sentences are ordered from overall scope to preconditions to filtering modes to return values, and the core scope statement comes first. There is mild redundancy where open_now and day/time semantics partly restate the schema descriptions, but no sentence is wasted.

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?

For a 7-parameter search with no output schema and no annotations, the description covers filtering and filter preconditions well and partly describes the return payload (hours, nullable). It does not describe the rest of the facility record returned or how limit interacts with large result sets, which an agent would need to know to plan a search.

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, but the description adds the cross-parameter constraint that query or prefecture must be present, which the schema does not state anywhere. It also reinforces that day and time are meant to be combined and that open_now uses JST, adding meaning beyond the field-level text.

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 gives a concrete verb (検索) and resource (全国の薬局・医科・歯科医療機関) plus the filterable facets, so an agent can tell this is the keyword/attribute search over the facility database. It does not explicitly name get_facility or search_nearby as the alternatives, so sibling differentiation is implicit rather than stated.

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?

It states a real precondition ('query と prefecture の少なくとも一方が必要です') and explains the open_now and day+time filters, which guides invocation. However, it never says when to choose this over search_nearby (geo search) or get_facility (single-record lookup), leaving the sibling choice to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden. It does disclose real behavior: nearest-first ordering and the fact that bbox overrides latitude, longitude, and radiusKm, which is genuinely useful. It says nothing about permissions, rate limits, pagination, or what happens when neither bbox nor coordinates are supplied, and those gaps matter for a tool whose inputs are all optional.

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?

Two short sentences; the primary radius behavior is front-loaded, and the bbox alternative with its precedence note follows. There is no filler, though the parenthetical syntax detail partly duplicates what the bbox schema description already states.

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?

With six parameters and no output schema, the description should mention what is returned and how results are limited; limit and ordering appear only in the schema. Precedence is covered, but the no-location-parameter case and the shape of the response are not, leaving gaps for a moderately complex search tool.

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 description coverage is 100%, so the baseline is 3, and the description exceeds that baseline by stating the precedence relationship between bbox and the latitude, longitude, and radiusKm parameters. That interaction is semantic and is not expressed in the schema at all, which is exactly the kind of value the description should add.

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 names a specific verb and resource: it returns (返します) medical institutions (医療機関) ordered by proximity within a radius around a lat/lng point. It is clear what the tool does, but it never contrasts itself with the siblings search_facilities or get_facility, so an agent must infer which one to pick.

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?

The description documents both usage modes, radius search and direct bbox specification, and states the precedence rule when both are supplied. It does not say when to prefer this tool over search_facilities or analyze_trade_area, and it does not cover the case where no location parameter is given at all.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.