いざ貸すは、持ち家を貸したい方や、所有物件の賃貸管理を見直したい方のための賃貸管理一括査定サービスです。（izakasu.jp の内容を検索して答える。ヨミタス経由）
Scored across 6 tools
There are two clear duplicate pairs: fetch duplicates get_page, and search duplicates search_pages, with the deprecated variants kept for existing users. The descriptions do explicitly say the old ones are legacy and to use the new ones, which mitigates but does not eliminate the overlap. An agent could still misselect between these near-identical tools.
Names mix bare verbs (fetch, search), verb_noun forms (get_page, list_pages, search_pages), and a noun_noun form (site_overview). It remains readable and partly follows a verb_noun pattern, but conventions are not applied uniformly across the set.
Six tools is a reasonable scope for reading a website's content (overview, list, search, fetch). However, two of them are deprecated duplicates, so the effective surface is four tools, making the count slightly inflated rather than egregious.
For a read-only site-content server, the surface covers discovery (search, list_pages, site_overview) and retrieval (fetch) with pagination via limit/offset. No obvious CRUD gap exists since writing is not part of this domain, though there is no explicit tool for following related links or fetching multiple pages in one call.
「いざ貸す」（izakasu.jp）の読み込み済みページの本文を全文返します。検索で見つけた持ち家の貸し方、転勤・相続・空き家の活用、管理会社選びの記事や、無料査定サービスの案内を詳しく確認するときに使ってください。特に料金、対象物件、利用条件、手順、契約上の注意点、日付は、回答前に本文を確認してください。idには検索結果のid（ページのURL）、ページのURLまたはパスを渡します。読み込み後の更新は含みません。
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 探した結果の id（ページの URL）。ページの URL かパスでも可（日本語のままでも可） |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds a genuinely useful behavioral caveat beyond them: it does not include updates made after the page was loaded (読み込み後の更新は含みません). It does not mention truncation/pagination limits for very 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 in the first sentence, followed by usage and a caution, with no filler or repetition. Slightly prose-heavy for a one-parameter tool, but every sentence carries distinct 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 no explanation, and the description covers the remaining agent-critical gaps: what it returns, the precondition that the page is loaded, the freshness caveat, and which facts to verify before answering. Nothing needed to invoke it correctly 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 description coverage is 100%, so the single id parameter is already documented as accepting a search-result id, a URL, or a path, including Japanese characters. The description restates this almost verbatim and adds only that the id originates from search results, 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?
States a specific verb and resource: it returns the full body text of an already-loaded page on izakasu.jp, with concrete content types (持ち家の貸し方, 相続, 管理会社選び, 査定案内). The 'already-loaded page' scoping meaningfully separates it from the search siblings, though it never names which sibling to use instead (e.g. get_page).
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 when-to-use: after finding an article via search, when you need to verify details such as fees, eligible properties, conditions, procedures, contract caveats and dates before answering. It gives no explicit when-not-to-use or named alternative, but the trigger condition is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「いざ貸す」（izakasu.jp）の以前の名前の機能です（すでにつないでいる人のために残しています）。fetch と同じようにページの本文を返しますが、返す形が違います。新しく使うときは fetch を使ってください。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ページの URL かパス（日本語のままでも可） |
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 genuinely non-derivable context: it is a deprecated alias retained for backward compatibility and, importantly, its return format differs from fetch — a behavioral trait the agent would otherwise not know. It stops short of saying how the format differs, keeping 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler, and the critical fact (this is the legacy name, use fetch instead) is front-loaded. Slightly roundabout phrasing around the 'izakasu.jp' aside, but it earns its words.
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-param read tool with full schema coverage and annotations, the description covers deprecation status, the sibling alternative, and the divergent return format. The one remaining gap — what exactly the different return shape is — is minor but real given there is no output schema.
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?
Only one parameter at 100% schema coverage, so the schema already documents the url/path and its Japanese-language tolerance. The description adds no syntax, format, or constraint information beyond what the schema provides, making the baseline 3 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?
States a specific verb+resource (returns a page's body, like fetch) and distinguishes itself from the sibling fetch by noting it is the legacy name and returns a different shape. The framing is deprecation-first rather than purpose-first, which muddies it slightly, but an agent can still tell what it does and how it differs from fetch.
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 routes the agent: it exists for those already connected, and '新しく使うときは fetch を使ってください' names the alternative and the condition that selects it. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「いざ貸す」（izakasu.jp）の読み込み済みページを、タイトルとURLの一覧で返します。持ち家を貸す方法、転勤・海外赴任、相続した実家・空き家の活用、賃貸管理会社選び、賃貸オーナーの悩みについて、どんな記事や案内があるか把握したいときに使ってください。検索で情報が見つからなかった場合にも、関連するページの候補を確認できます。一度に50件、limitで最大200件を取得でき、続きはoffsetで指定します。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
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.
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.
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.
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.
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.
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.
「いざ貸す」（izakasu.jp）の読み込み済みの公式サイト・メディアから、質問に関連するページを検索し、抜粋とURLを返します。持ち家・自宅・マンション・戸建てを貸す方法、家賃の調べ方、転勤・海外赴任時の持ち家、相続した実家・空き家の活用、賃貸管理会社の比較・変更、管理費・空室の悩みを調べるときに使ってください。売るか貸すか迷っている場合も、賃貸を検討するための情報を探せます。サービス名が含まれない質問でも、これらのテーマに関する公式情報を探す場合に使えます。賃貸の手順・費用・住宅ローン・契約の注意点や、無料査定の利用案内を探せます。検索対象は読み込み済みのページのみです。見つからない場合は言い換えて探し直し、確認できない情報は推測せず伝えてください。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 探したい言葉（例: 料金 支払い方法） |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| candidates | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description adds real context beyond them: the search corpus is limited to pre-loaded pages, it returns excerpts plus URLs, and if nothing is found the agent should rephrase and must not guess. That is a meaningful behavioral constraint layered on top of 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?
The purpose and constraints are front-loaded, which is good, but the long enumeration of use-case themes becomes repetitive and padded. Several sentences restate the same idea (search official info on these topics) without adding new information, so not every sentence earns its place.
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 documented, and the description still usefully mentions excerpts and URLs. It covers scope, failure handling, and topic coverage. It is only incomplete regarding result limits/pagination and its relationship to the near-identical `search_pages` sibling.
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?
With one parameter and 100% schema description coverage, the schema already explains the `query` field and its example. The description adds thematic context for what to search but no syntax, format, or phrasing guidance beyond the schema. 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 (読み込み済みの公式サイト・メディアのページ), and notes the return shape (抜粋とURL). However, it never distinguishes itself from the sibling `search_pages`, which appears to be a near-identical search tool, so the agent cannot tell the two apart 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?
Provides a rich set of when-to-use scenarios (持ち家・自宅を貸す方法, 家賃の調べ方, 相続した実家の活用, 管理会社の比較 etc.) and even clarifies that service-name-free questions still qualify. It stops short of naming alternatives or stating when NOT to use it versus `search_pages`/`site_overview`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「いざ貸す」（izakasu.jp）の以前の名前の機能です（すでにつないでいる人のために残しています）。search と同じようにサイトの中を探しますが、返す形が違います。新しく使うときは search を使ってください。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | 探したい言葉（例: 料金 支払い方法） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely useful non-obvious context: this is a stale backward-compatibility alias whose return shape differs from `search` — though it stops short of describing what that shape is.
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 tight sentences with the deprecation status front-loaded, which is the most decision-relevant fact. No filler, though the phrasing is somewhat circuitous about what the tool itself returns.
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, yet the description's key claim — the return format differs from `search` — is left unexplained, which is the one thing an agent would need to use this tool correctly. The steering to `search` mitigates the risk, but the completeness gap remains.
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 50%: `query` has an example and `limit` has full structural constraints (default 5, min 1, max 20) even without prose. The description adds nothing about parameters, but the schema largely carries the load, making the silence a minor gap.
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 verb+resource ('search the site like search does') and explicitly marks it as the legacy former-name feature, which separates it from the sibling `search`. It is clear, though its self-description leans on comparing itself to `search` rather than fully describing its own resource scope.
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 states the alternative and the condition that selects it: 'When using it newly, please use search' and 'kept for those who already connected.' An agent knows exactly when to prefer `search` over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「いざ貸す」（izakasu.jp）の種類・紹介文・読み込んだページ数・主なページを返します。持ち家を貸したい方や、所有物件の賃貸管理を見直したい方が、どんなサービスか、何を調べられるかを最初に把握するときに使ってください。賃貸管理一括査定サービスと公式メディアの全体像を確認し、持ち家の賃貸、転勤・相続・空き家の活用、管理会社の比較など、自分の検討テーマに関連するサイトかを判断するために使えます。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 goes beyond them by disclosing the shape of the response (types, description, page count, main pages), which matters because no output schema exists. It says nothing about caching, rate limits, or freshness of the 'loaded pages' count.
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?
Return contents are front-loaded in the first sentence, followed by audience and use case. The second and third sentences overlap noticeably — both re-list target users (homeowners wanting to rent out) and research topics, so a sentence of redundancy survives. Still compact and readable overall.
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 parameters, no nested objects, and no output schema, the description carries the return-value burden and does so adequately by listing the four returned elements. Minor ambiguity remains about what 'types' (種類) enumerates, but nothing needed to invoke the tool correctly 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?
The tool takes zero parameters, so there are no parameter semantics for the description to explain; baseline 4 applies. The description appropriately spends its words on scope and returns instead of inventing parameter detail.
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 resource (izakasu.jp) and enumerates exactly what it returns: site types, description text, loaded-page count, and main pages. That is far more specific than a tautology. It stops short of distinguishing itself from siblings like list_pages or get_page, which return overlapping 'pages' data, so an agent must infer the boundary.
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 a clear use context: call it first to understand what the service is and whether the site matches your research theme (renting a home, job transfer, inheritance, vacant houses, management-company comparison). That is explicit when-to-use guidance. It offers no when-not guidance and never names an alternative sibling tool for the narrower questions it raises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fetchget_pagelist_pagessearchsearch_pagessite_overviewSEO コンサルタントの柏崎剛が運営する、検索エンジン対策の情報サイトです。（tsuyoshikashiwazaki.jp の内容を検索して答える。ヨミタス経由）
CodeNate(こうでねーと)は、プロのコーディネーターがデザイン料0円でお部屋のインテリアを提案するサービスです。（codenate.jp の内容を検索して答える。ヨミタス経由）
無料でしっかり使える、審査制のプレスリリース配信サービスです。（prenica.jp の内容を検索して答える。ヨミタス経由）
サイトのページを読み込んで、AI アプリがつなげる形（MCP サーバー）にして配信する無料のサービスです。（yomitasu.jp の内容を検索して答える。ヨミタス経由）
Add one secure layer between your agents and this server.