コエカツ

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds useful behavioral context beyond the annotations: it discloses that the whole page body is returned (not a summary or excerpt) and frames the tool as the verification step before citing figures.

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 short sentences: what it returns, when to use it, and a verification directive. It is front-loaded and free of filler, though the middle sentence is dense with examples and could be tightened.

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?

An output schema exists, so return values need not be explained, and the read-only annotations cover the safety side. What remains missing is any differentiation from the similarly named sibling 'get_page', which is the one gap that could cause a wrong tool selection.

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 there is a single required 'id' parameter, so the schema already documents accepted forms (page URL, path, or the id from search results). The description adds nothing about the parameter and simply calls out the baseline 3.

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 the full body text of a 'コエカツ' page from start to finish, and it scopes the use case to reading survey detail. However, it never distinguishes itself from the sibling 'get_page', which by name appears to retrieve the same resource, so an agent cannot fully disambiguate the two from the description alone.

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 clear when-to-use guidance: use it to read in detail the question text, per-choice percentages and response counts that 'search' surfaced, and explicitly says to confirm with this tool before quoting numbers. It does not state when NOT to use it or why one would pick it over the sibling 'get_page', so the routing is not complete.

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 this a safe read (readOnlyHint true, destructiveHint false, openWorldHint false), so the safety profile is covered. The description adds genuinely useful non-schema context: this is a deprecated alias being kept alive for existing integrations and returns a different shape than fetch.

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 short sentences, front-loaded with the legacy status so an agent knows immediately to prefer fetch. No filler, though the second sentence about return shape could have been made concrete rather than merely asserting a difference.

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 carries the burden of explaining return values, yet it only says the shape 'differs' without describing it. For a deprecated alias that is tolerable, but it is a real gap for an agent that must parse the response.

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?

With a single required url parameter and 100% schema description coverage, the schema already documents the parameter, including that Japanese text is acceptable. The description adds nothing about the url, 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?

The description states a specific verb and resource (returns the page body) and frames the tool against its sibling fetch by noting the return shape differs. It is clear that this is a legacy alias, though it never says how the shape differs, which is the one thing that would fully disambiguate it from fetch.

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 explicit routing guidance: use fetch for new usage, and this exists only for users already connected under the old name. That covers the 'when not to use' case clearly, but leaves the specific condition under which an agent should still pick get_page unspecified beyond backward compatibility.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds useful context by naming the returned fields and topic structure, but says nothing about pagination or result-size behavior despite limit/offset existing.

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-loads what the tool returns in the first sentence, then gives concrete topic examples and a usage cue. Two sentences with no filler; appropriately sized.

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 correctly explains the return shape (titles and URLs). However, for a parameterized listing tool it omits any pagination guidance, leaving a gap an agent would need when result sets exceed the default limit.

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 0%, so the description should compensate for the limit/offset parameters, yet it never mentions paging, defaults, or ranges. With 2 undocumented parameters the description leaves the agent to infer pagination entirely from the raw 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?

States a specific verb (list) and resource (pages loaded into 'Koekatsu') with what is returned (titles and URLs). The topic-category examples make the scope concrete, though it never explicitly distinguishes itself from siblings like search_pages or site_overview.

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 a context cue — 'use when you want to narrow by field and line up surveys' — which implies a filtered-listing use case. But it offers no explicit when-not-to-use and does not name any sibling alternative such as search_pages.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: results come with excerpts, and answers must carry the response count, survey period, and コエカツ attribution. Return format is otherwise deferred to the 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?

The description is front-loaded with purpose, then usage, then query style, then answer requirements. It is somewhat long but each clause contributes distinct information, with no obvious padding.

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 an output schema present and annotations covering safety, the description only needs to carry purpose, usage, and any special obligations. It supplies purpose, usage, and the citation requirement, though the missing sibling-level disambiguation from 'search_pages'/'fetch' leaves a small gap.

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% for the single 'query' parameter, which already supplies an example. The description adds example topic terms ('SEO 外注', 'AI スクール'), reinforcing but not extending the schema's meaning, so the baseline of 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: it searches within the コエカツ survey site for matches in surveys and aggregate results, returning excerpts. This is concrete, but it never distinguishes itself from the sibling 'search_pages', leaving the agent to infer the boundary between site search and page 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 clear context: 'まずこれを使ってください' (use this first) when you want to know what most people choose or how people feel, with topic areas and example queries. It does not name alternatives or state when NOT to use it, so it stops short of the top score.

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 the safe read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the safety burden is lifted. The description adds genuinely useful context beyond the annotations: this is a deprecated/legacy-named feature retained for backward compatibility and it returns a different shape than `search`. It does not detail pagination or the exact return structure.

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 short sentences, front-loaded with the legacy status and then the routing advice, with no filler. Slightly indirect by leading with the meta-notion of a former name before the actual function, but 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?

With no output schema, the description carries some burden for return values, and it only says the shape is 'different' from `search` without describing how. For a deprecated alias with annotations covering the safety profile and an explicit steer to `search`, this is adequate but not complete.

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 50% — `query` is documented with an example while `limit` is only structurally constrained (default 5, min 1, max 20). The description adds nothing about either parameter, but the schema's structured constraints largely self-document them, so the baseline of 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?

States a specific verb+resource (サイトの中を探す / search within the site) and immediately distinguishes itself from the sibling `search` by noting the return format differs. An agent can tell it is a legacy alias for `search` without opening either 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?

Explicitly names when to use it (kept for users who are already connected / legacy callers) and the alternative to use instead (`search` for new integrations). The exclusion and the routing are both stated outright.

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 readOnly, non-destructive, and closed-world. The description adds domain context (a free survey site with public graphs) but does not disclose return format, latency, or other behavioral traits beyond what annotations provide.

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: purpose first, then site context, then usage. Efficient and front-loaded, though the middle sentence is slightly descriptive.

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 tool with no output schema, the description adequately explains what the overview contains and when to call it. Nothing critical is missing, though it could specify the exact structure of the overview.

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?

No parameters are defined, so the baseline of 4 applies. The description does not need to explain any inputs.

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 (returns an overview of Koekatsu) and then describes what that overview contains. It implicitly distinguishes itself from page-fetching siblings by positioning itself as a first-look tool, but does not name any sibling explicitly.

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?

Gives a clear condition for use: when you first want to know what kind of site it is and what survey topics exist. No explicit when-not or alternative tool is named, but the context is clear.

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