学童さがし (Gakudo Sagashi)

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

Annotations already declare readOnly, idempotent, openWorld=false and non-destructive, so the safety profile is covered. The description adds behavior the annotations do not: the response is human-readable text plus a page URL, which matters because there is no output schema. It omits error behavior for a missing id, keeping it below a 5.

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?

One sentence, front-loaded with the verb and the identifier constraint, with the return format appended. Nothing is redundant with the annotations or schema.

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 read tool with full annotation coverage, the description supplies the one thing structured fields cannot: what comes back (text + URL), which substitutes for the absent output schema. Only edge-case behavior (unknown id, not-found) is unaddressed.

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% and the single id parameter is already documented, so the baseline is 3. The description adds provenance semantics — the id must come from search results — which is meaningfully more than the schema's bare type/description.

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 ('Fetch') and resource ('one facility by id') plus the return shape ('readable text plus its page url'), which separates it from search/search_facilities/list_wards siblings. The parenthetical ties the id back to the search tool, making the retrieval-by-id contract unambiguous.

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 phrase 'id (as returned by search)' clearly implies this tool is used as a follow-up to search rather than as a discovery tool, which is the key routing decision. It stops short of explicitly excluding alternatives or stating what to do with an unknown/expired id, so it is clear context rather than full when/when-not guidance.

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?

The annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuinely non-derivable semantics: null means 'not published by the facility / 要問合せ' and never 0 — a critical distinction for interpreting fees and hours that appears nowhere in the structured fields.

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-loaded with the scope, that packs the return-field inventory and the null-vs-zero rule with zero redundant wording. Every clause carries information an agent would otherwise have to guess.

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 no output schema, the description compensates by enumerating the returned fields and explaining the null sentinel. For a one-parameter read tool whose annotations already declare safety, nothing an agent needs to call it correctly or interpret the result is missing.

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 sole parameter's provenance (from search_facilities or search) is fully documented in the schema. The description adds no further format, validation, or failure semantics for slug, 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?

Names a specific resource (one facility) and enumerates exactly what it returns: hours, pickup schools, fees with conditions, source URL, verification date, application page. That is far more than a restatement of the name. It stops short of a 5 because it never names the sibling it complements (search_facilities), leaving the routing to the slug parameter's schema note.

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 only implied: the single required slug, documented in the schema as coming from search_facilities or search, signals this is the follow-up detail call after a search. There is no explicit when-to-use/when-not and no statement about what happens if the slug is unknown.

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?

Annotations already establish that this is a safe, read-only, idempotent, non-destructive, closed-world operation. The description adds useful context about returned data components, but it does not describe output structure, pagination, or other behavioral details beyond those annotations.

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 description is a single compact sentence that front-loads the core resource and then lists the included data. It contains no filler or redundant explanation.

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 zero-parameter, read-only metadata tool, the description covers the key contents an agent needs to decide whether to call it. It is slightly incomplete because it does not specify the exact return shape or whether the result is a list, object, or grouped structure.

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?

The tool has zero parameters, so there is no parameter semantics to document. The schema is effectively self-explanatory, and the description does not need to compensate for any missing parameter coverage.

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 resource, Tokyo wards, and enumerates the data included: facility counts, feature tags, data date, and usage rules. It is clear what the tool returns, though it does not explicitly differentiate itself from sibling tools such as search, fetch, or get_facility.

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?

There is no explicit guidance on when to use this tool versus alternatives. The description implies a metadata-listing purpose but never states when an agent should choose list_wards over search, search_facilities, fetch, or get_facility.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without prose. The description adds the return shape (ids only) which is genuinely helpful for chaining. It says nothing about matching semantics (substring vs AND/OR across the listed facets), result cap, or ordering — real behavioral gaps for a search 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, zero filler, with the search scope front-loaded and the return value trailing. Every clause earns its place.

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 tool with a full schema, complete annotations, and no output schema, the description covers the main thing an agent needs beyond structured fields: that the result is ids destined for fetch. Only the multi-keyword combination rule and any result limit are left unstated.

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% and the single parameter already carries a concrete example (世田谷 英語 / 豊洲小). The description adds no meaning beyond that — it does not say whether multiple keywords are ANDed or ORed, which is the one thing an agent actually needs to know here. Baseline 3 is correct.

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 (search) plus the exact searchable facets — facility names, areas, wards, operators, tags, pickup schools — and what comes back (ids). That is materially more than the name/title. It does not, however, distinguish itself from the sibling search_facilities, which an agent will have to disambiguate on its own.

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?

"Returns ids for fetch" implies the intended two-step workflow: search here, then call fetch with the ids. That is useful implied guidance, but there is no explicit when-to-use versus search_facilities/get_facility, and no statement of when this tool is the wrong choice.

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?

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior. The description adds useful behavioral context beyond that: it returns compact rows, points to get_facility for richer details, and explains that null means unpublished (要問合せ), never 0.

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 tightly written sentences with no wasted words. The core search purpose and the get_facility routing are front-loaded, and the null caveat is compactly appended.

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 12-parameter search tool with full schema coverage and annotations, the description provides what an agent needs: search scope, result nature ('compact rows'), where deeper detail lives, and how to interpret nulls. No output schema is present, but the description sufficiently covers return expectations.

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 fully documents all 12 parameters. The description reinforces several filter concepts but does not add syntax or constraints beyond the schema; the null explanation is return-value semantics rather than parameter meaning.

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 uses a specific verb ('Find') and resource ('private after-school care facilities in Tokyo') and enumerates the filtering dimensions. It also distinguishes itself from get_facility by saying detailed fee conditions, pickup schools, and application routes live there.

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 clearly indicates when to use this tool: searching facilities by ward, feature, pickup school, fee ceiling, closing time, and more. It explicitly routes users to get_facility for detailed data, though it does not contrast itself with the generic search or list_wards siblings.

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