［MCP］アイレディース化粧品 - アイスター商事（基礎化粧品 / アルファエー / 健康食品 / 季節の食品）【公式】

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context: it returns the full body text and the corpus retains past-year pages, so results may include outdated or discontinued content. It does not describe pagination or truncation behavior for long pages.

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 is front-loaded and the follow-on sentences are all relevant to correct invocation. It is somewhat long and several sentences read as answer-behavior policy rather than tool semantics, which slightly dilutes focus but does not waste space.

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, return-value explanation is unnecessary, and the single parameter plus rich usage rules fully equip an agent to call it correctly. Nothing essential 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?

Schema coverage is 100% and the single `id` parameter is already documented in the schema. The description restates it (search result id = page URL, or URL/path) with no syntax or format detail beyond what the schema provides, so 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?

State a specific verb+resource: it returns the full body text of an already-loaded page on ai-star.co.jp, and explicitly contrasts full text with search's excerpts. However, it does not distinguish itself from the sibling get_page, leaving ambiguity about which of the two to pick for a single page read.

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?

Explicit about when to use it (accuracy-critical facts: prices, shipping, application periods, ingredients, allergens, company info) and when not to rely on excerpts from search. It also adds domain rules for handling past-year pages, sold-out/discontinued markers, and cosmetic/beverage claims, which is far beyond typical 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 the safety profile is covered. The description adds the meaningful context that this is a deprecated alias whose return shape differs from fetch, but it never explains how the format differs or what is returned. Adequate but leaves a real behavioral gap.

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 that carry the key routing message, but the first sentence is dominated by a long parenthetical corporate/site name that reads as noise rather than information. The practical content is front-loaded reasonably, but the opening is not tightly structured.

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-risk legacy read alias with no output schema and full schema coverage, the description gives what an agent needs: it is deprecated, it mirrors fetch, and fetch should be preferred. The one omission is a concrete explanation of how the differing return format looks, which matters for callers depending on it.

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 documented in the schema (URL or path, Japanese allowed). The description adds no parameter syntax beyond that, so the baseline of 3 is correct when the schema does the heavy lifting.

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?

Despite a confusingly embedded site name in the opening quote, the description states clearly that this returns a page body like fetch but in a different form. It distinguishes itself from the sibling fetch by noting the format difference. The core verb+resource is identifiable, though the wrapped corporate title adds noise.

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 routes the agent: this is the legacy name kept only for those already connected, and 'when using newly, use fetch.' Both the when-to-use (backward compatibility) and the preferred alternative (fetch) are named directly, 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 establish read-only, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real behavioral value beyond that: pagination mechanics (50 per page, limit 200, offset continuation) and the caveat that multiple year-variants of the same product may appear, with guidance to pick the latest. It does not state ordering/sort behavior, which is the remaining gap.

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 purpose, then pagination, then usage context. Dense but every clause carries information (paths, pagination, year-selection caveat); the long enumeration of section paths makes it heavier than strictly necessary.

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?

There is no output schema, but the description names the returned fields (title and URL), covers pagination, and warns about duplicate year variants. Combined with the annotations, an agent has enough to call this correctly, with only sort order unspecified.

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: it explains the 50-item default page size, the 200 maximum for limit, and that offset retrieves the continuation. That compensates well for undocumented schema properties, though it does not explicitly tie names to each 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 ('ai-star.co.jpの読み込み済みページの一覧を、タイトルとURLで返します') and names exactly what is returned. It also separates itself from the search siblings by framing itself as the fallback when searching fails.

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 an explicit trigger condition ('searchで見つからないとき') plus a positive use case (surveying what pages exist), and enumerates concrete section paths to look under. The alternative tool (search) is named rather than 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 and openWorldHint=false. The description goes further by disclosing that only pre-loaded pages are searchable and that post-load updates and the wider internet are excluded, which reinforces the openWorld=false semantic. It does not describe pagination or result limits, but the annotated baseline keeps the bar low.

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 is front-loaded in the first sentence, followed by usage rules and fallback behavior in a logical order. The synonym list is somewhat long but each entry is functionally useful, with little 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 values need no explanation. Combined with the rich usage and fallback guidance plus the explicit scope limitation, an agent has everything needed to invoke and interpret this tool 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 100% for the single query parameter, so the baseline is 3. The description adds genuine value beyond the schema by enumerating effective query synonyms and query-shaping strategies, which meaningfully informs how to construct the query.

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 (loaded pages of ai-star.co.jp), and lists the content domains it covers (company, products, seasonal items, FAQ, recruiting). However, it never differentiates itself from the near-identical sibling search_pages, so an agent cannot disambiguate the two 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?

Explicitly instructs the agent to use this tool before answering from its own knowledge for a concrete set of topics, provides rephrasing fallbacks with synonym examples (おせち→なごやかセット白鳥), and defines the terminal fallback behavior (read candidate pages, do not speculate, report 'not found'). This is unusually complete 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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds a genuinely useful behavioral trait beyond the annotations: the return format differs from `search`. It does not cover pagination or response shape details, but the key behavioral difference is disclosed.

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 message (legacy alias of search with a different return shape, use search instead) is front-loaded and useful. However the long full site title and the redundant restatement of the connection rationale pad the text without adding information an agent needs.

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-only search wrapper with no output schema, the description supplies purpose, the difference from its successor, and explicit usage routing. The main residual gap is that the 'different return format' is left unspecified, which slightly limits an agent relying on it.

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%: `query` has a description and example, while `limit` has numeric bounds (default 5, min 1, max 20) but no textual meaning. The description adds no parameter information at all, so it neither compensates for the gap nor adds value beyond the schema; baseline 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 this is the former-name version of the site search and that it 'searches inside the site like search,' giving a clear verb+resource. It distinguishes itself from the sibling `search` by naming it directly. It never says explicitly that it searches pages, but the intent is unambiguous.

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 it and what to use instead: use `search` for new usage, this is retained only for already-connected clients. That is a textbook when/when-not/alternative statement.

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 establish readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context: warning not to conflate Ai-star group companies, to answer sales-method questions strictly from the site's own compliance statements, and to escalate individual order/skin/health inquiries to the contact form rather than guessing.

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 sentence front-loads the return contents well, which is good structure. However, a substantial portion of the text concerns domain answering policy (company-name confusion, visiting-sales compliance, escalation) rather than the tool's own mechanics, making it longer than a tool definition needs to be.

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 and no output schema, the description carries the burden of explaining the return payload and does so by enumerating the overview fields. It also supplies the missing escalation target URL, leaving little an agent needs that is absent.

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 per the rubric the baseline is 4. The description correctly implies a parameterless, whole-site call and adds no conflicting parameter expectations.

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: it returns an overview of ai-star.co.jp (type, description text, number of pages loaded, main pages). The scope is precise enough to distinguish it from fetch/get_page/list_pages, though it never names a sibling tool explicitly.

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 triggering condition. It does not, however, say when NOT to use it or point to a specific alternative (search_pages, list_pages) for narrower needs, so there is no explicit routing.

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