Smart省エネ AI【公式】

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 that the tool returns the entire page body and is restricted to one domain (openWorldHint=false is consistent). It says nothing about behavior on off-site URLs, very long pages, or fetch failures, which keeps 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?

Three short sentences, front-loaded with what is returned, then the parameter, then the accuracy-critical usage rule. Nothing is wasted and the ordering matches how an agent needs the information.

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 domain scope, accepted id forms, and the key use case. The one remaining gap is that an agent cannot tell from this definition how fetch differs from get_page.

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%, so the schema already documents that id accepts a search-result id, a URL, or a path, including Japanese characters. The description repeats that same range of accepted values rather than adding format constraints or normalization details, 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: returns the full body text of a loaded page on the named site (smart-shouene-ai.com). The site scoping is precise, but it does not distinguish itself from the sibling get_page, which on the surface sounds like the same operation.

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 a clear usage context: for pricing, dates, conditions and terms where accuracy matters, verify the body text before answering, and take the id from search results. It does not say when to prefer a sibling such as search or get_page, so no explicit alternatives/exclusions 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 cover safety (readOnly, non-destructive, closed-world), and the description adds genuinely new behavioral context: this is a deprecated alias retained for backward compatibility, and its response shape diverges from fetch. The one gap is that it never says how the format differs, which matters somewhat since no output schema exists.

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, each carrying distinct information: identity/deprecation, behavior and difference, and the recommended alternative. Minor weakness is that the deprecation framing precedes the statement of what the tool actually does.

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, annotated, deprecated read tool, the description supplies everything needed to make the correct decision (deprecated; use fetch instead). The only missing piece is the concrete shape of the returned body, which the absent output schema leaves undocumented.

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?

Single parameter with 100% schema description coverage, so the schema fully documents 'url' including that Japanese paths are acceptable. The description adds nothing about the parameter, which is the expected baseline given complete schema 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 states the concrete behavior ('ページの本文を返します') and immediately contrasts it with the sibling fetch ('fetch と同じように…が、返す形が違います'). The legacy framing ('以前の名前の機能') is a bit roundabout as an opening, but the agent still learns exactly what the tool returns and how it differs from the alternative.

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-not ('新しく使うときは fetch を使ってください') and names the exact alternative, plus explains the only legitimate use case ('すでにつないでいる人のために残しています'). No inference is required to route away from this tool.

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), so the description's job is to add operational context — and it does: paging behavior (50 per call, limit up to 200, offset for continuation) and the shape of the returned items (title + URL). It does not discuss total counts or ordering, but that is a minor gap for a simple read tool.

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 what the tool returns, then paging mechanics, then use cases. Nothing is redundant or padding.

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 two-parameter read-only listing tool with no output schema, the description covers the source site, the returned fields, pagination limits and the retrieval pattern needed to call it correctly. What an agent needs to invoke it is present.

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 compensate, and it does: it explains that 50 is the per-call page size, that limit can go up to 200, and that offset is used to fetch the continuation. The wording is not fully explicit about offset's unit (items vs pages), which is the only ambiguity.

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 (list / 一覧を返す) and resource (pages loaded on smart-shouene-ai.com), and specifies what is returned (title and URL). It implicitly distinguishes itself from the search sibling by framing itself as the enumeration/fallback path, so an agent can tell it apart from search_pages 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?

It gives two concrete use conditions: wanting to know what pages exist, and falling back when a search fails to find something. That is clear when-to-use guidance with an implied alternative. It does not name the sibling tool (search_pages) explicitly or state when-not-to-use, which keeps it just below 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 cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real behavioral context beyond them: the corpus is limited to already-crawled pages, post-crawl site updates are excluded, results come back as excerpts with URLs, and misses return candidate pages. It doesn't mention result limits or ranking 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?

Front-loaded with what it searches and where the corpus comes from, then the usage trigger, then the retry/fallback ladder. Slightly long for a one-parameter tool, but every sentence contributes a distinct instruction.

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 search with an output schema and full annotation coverage, the description supplies everything an agent needs: corpus scope, invocation trigger, query-reformulation guidance, and correct failure behavior.

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 already gives an example query, so the baseline is 3. The description goes further by explaining how to shape the query string — expand abbreviations to formal names, substitute synonymous terms — which is actionable semantics the schema does not carry.

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 smart-shouene-ai.com), and bounds the scope explicitly ('探せるのは読み込んだページだけ'). It does not, however, distinguish itself from the sibling tool `search_pages`, leaving an agent to guess which search to call.

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 a clear trigger ('Smart省エネ AI【公式】 について質問されたら、まずこれを使ってください') plus a concrete retry strategy (rephrase with full names or synonyms) and a fallback path (read candidate pages, then report not-found rather than guess). No explicit when-not or comparison against `search_pages`/`fetch`.

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 needs no restating. The description adds useful context that this is legacy and returns a different format than `search`, but it does not explain what that format is, nor any limits or caveats 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?

Three short sentences, with the legacy status front-loaded so the agent hits the most decision-relevant fact first. The parenthetical aside about retaining it for existing connections is slightly redundant with the later instruction to use `search`, but nothing is padded.

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 two-parameter read tool with annotations covering safety, the main decision (use `search` instead) is fully covered. The gap is that the differing return shape is asserted but never described, and there is no output schema to fill that in, so an agent choosing this tool cannot know what it will receive.

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 says nothing about either parameter. The schema documents `query` but leaves `limit` (default 5, max 20) undescribed, so at 50% coverage the description should compensate for the gap and does not.

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 ('サイトの中を探す' - search within the site) and explicitly distinguishes this tool from the sibling `search` by stating the return shape differs. The only remaining ambiguity is that it never says what the different return shape actually looks like, so an agent knows the category but not the output.

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-not-to-use ('新しく使うときは search を使ってください' - use search for new usage) and a when-to-use ('すでにつないでいる人のために残しています' - kept for those already connected). The alternative sibling is named along with the condition that selects it, leaving 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 fully covered. The description adds value by enumerating the returned fields (種類・紹介文・読み込んだページ数・主なページ), which is genuinely useful for a zero-param tool. However, roughly half the text is product marketing (JW_CAD, BIM, 2025 省エネ基準) that says nothing about the tool's 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?

The purpose and usage conditions are correctly front-loaded in the first two sentences. But the trailing block of promotional copy about CAD/BIM/省エネ基準 adds no decision-relevant information for an agent and dilutes the signal.

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 zero-parameter, read-only summary tool with full annotation coverage and no output schema, the description supplies the returned field names and the point at which to call it. Nothing essential to correct invocation is missing; only the wasted marketing text keeps it from a 5.

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 no parameters and the schema is empty, so there is nothing for the description to disambiguate; the baseline for zero-param tools is 4. The description does not introduce any spurious parameter concepts.

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 states a specific resource and a concrete return payload (site type, description, page count, main pages) tied to the named domain smart-shouene-ai.com. It is clearly distinguishable from get_page/list_pages because it returns an aggregate summary rather than a page or a list. It stops short of naming a sibling, so it lands just below 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?

「最初にサイトの全体像をつかみたいときに使います」 gives a clear selection condition (do this first when you want the big picture), implicitly ordering it ahead of the detail-oriented siblings. No explicit exclusions or named alternatives are provided, which keeps it at 4 rather than 5.

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