Skip to main content
Glama

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

サイトの中を探す(以前の名前)

search_pages
Read-only

「[MCP]アイレディース化粧品 - アイスター商事(基礎化粧品 / アルファエー / 健康食品 / 季節の食品)【公式】」(ai-star.co.jp)の以前の名前の機能です(すでにつないでいる人のために残しています)。search と同じようにサイトの中を探しますが、返す形が違います。新しく使うときは search を使ってください。

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYes探したい言葉(例: 料金 支払い方法)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources