セキュリティIoTソリューション

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 safe-read profile is covered by structured data. The description adds that it returns the full body text and accepts a URL, path, or Japanese string, which is modest extra context, but says nothing about idempotency, rate limits, or failure modes when an id is wrong.

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 first two sentences are well front-loaded and actionable, but the bulk of the description is a long marketing blurb describing what the Security IoT Solution product line is. That content is pure site boilerplate and does nothing to help an agent call the tool, which is a severe conciseness failure.

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, annotations covering the safety profile, and a single fully documented parameter, the description only needs to explain what it does and when to use it. It covers the what and gives a use cue, but leaves the fetch-vs-get_page distinction unresolved and pads the rest with irrelevant product copy.

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 'id' parameter, and the description largely restates it: id is the search-result id (the page URL), and a URL or path also works. It adds no format or syntax guidance beyond the schema, 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 opening sentence states a specific verb and resource: it returns the full body text of a page on securityiot.theshop.jp, and clarifies that the input is an id/URL/path. However, it never distinguishes itself from the sibling tool 'get_page', which on its name alone appears to do the same thing, so an agent cannot disambiguate the two without opening both 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?

It gives a genuine usage directive: verify prices, dates, conditions and terms with this tool before answering accuracy-critical questions, and it implies a search-then-fetch workflow by referencing the id from search results. But it says nothing about when to prefer 'get_page' or any other sibling, and gives no exclusions, so tool selection is left partly 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the tool is a deprecated alias and that its return format differs from fetch. It stops short of describing what that format actually is.

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 most decision-relevant fact (legacy name, kept for existing users) and closes with the routing advice. Four compact sentences with no filler, though the wording is slightly repetitive about fetch.

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 a full annotation set this is largely adequate, and the deprecation routing is clear. However there is no output schema, and the description says the return shape differs from fetch without explaining how — the one piece of information an agent cannot get elsewhere 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?

There is a single url parameter with 100% schema description coverage, including the useful note that Japanese paths are acceptable. The description adds nothing about the parameter, so the baseline 3 applies — the schema carries the burden here.

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 (returns the page body, like fetch but in a different shape) and explicitly frames itself as the legacy name of an existing function. It clearly distinguishes itself from the sibling fetch, so an agent can pick between the two 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 that new usage should go to fetch instead — a named alternative plus the condition that selects it. This is exactly the when/when-not guidance the dimension asks for.

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, so the safety profile is covered. The description adds real behavioral detail beyond them: pagination at 50 per page, a hard cap of 200, and offset-based continuation.

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 compact sentences, front-loading what is returned before how paging works, then the usage cue. No filler, though the paging details could be compressed slightly.

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 the return-shape burden and does name the fields (title and URL). Combined with paging behavior and usage context, an agent has enough to call the tool correctly; a note on total counts or ordering would make it 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 coverage is 0%, and the description compensates by explaining both parameters: limit controls page size up to 200 and offset retrieves subsequent batches. The paging semantics (batch size, continuation) are conveyed even though the schema only carries types and bounds.

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 for the named site), and specifies the returned fields (title and URL). It does not, however, differentiate itself from sibling search_pages / get_page, so an agent must 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 clear usage context: use when you want to know what pages exist, or when searching fails to find something. It does not name a specific alternative tool to route against, so it stops short of full when/when-not 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, openWorldHint=false and destructiveHint=false. The description adds real value beyond that: it discloses the corpus boundary (only loaded pages, no live updates) and prescribes non-guessing behavior on failure. It does not discuss auth, rate limits, or result limits.

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?

Purpose and scope are front-loaded and each sentence carries distinct information (scope, usage, fallback, failure handling). It is a dense single paragraph rather than a tight list, so it is on the verbose side but not wasteful.

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 restated. Combined with the safety annotations, the description covers what an agent needs: what corpus is searched, when to invoke, and how to behave when results are empty. Only the relationship to search_pages is left unexplained.

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 further by advising on query formulation — switching abbreviations to formal names or trying synonyms — which is meaningfully beyond the schema's terse example ('料金 支払い方法').

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 a bounded resource (pages loaded from securityiot.theshop.jp), with the return shape (excerpts + URLs) made explicit. It does not differentiate itself from the sibling search_pages, which appears to be a near-equivalent, so an agent cannot route between them from this text 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?

Gives clear when-to-use (use this first when asked about the site), when-not (only loaded pages, not the open web, not post-load updates), and a concrete fallback procedure (rephrase, then read returned page candidates, then admit failure rather than guess). No alternative tool is named, so tool-selection guidance is incomplete, but the contextual guidance is strong.

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 (readOnlyHint, destructiveHint false, openWorld false), so the description's job is to add context beyond that — and it does, disclosing that the tool is deprecated and returns output shaped differently from `search`. It stops short of saying how the format differs or noting pagination/limit behavior, which keeps it out of 5 territory.

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 before the guidance, and no filler. The parenthetical domain reference is necessary context rather than waste, though the phrasing could be tightened slightly.

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 a two-parameter, read-only search tool with annotations but no output schema, the description covers the deprecation and the alternative adequately. The notable gap is the unexplained 'different format' — with no output schema to fall back on, an agent cannot tell what this tool actually returns versus `search`.

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 only 50%: `query` carries meaning in the schema, but `limit` has no description (only default/min/max constraints). The description adds nothing about either parameter — the 'different format' remark concerns output, not inputs — so it 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 specific verb+resource (searches inside the site) and explicitly frames it as the legacy/renamed counterpart of the `search` sibling, so an agent can place it immediately. The only weakness is that 'returns a different format' never specifies what that format is, so the practical difference from `search` is left fuzzy.

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: this is retained only for users already connected to it, and 'for new usage, use search.' Both the when (backward compatibility only) and the named alternative are stated outright, leaving nothing 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 that the tool is bound to one specific site and what fields it returns, but says nothing about auth, rate limits, or freshness of the overview, so it only modestly exceeds 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?

The first paragraph is front-loaded and useful, but the entire second paragraph is marketing copy about the site's camera/IoT products that does nothing to help an agent select or invoke the tool. Roughly half the description is filler that does not earn 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 input parameters, no output schema, and annotations covering the safety profile, the description supplies the key missing context: which site it targets and what information it returns. It is essentially complete for such a simple read tool.

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 nothing for the description to disambiguate; the baseline for a 0-param tool is 4. The description correctly gives no parameter guidance because none is needed.

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 first sentence gives a specific verb+resource: it returns an overview of the site, and it enumerates exactly what comes back (type, intro text, page count, main pages). The purpose is clear, but it never distinguishes itself from siblings like get_page or list_pages, so an agent must 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?

It explicitly states when to use it: '最初にサイトの全体像をつかみたいときに使います' (use when you first want to grasp the whole picture), which implies an ordering relative to the other site tools. There are no explicit exclusions or named alternatives, so it falls 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.