Skip to main content
Glama

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

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

search_pages
Read-only

「セキュリティIoTソリューション」(securityiot.theshop.jp)の以前の名前の機能です(すでにつないでいる人のために残しています)。search と同じようにサイトの中を探しますが、返す形が違います。新しく使うときは search を使ってください。

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources