全国企業データベース-プレスリリース配信サービス

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

Annotations already establish the safety profile (readOnly, non-destructive, closed-world), which lowers the bar. The description adds that it returns the FULL body text rather than a snippet and that it is the authoritative source for accuracy-critical facts, but it says nothing about failure on a bad id, truncation, or pagination.

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 site + purpose and then id usage and the verification trigger; each sentence carries information. Slightly more compact than ideal but no 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?

For a low-complexity read-only tool with an output schema (so return shape need not be described) and full param coverage, the description covers purpose, required input, and the moment to use it. The unresolved overlap with the get_page sibling is the main remaining 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?

With a single parameter at 100% schema coverage, the schema already documents the id semantics (search-result id, URL or path, Japanese acceptable). The description restates the same 'URL or path' guidance without adding format or validation detail beyond the schema, 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 names a specific verb and resource ('returns the full body text of a loaded page') and even pins the target site (companydata.tsujigawa.com), so the agent knows exactly what it does. However it never differentiates itself from the near-duplicate sibling get_page, so it stops short of a 5.

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 use condition: verify the body text with this before answering questions where accuracy matters (prices, dates, conditions, terms), and it links to the search flow ('pass the id from the search results'). It offers clear context but no explicit exclusions or named alternatives.

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 shape differs from fetch and that this is a legacy endpoint, which is useful context, but it does not say how the shape differs or disclose any other behavioral traits.

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 the legacy status and the key differentiation from fetch in compact sentences, with no filler. Slightly verbose in restating the service identity, but every clause carries relevant context.

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 legacy read tool with no output schema, the description warns that the return shape differs from fetch but never explains how, leaving a real gap for an agent deciding whether the output is usable. It is otherwise adequate given the covered annotations.

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 a single required parameter, so the schema already documents the url field (including that Japanese is acceptable). The description adds nothing about the parameter, which is the expected baseline when the schema does the work.

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 action (returns page body) and resource (page) and explicitly distinguishes itself from the sibling fetch by noting the return shape differs. The legacy framing ('previous name feature, kept for those already connected') is clear, though the exact purpose beyond mimicking fetch is somewhat implicit.

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 the alternative (fetch) and the condition that selects it ('use fetch for new use'), and explains why this tool still exists for backward compatibility. An agent knows precisely when to pick this vs the sibling.

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, non-open-world). The description adds real behavioral context beyond them: batch size of 50, a maximum of 200 via limit, and offset-based continuation. Return content (titles and URLs) is also disclosed, though rate limits or ordering guarantees are unstated.

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 well-formed sentences, front-loaded with the resource and return fields, then pagination, then usage. No filler, though the service URL and full product name add length that could be trimmed.

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 2-param, no-required, no-output-schema tool, the description covers return shape, pagination mechanics, and usage intent adequately. Minor gaps (result ordering, total count behavior) remain but are not essential to correct invocation.

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 must carry parameter meaning. It does: limit default/max (50/200) and offset for pagination are explained in prose, compensating for the bare schema. It doesn't explicitly note offset units or ordering, so not a 5.

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 a list of loaded pages with title and URL) within a named service context. It implicitly distinguishes itself from search-type siblings by framing this as the enumeration fallback, so an agent can tell it apart from search_pages/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?

Explicitly says when to use it: to see what pages exist, or when a search fails to find something. This routes the agent away from search tools in the failure case. It does not state exclusions or name a specific alternative tool, keeping it 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, and the description is consistent with all three. It adds genuinely useful context beyond the annotations: the index covers only pages already loaded and misses post-loading updates, which tells the agent results can be stale. Rate limits and result caps are not mentioned, so it is not a full 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?

Front-loads what the tool does and where it searches, then moves to when to use it, then to failure handling. Every sentence carries information, and the empty-result protocol is worth its length. It is slightly dense in one paragraph but has no 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?

An output schema exists, so return-value detail is unnecessary, and the description still summarizes the response (excerpts plus URLs). Annotations carry the safety profile and the description covers index scope and failure handling. The one gap is that sibling disambiguation against search_pages is never addressed.

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?

Only one parameter (query) and schema description coverage is 100%, with the schema itself supplying an example query. The description adds behavioral advice about reformulating queries but no syntax, format, or length guidance beyond what the schema already provides. 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 (search) and resource (pages loaded from companydata.tsujigawa.com), plus the return shape (matching excerpts with URLs). Scope is precise about the corpus and explicitly excludes the open web. It does not, however, differentiate itself from the sibling search_pages, which an agent could easily confuse it with.

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 ("if asked about this site, use this first") and a concrete fallback protocol: rephrase the query with full names or synonyms, and if still empty, tell the user the site does not cover it rather than guessing. It stops short of naming alternatives like search_pages or fetch, so the sibling choice is left to inference.

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 the safety profile is covered. The description adds legacy/deprecation status and that the return format differs from `search`, which is useful non-obvious context. It does not detail the actual return shape, but with annotations this is sufficient for a 4.

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 concise sentences: identifies legacy status, explains similarity to `search` and the return shape difference, then gives routing advice. Front-loaded with what it is, though the full service name adds some verbosity.

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 deprecated search tool with no output schema, the description gives enough context: legacy status, alternative, and return format difference. However, it leaves the actual return shape unexplained, which could matter for existing users.

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 50%: the `query` parameter has a description in the schema, but `limit` has only type/default/min/max with no description. The tool description provides no additional parameter semantics or guidance, so it fails to compensate for the undocumented `limit` 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?

States a specific verb and resource: searching within the site (サイトの中を探す), and explicitly identifies itself as the legacy name of a feature on the named service. It distinguishes from the sibling `search` by noting the return shape differs, so an agent can tell them apart without opening 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?

Explicitly states when to use this tool (for those already connected) and when not to (new use should use `search`), naming the alternative directly. The deprecation routing is unambiguous with no inference required.

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 the safety profile is covered. The description adds the specific payload contents (type, intro, page count, main pages), which is somewhat useful, but nothing about auth, limits, or behavior 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 tight sentences: the first identifies the target and payload, the second gives the trigger condition. No redundancy and the content is 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?

With no parameters, no output schema, and annotations covering safety, the description fills the remaining gap by listing what is returned. It is nearly complete for a simple overview tool, missing only explicit sibling routing.

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 there is no parameter semantics for the description to supply. Per the rubric, a 0-parameter tool gets a baseline of 4.

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 concrete verb and resource and enumerates exactly what the tool returns: site type, intro text, page count, and main pages. This clearly sets it apart from fetch/get_page/search, though it does not explicitly contrast with the adjacent list_pages, whose 'main pages' overlap could confuse an agent.

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 states a clear condition for use — 'use when you first want to grasp the overall picture of the site' — which is a sensible entry-point instruction. It does not, however, name any alternative tool or state when NOT to use it versus list_pages or search.

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