ヨミタス

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is known. The description adds useful behavioral context beyond the annotations: it returns the full text from beginning to end and preserves original wording without paraphrasing. This gives the agent a clearer expectation of the output.

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 two sentences, front-loads the core action and resource, then immediately states the practical use case. There is no redundant information or 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?

The tool has a single required parameter and an output schema present, reducing the need for return-value documentation. The description provides sufficient context for a simple read operation, though it could more clearly differentiate itself from the sibling get_page to fully remove selection ambiguity.

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 fully explains the 'id' parameter including acceptable forms (URL, path, Japanese text). The tool description adds no parameter-level information, so with full schema coverage a baseline score 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?

The description states a specific verb ('返します' - returns) and resource ('ページの本文' - page body text), making it clear this tool retrieves full page content. It provides a clear use case for exact verification, but it does not explicitly distinguish itself from the sibling tool get_page, which may have overlapping functionality.

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 explicitly states when to use the tool: when needing to verify terms of service, privacy policy clauses, or usage instructions accurately without paraphrasing. This gives clear context, but it does not mention when not to use it or point to alternatives among the sibling tools.

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, covering the safety profile. The description adds that the return format differs from fetch but does not explain how, which is a minor gap. It does not contradict annotations, and the legacy context is helpful but not rich.

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 two sentences with no wasted words. The legacy context is front-loaded, and the directive to use fetch is placed clearly. It is efficient and easy to scan.

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?

The tool is simple with one parameter, annotations cover safety, and no output schema exists. However, the description does not specify the actual return format, which could be necessary for someone using this legacy tool. Since the description directs new users away, it is adequate but leaves a gap for existing users who need to know the format.

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%, with the url parameter described as 'ページの URL かパス（日本語のままでも可）' (page URL or path, Japanese allowed as-is). The description adds no additional parameter information, so it does not compensate beyond what the schema already provides. Baseline 3 is appropriate given full 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 clearly states that the tool returns the page body, similar to fetch, but with a different return format. It also identifies itself as a legacy version of a previously named function, distinguishing it from the fetch sibling. However, it does not specify exactly what the return format is, so the purpose is clear but not fully detailed.

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 explicitly directs new users to use fetch instead, stating '新しく使うときは fetch を使ってください' (use fetch when using anew). It also notes that this tool is kept for existing users, providing clear context on when to use this tool vs the alternative. This is explicit and leaves no ambiguity.

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, covering the safety profile. The description adds useful context about the returned content (titles and URLs) and explains the meaning of specific path prefixes, but it does not disclose pagination behavior or ordering.

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 concise and front-loaded with the core function, followed by useful path-prefix context. The path enumeration is helpful for understanding the returned list and does not feel excessive.

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 list tool, the description covers the main return value (titles and URLs) and gives helpful context about page categories. However, with no output schema and no parameter semantics, the absence of pagination details leaves a notable 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 0%, so the description needed to explain limit and offset, but it does not mention them at all. The parameter names and schema constraints are somewhat self-explanatory, but the description adds no meaning to the pagination parameters.

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 clearly states the tool returns a list of pages loaded in Yomitas, including titles and URLs. This distinguishes it as a listing operation from siblings like fetch or search_pages, though it does not explicitly name those alternatives.

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 seeing what pages exist, but it gives no explicit guidance on when to choose list_pages over search_pages, get_page, or site_overview. No exclusions or alternative routing are provided.

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-only profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description only needs to add non-annotation context. It does so by noting that results come with excerpts and by clarifying the closed-world scope (Yomitasu pages and site intro pages). It does not discuss pagination, result limits, or authentication, but those are minor given the annotation coverage.

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: it first states what the tool does, then enumerates searchable topics, then gives usage guidance and limitations. The list of topics is informative but slightly verbose, and every sentence earns its place by clarifying scope or usage.

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 search tool with 100% schema coverage, an output schema, and clear annotations, the description covers purpose, scope, usage priority, and a key limitation. The only notable gap is the lack of explicit differentiation from the sibling 'search_pages', which could cause selection ambiguity.

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 fully documents the single 'query' parameter with a description and example, so the baseline is 3 when schema coverage is 100%. The tool description adds no additional syntax, format, or constraint information about the query parameter beyond what the schema already provides.

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 Yomitasu pages for matching text and returns excerpts. It also scopes the searchable content to Yomitasu's own pages (mechanism, AI app connection, pricing, FAQ, policies, etc.). However, it does not differentiate itself from the sibling 'search_pages', which an agent might reasonably confuse with this 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?

The description gives explicit usage guidance: 'If asked about Yomitasu, use this first.' It also states a when-not condition: registered site introduction pages can be searched, but their actual contents should be searched via that site's own MCP server. It does not mention when to prefer or avoid sibling tools like 'search_pages', so it is clear but 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 readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: it is a legacy implementation of `search` and that the return format differs from `search`. It does not specify the exact old return shape, but the deprecation context and format difference are meaningful disclosures beyond the 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?

Two compact Japanese sentences with no wasted words. The legacy status is front-loaded, the functional similarity to `search` is stated, and the recommendation to use `search` comes last as a natural conclusion.

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 legacy tool, the description covers selection well: it identifies itself as an alias, distinguishes the return format, and routes new callers to the preferred sibling. However, since there is no output schema and the return format is the tool's distinguishing trait, the description stops short of explaining what that old format actually looks like.

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 description adds no parameter-level meaning. Schema coverage is only 50%, and the description does not clarify what `limit` controls or how it interacts with results. The `query` parameter is documented in the schema with an example, but the description itself contributes nothing to parameter understanding.

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 clear verb and resource: it searches within the site (サイトの中を探します), just like `search`. It also differentiates itself from the sibling `search` by noting the return format is different, and marks itself as a legacy alias for previously connected users.

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 explicitly says this tool is kept for people already connected and instructs new usage to go to `search` instead: '新しく使うときは search を使ってください'. This is unambiguous when-to-use versus when-not-to-use guidance with a named alternative.

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 externally provided. The description adds useful context about what Yomitas is and how site registration works, but it does not disclose output format, rate limits, or other operational details. For a zero-parameter read-only tool this is acceptable, though not rich.

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 core function is front-loaded in the first sentence. The following sentences give helpful background about the service and a use case, though the site-owner registration detail is tangential to invoking the tool. Overall compact and readable.

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?

Given zero parameters and existing read-only annotations, the description covers purpose and usage sufficiently. Since there is no output schema, a more specific description of what the overview contains would close the only real gap, but for a simple info tool this is likely enough.

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 and 100% schema coverage (empty schema). The description correctly avoids inventing parameter details, so the baseline of 4 for parameter-free tools 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 opens with a specific verb and resource: '「ヨミタス」の概要を返します' (returns the overview of Yomitas). This clearly distinguishes the tool from siblings like get_page or list_pages, which target individual pages or lists.

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 final sentence 'どんなサービスかを最初に知りたいときに使います' gives an explicit use case: use when first learning about the service. However, it does not name alternatives or state when not to use it, so it misses a bit of full comparative guidance.

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