Skip to main content
Glama

いざ貸す

どんなページがあるか見る

list_pages
Read-only

「いざ貸す」(izakasu.jp)の読み込み済みページを、タイトルとURLの一覧で返します。持ち家を貸す方法、転勤・海外赴任、相続した実家・空き家の活用、賃貸管理会社選び、賃貸オーナーの悩みについて、どんな記事や案内があるか把握したいときに使ってください。検索で情報が見つからなかった場合にも、関連するページの候補を確認できます。一度に50件、limitで最大200件を取得でき、続きはoffsetで指定します。

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo

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=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the behavior annotations cannot express: it returns titles plus URLs, pages in batches of 50, and continuation via offset. It doesn't state ordering or whether the set is exhaustive, which keeps it from 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the return shape before the usage scenarios and then pagination. The middle sentence enumerates five topics, which is somewhat long, but each clause serves to describe coverage of the target site.

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?

With no output schema, the description correctly specifies the return shape (title + URL list) and the pagination contract, which is what an agent needs to call and page through it. Nothing critical is missing for a two-parameter read-only enumerator.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description has to carry both parameters, and it does: limit is documented with its default 50 and ceiling of 200, and offset is documented as the continuation cursor. Meaning is added beyond the bare integer types, though no units/edge behavior beyond the stated bounds.

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 concrete verb and resource: it returns the izakasu.jp loaded pages as a list of titles and URLs. It implicitly separates itself from the search siblings by framing itself as a catalogue/overview of 'what pages exist' rather than a query, but it never names a specific sibling to contrast against.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives two clear when-to-use conditions: when the agent wants to survey what articles/guides exist on the covered topics, and as a fallback when search returns nothing useful. That second clause effectively routes away from the search tools. No explicit when-not-to-use or named alternative tool, though.

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