KIKARET

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction exists. The description adds value beyond those hints by enumerating what the caller receives: identity, official URL, and resolved fields like prefecture, city, address, phone, and facility type.

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 focused sentence conveys the tool's purpose and return payload with no filler. The key action is front-loaded and every clause adds useful 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?

For a simple, single-parameter lookup with strong annotations, the description provides enough detail about returned values to guide an agent. It does not describe missing-ID or error behavior, and 'such as' leaves the return list slightly open-ended, so it is not fully comprehensive.

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 schema already documents facility_id thoroughly with type, format, pattern, and a note that it is returned by search_facilities. The description only restates the parameter name without adding semantic detail, so baseline 3 is appropriate.

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 action — 'Get one KIKARET facility by facility_id' — and names the resource clearly. It also lists the returned content, distinguishing it from search_facilities, which would return multiple facilities.

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 this tool is for fetching a single facility when you already have an ID, and the schema parameter notes that facility_id comes from search_facilities. It does not explicitly contrast with get_facility_knowledge or state when not to use it, so it falls short of a full 5.

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 mark the tool read-only and non-destructive. The description adds a useful behavioral default: omitting keys returns all resolved knowledge with source metadata. It does not cover error or empty-result behavior, but this is a low-risk read operation.

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 with no filler; the core operation, parameter source, and default behavior are front-loaded. Every sentence adds 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?

For a simple read-only getter with full schema coverage, the description is sufficient to select and invoke the tool. It even states that results include source metadata, though it does not detail the exact response shape beyond that.

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 both facility_id and keys are documented in the schema. The description adds provenance for facility_id and restates the omit-to-return-all behavior, but no meaningful semantics 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 action ('Get'), a distinct resource ('resolved KIKARET knowledge'), and scope ('one facility'). This is clearly separable from siblings like get_facility (facility record) and search_facilities (facility search).

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 concrete provenance instruction: take facility_id from search_facilities, and explains the optional keys behavior. It does not explicitly say when to use this tool instead of get_facility, so it falls short of full alternative 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description aligns with those annotations by describing a read-only availability check, but it does not disclose the response format or what the optional 'message' parameter does.

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 sentence that immediately states the tool's purpose without any filler or redundant detail. It is appropriately sized for a simple ping operation.

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 low-complexity health-check tool, the description plus annotations are nearly sufficient for an agent to invoke it correctly. The main gaps are the undocumented optional 'message' parameter and the absence of any output schema or return-value description, but these are minor for a ping 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?

The schema has one optional string parameter 'message' with no description and 0% schema description coverage. The tool description does not explain what this parameter means or how it affects the invocation, so an agent cannot know whether to supply it.

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 ('check') and a clear resource ('KIKARET MCP server availability'), making it obvious that this is a health-check or ping tool. This distinguishes it from the sibling facility-related tools without needing to inspect their schemas.

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 does not explicitly state when to use this tool versus alternatives or mention any exclusions. However, the phrasing implies it should be used to verify server availability, likely before other calls, which provides only implicit usage 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context by stating it performs name-based search and 'Returns facility IDs and basic location/contact information,' which is especially valuable given there is no output schema.

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 with no wasted content. The core action is front-loaded, followed by usage guidance and return-value summary. Every sentence 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 simple read-only search tool with full schema coverage and clear sibling context, the description covers what the tool does, when to use it, and what it returns. Nothing essential is missing for an agent to select and invoke it.

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 schema already documents both query and limit fully. The description adds the search-by-name framing but does not provide extra parameter meaning beyond what the input schema already contains.

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: 'Search KIKARET for childcare facilities by facility name.' It also differentiates from siblings by saying 'Use this first when you do not know the facility_id,' which clearly positions it against 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?

Provides an explicit usage condition: 'Use this first when you do not know the facility_id.' It implies that a facility_id-based lookup is the alternative, but does not explicitly name the sibling tool or state when not to use it.

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