Pono-Pono｜フェムケア・デリケートゾーンケア情報

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 context beyond them: it returns the FULL page body and should be used as the accuracy authority before answering on critical facts.

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 front-loaded sentences that each carry a purpose: what it returns, what id accepts, and when accuracy demands it. The full site name in quotes is somewhat verbose but not wasteful enough to hurt the structure.

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 description covers the input source and the usage context. The main gap is that it never clarifies its relationship to the closely related get_page sibling, which leaves a real ambiguity unresolved.

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 the single id parameter including that a URL or path (even in Japanese) is acceptable. The description repeats the same information (id from search results, or URL/path) without adding format or syntax detail, so it meets the baseline 3 rather than exceeding 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 states a specific verb+resource: it returns the full body text of the loaded page on pono-pono.co.jp. It is clear what the tool does, but it never distinguishes itself from the near-identical sibling get_page, so an agent cannot tell the two apart 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 concrete when-to-use guidance: for pricing, dates, conditions, and terms, verify the body text with this tool before answering. However, it names no alternative (e.g. get_page) and states no when-not-to-use condition, so the routing against siblings is left implicit.

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, openWorldHint=false and destructiveHint=false, so safety is covered. The description usefully adds deprecation status and that the return shape differs from fetch, but it never says how the shape differs, nor anything about errors, limits, or truncation of page bodies.

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 that each carry a distinct load: identity/legacy status, behavior relative to fetch, and migration instruction. The legacy notice is front-loaded. Minor redundancy in naming the site and repeating the backwards-compatibility rationale.

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-only legacy alias with no output schema, the description supplies everything needed to decide whether to call it: what it does, that it is superseded, and the preferred alternative. The only omission is the nature of the differing return format, which is low-stakes given the agent is told to use fetch instead.

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 'url' parameter already documented in the schema ('ページの URL かパス（日本語のままでも可）'). The description adds no additional semantics about the parameter, 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 ('fetch と同じようにページの本文を返します') and explicitly identifies itself as the former name of the fetch tool, so an agent can place it against its sibling immediately. It is slightly indirect because it defines itself by reference to another tool rather than describing its own output, but the core purpose (read page body) is unmistakable.

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 both sides of the routing decision: this exists only for already-connected clients ('すでにつないでいる人のために残しています'), and new usage should go to fetch ('新しく使うときは fetch を使ってください'). The alternative is named and the condition selecting it is 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?

Annotations already establish read-only, non-destructive, closed-world behavior, so the bar is lower; the description usefully adds pagination semantics (50 per call, limit up to 200, offset to continue) and return fields (title and URL). No output schema exists, so stating the returned fields adds real value, though per-call cost or ordering is not mentioned.

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 tightly packed sentences: what is returned, then pagination mechanics, then when to use it. Front-loaded with the resource and output fields, with zero filler.

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 compensates by naming the returned fields, and it covers pagination fully. What is missing is minor: no indication of total result count or ordering, which would help the agent decide when to stop paginating.

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 0%, so the description must carry the load, and it does: it explains limit's batch size and its 200 maximum, and offset as the continuation cursor. It does not mention the minimum bounds (1, 0) or the default offset=0, but the operative meaning of both parameters is conveyed.

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: it returns the list of pages loaded on pono-pono.co.jp as title + URL, which is exactly what 'list_pages' claims. It does not, however, explicitly distinguish itself from close siblings like search_pages or site_overview, leaving the agent to infer the boundary.

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 two concrete situations for use: when you want to know what pages exist, and when a search fails to find something. The second clause implicitly positions search as the alternative, but no sibling is named explicitly and there are no stated exclusions.

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, closed-world, non-destructive behavior. The description adds valuable scope context: only previously loaded pages are searched, network-wide content and post-load updates are excluded, and it specifies expected behavior when no match is found. Return format is largely covered by 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?

Front-loads what the tool does and the site it indexes, then layers scope limits and fallback guidance. Reasonable length but slightly dense; every sentence adds value.

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?

Comprehensive for a 1-param read-only search tool: purpose, scope boundaries, and failure handling are covered, and return values are handled by the output schema. The main gap is no differentiation from the similarly named sibling 'search_pages'.

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 there is only one string parameter with an inline example. The description adds no syntax, operators, 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?

States a specific verb+resource (探す/ページ), names the site, and describes what is returned (抜粋 + URL). It does not explicitly distinguish itself from the very similar sibling 'search_pages', nor from 'fetch'/'get_page', which is a missed opportunity given this is a common naming collision.

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 clear when-to-use guidance ('質問されたらまずこれを使ってください'), scope constraints (読み込んだページのみ), and iterative fallback advice (rephrase the query, review candidate pages, don't guess if not found). An explicit comparison with sibling 'search_pages' is absent.

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 genuinely non-structured context: the tool is deprecated and retained only for backward compatibility, and it diverges from `search` in return format. It stops short of saying how the format differs or noting pagination/limit behavior.

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 tight sentences plus a parenthetical; the deprecation notice is front-loaded and the redirect to `search` lands last, which is the right ordering. The parenthetical about the site name is slightly more context than strictly needed but earns its place by identifying the resource.

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 some return-value burden; it flags that the shape differs from `search` but never describes it. For a low-complexity legacy alias whose main decision (avoid unless already integrated) is fully answered, 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?

With only 50% schema description coverage, the `limit` parameter (default 5, max 20) is documented nowhere, and the description says nothing about parameters at all — no syntax, no effect of `limit`, no query-format hints. The description fails to compensate for the coverage gap.

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 (site-wide search) and explicitly frames itself as the legacy name of the site-search function, naming the sibling `search` as the equivalent. It distinguishes itself from that sibling by noting a different return shape, though it defines its own behavior only relationally to `search` rather than describing the output itself.

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 when-to-use (only for integrations already wired to it) and an explicit when-not-to-use with the named alternative: '新しく使うときは search を使ってください' (use search for new work). The agent has no inference left to make about tool selection.

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 a safe read-only, non-open-world profile. Since there is no output schema, the description's disclosure of the returned fields (site type, blurb, pages loaded, main pages) meaningfully compensates and is the main value-add.

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: what is returned first, then the usage trigger. No filler, though the site identity is stated twice (name plus domain), a minor redundancy.

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 zero params, annotations covering the safety profile, and no output schema, the description supplies exactly the missing piece (what comes back) and the sequencing hint. Adequate for this low-complexity tool, lacking only sibling routing detail.

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 takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly introduces no parameter discussion.

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 verb (返します/returns) and resource (site overview for pono-pono.co.jp) and enumerates what the response contains: type, description, page count, and main pages. It does not explicitly contrast itself with siblings, though '最初に' hints it is the entry point.

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?

States a clear usage condition: use it when you first want to grasp the whole picture of the site, implying it precedes fetch/get_page/list_pages. No explicit exclusions or named alternatives, so it stops short of a 5.

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