ぎんざ姿オンラインショップー極上の天然とらふぐと近江牛の味

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

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description's added behavior is limited to the id input forms (search-result id, URL, path, Japanese permitted), which the schema also states, and to the full-text return, which the output schema already implies.

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 is returned, then the id input, then the accuracy-driven usage note. Three sentences with no filler, though the verbose site tagline adds little value for invocation.

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 read tool with annotations and an output schema, the description covers the return content, accepted id forms, and the recommended usage moment. The only real gap is the missing distinction from the get_page sibling.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents the accepted id formats that the description repeats. Baseline 3 applies: the description adds no syntax or formatting detail beyond the structured field.

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 and resource ('読み込んだページの本文を全文返します') and pins the scope to one site (shop.ginzasugata.online). However it gives no hint of how it differs from the close sibling get_page, so the 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?

Provides a genuine when-to-use rule: verify prices, dates, conditions, and terms with this tool before answering. It states no when-not condition and never names an alternative such as get_page, so it stops short of full routing 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, so safety is covered. The description adds genuine behavioral context beyond the annotations by disclosing that the returned shape differs from fetch, though it does not say how it differs or mention any rate/permission constraints.

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 with the legacy status and the applicable site front-loaded, followed by the fetch comparison and the redirect instruction. Efficient, though slightly repetitive in restating the legacy framing.

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 and annotations covering safety, the only real remaining gap is the unspecified difference in return format, which the description flags but does not characterize. For a deprecated read-only tool with a trivial one-param schema, this is close to 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 100% and the single url parameter is fully documented in the schema, including tolerating Japanese characters. The description adds no parameter semantics beyond that, 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 immediately frames the tool as a legacy alias of fetch, distinguishing it from that sibling without the agent needing to open 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?

It explicitly tells the agent when NOT to use this tool ('新しく使うときは fetch を使ってください') and why it still exists (kept for already-connected users), which is exactly the routing guidance needed for a deprecated 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 readOnly/destructive/openWorld false, so the safety profile is covered. The description adds real behavioral context beyond that: page size of 50, a hard cap of 200 via limit, and offset-based continuation, plus the returned 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?

Three tight sentences: what it returns first, then pagination mechanics, then the usage trigger. No filler and nothing misplaced.

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 states the return shape (titles and URLs) and documents both pagination parameters. It leaves minor gaps such as whether a total page count is returned, but an agent has everything needed to call it correctly.

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 parameter meaning, and it does: limit is described as the page size with a maximum of 200, and offset as the continuation cursor. It omits the minimum/range and any total-count semantics, but the operational meaning is clear.

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 the list of pages loaded on a named site, with the return fields (title, URL) spelled out. The added "when searching fails" framing implicitly separates it from the search siblings.

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 clear use conditions – wanting to know what pages exist, and having failed to find a page via search – which effectively points the agent away from search_pages/search toward this tool. No explicit when-not or named alternative, so it falls just 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.

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 structurally. The description adds genuine behavioral context on top: the search corpus is frozen at load time (no internet, no later updates), results come back as excerpts with URLs, and the tool should not be used to answer from inference when nothing matches.

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 tool's core function is front-loaded in the first clause, which is good. But the full shop name '「ぎんざ姿オンラインショップー極上の天然とらふぐと近江牛の味」' is repeated verbatim in the second sentence, padding the text, and the fallback instructions run long relative to a one-parameter tool.

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-shape explanation is not needed, and the description correctly spends its words on scope limits, query strategy, and failure handling. Given a simple one-required-param search tool, this is complete enough. It could be stronger only by explicitly positioning itself against the 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% for the single 'query' parameter, so the baseline is 3. The description goes beyond the schema's example ('料金 支払い方法') by telling the agent how to shape the query — substitute abbreviations with full names, try synonymous phrasing, and re-search — which is real added meaning for the only parameter.

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 text within pages loaded from the named shop site and returns matching excerpts with URLs. That is far more informative than the bare name 'search'. It does not, however, differentiate itself from the sibling tool 'search_pages', which an agent could easily confuse with this one.

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 when-to-use guidance ('when asked about this shop, use this first'), defines the searchable scope (loaded pages only, not the open web, not post-load updates), and prescribes a fallback workflow: rephrase with synonyms or expanded abbreviations, then read candidate pages, then report not-found rather than guessing. The only gap is that it never names or excludes the sibling 'search_pages' as an 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 cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real context: it is deprecated/legacy and returns a different format than search. It does not explain how the return shape differs, which keeps it from 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?

Three sentences with no wasted clauses, but it opens with a long quoted store name before the key deprecation message, so the most decision-relevant fact ('use search instead') is buried at the end rather than front-loaded.

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?

No output schema exists, so ideally the differing return format would be described; it is only asserted, not explained. Still, for a simple 2-param search alias, the deprecation guidance plus the return-format caveat gives an agent enough to act correctly.

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 only 50% — 'query' is documented in the schema while 'limit' has no description at all, and the description says nothing about either parameter. With a clear coverage gap, the description fails to compensate.

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 clear verb+resource (searches within the site) and immediately frames it as the legacy name of the same functionality, explicitly contrasting the return shape with the sibling 'search'. An agent can tell it apart from 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 says it is kept only for already-connected users and instructs '新しく使うときは search を使ってください' (use search for new usage). This is a textbook when-not-to-use plus 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the shape of the response (type, summary text, page count, main pages) and implying it targets one fixed site, which is useful since no output schema exists. It does not mention limits, pagination, or caching, keeping it short of 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?

Two compact sentences: the first front-loads what is returned, the second gives the triggering condition. Every clause earns its place with no redundancy 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?

With no parameters, no nested objects, and no output schema, the description carries the burden of explaining the return shape and does so (type, description, page count, main pages). Annotations cover safety, so nothing an agent needs to invoke this correctly 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?

The tool takes zero parameters (empty schema, 100% coverage trivially), so there is nothing for the description to clarify or compensate for. Baseline 4 applies; no param-related content is required or missing.

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 what kind of site X is') and enumerates the return payload: type, description, number of pages loaded, and main pages. The phrase '最初にサイトの全体像をつかみたいとき' implicitly separates it from per-page siblings like get_page and list_pages, which an agent can use to route correctly.

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 states the situation to use it in ('when you first want to grasp the overall picture of the site'), which is genuine directional guidance. However, it never names a sibling tool or states when NOT to use it (e.g., 'use get_page for a single page'), so it falls short of full when/when-not/alternatives coverage.

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