柏崎剛がプロデュースする陶器「慈焼」の公式サイトです。（earthenware.jp の内容を検索して答える。ヨミタス経由）
Scored across 6 tools
fetch and get_page are clearly overlapping (get_page is legacy). Similarly, search and search_pages overlap. The descriptions help by marking legacy tools, but the boundaries are not perfectly distinct.
Most names follow a verb_noun or noun pattern (fetch, get_page, list_pages, search, search_pages, site_overview). Minor inconsistency: fetch lacks a noun component, but overall consistent.
6 tools is reasonable for a website content server. However, two pairs are legacy duplicates, slightly inflating the count. Core set is 4 tools.
Provides search, fetch, list, and overview, covering most agent needs for reading site content. No create/update/delete needed as it's read-only. Minor gap: no tool to retrieve a specific page by URL (fetch might do that, but not explicit).
「慈」のページの本文を、最初から最後まで返します。search で見つけた作品の説明・サイズ・価格や、販売の条件をくわしく読むときに使います。
| 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 and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it returns the full body text from start to end, implying unfiltered output. However, it does not discuss potential limitations, size of output, or any request-specific behavior beyond what annotations already provide.
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 description is only two sentences, front-loads the primary behavior, and contains no filler. Every phrase earns its place by specifying scope, output, and the usage context.
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?
Given the low complexity (one required parameter), the presence of an output schema, and the read-only annotations, the description is complete enough. An agent can determine when to call it and what it returns, and the schema covers the parameter details.
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 schema already explains the 'id' parameter well, including that a URL or path is acceptable. The description itself adds no additional parameter-specific semantics, so the baseline score of 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 a specific verb ('返します') and a clear resource ('「慈」のページの本文'), and explains that it returns the full body from beginning to end. It ties the tool to the search flow ('search で見つけた作品...'), which distinguishes it from a generic listing tool, though it does not explicitly differentiate from the sibling '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?
It explicitly says when to use this tool: after search, when the user wants to read the detailed description, size, price, and sales conditions of a found work. It provides clear context but does not mention exclusions or alternative sibling tools like 'get_page'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「慈（慈焼 公式サイト）」（earthenware.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 the safety profile is covered by structured data. The description adds useful legacy/deprecation context and notes the different return format, but doesn't detail the return shape or error behavior. Given annotation coverage, a 3 is appropriate—it adds some value without going deep.
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 concise sentences in Japanese with the legacy status front-loaded before the functional explanation. The parenthetical site name adds a little noise but is minor. Efficient 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?
For a single-parameter, read-only, deprecated tool with no output schema, the description is fairly complete: it explains the purpose, the key difference from fetch, and when to choose fetch instead. The main gap is not explaining how the return format differs, but this is a minor omission given the tool's simple, legacy nature.
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%—the url parameter is fully documented in the schema (URL or path, Japanese characters acceptable). The description adds no parameter-level information beyond what the schema already provides, so the 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?
The description clearly states this tool returns the page body, positioning it as a legacy version of fetch. It explicitly distinguishes itself from the sibling fetch by noting the different return format, which helps an agent differentiate. It's clear enough but doesn't deeply specify what 'body' means or how exactly the return differs.
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?
This is exemplary guidance. The description explicitly names fetch as the alternative and gives a concrete directive: use fetch for new usage, and only use this tool for those already connected to the legacy version. This is exactly the kind of when/when-not/alternative routing the rubric asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「慈」に読み込まれているページの一覧（タイトルと URL）を返します。/asp-products/ の下が、作品 1 点ずつのページです。どんな作品があるかを並べて紹介したいときに使います。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that the result is a list of titles and URLs and clarifies the /asp-products/ subpath, but it does not disclose ordering, pagination behavior, or whether the list includes non-work 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?
The description is three short sentences, front-loads the core return value, and each sentence adds useful context: what is returned, the relevant URL path, and when to use the tool. There is no filler or redundancy.
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 simple list tool with two pagination parameters and no output schema, the description adequately explains the result shape and scope. It could be more complete by explicitly noting how limit/offset apply, but the intended use case and path structure are clear.
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 carries the burden of explaining limit and offset. It does not mention pagination, defaults, or how these parameters affect the result; the parameter names are somewhat self-explanatory, but that is not enough to compensate for the lack of explicit guidance.
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 clearly states the action: it returns a list of pages loaded in '慈' with titles and URLs, and it gives the specific /asp-products/ path context. This distinguishes it from get_page or fetch, though it does not explicitly name sibling tools.
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?
The description says to use it 'when you want to introduce works by listing them', which provides a clear usage context. It does not explicitly state when not to use it or name alternatives, so it misses the full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「慈」（陶器「慈焼」の公式サイト）のページから、言葉に当てはまる箇所を抜粋つきで探します。作品の名前（「竹取物語」「蛙」など）、大きさ、価格、売り切れかどうか、購入のしかた、販売の条件（特定商取引法に基づく表記）を探せます。作品や購入について質問されたら、まずこれを使ってください。
| 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only that results come with excerpts (抜粋つき), which is modest extra value. It says nothing about result limits, ranking, pagination, or empty-result behavior, so it does not go beyond the annotation baseline by much.
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?
Two sentences, front-loaded with what is searched and immediately followed by the usage trigger. No filler or repetition, though the enumeration of searchable fields makes the first sentence somewhat long.
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 the description need not explain return values, and with one well-documented parameter the tool is simple. The description covers scope, searchable content, and when to prefer it, leaving only sibling disambiguation (search_pages) as a gap.
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 query parameter is already documented with an example, so the baseline would be 3. The description adds meaning beyond the schema by listing the semantic targets a query can hit (作品名、大きさ、価格、在庫、購入方法、特商法表記), helping the agent formulate effective queries rather than just pass a string.
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 gives a concrete verb (探す/抜粋) and a specific resource (「慈」陶器サイトのページ), and enumerates the kinds of content that can be found (作品名、大きさ、価格、売り切れ、購入方法、特商法表記). This is far more than a restatement of the name 'search'. However, it never distinguishes itself from the sibling tool search_pages, which an agent could easily confuse with it.
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 explicit priority guidance: 「作品や購入について質問されたら、まずこれを使ってください」, which tells the agent when this tool is the right first move. It stops short of naming alternatives or stating when NOT to use it (e.g., vs. search_pages or get_page), so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「慈（慈焼 公式サイト）」（earthenware.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 declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by stating that the return format differs from 'search' and that it is a legacy alias. This is beyond the annotations and helps an agent understand what to expect, though it doesn't detail the return structure.
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 description is two concise sentences in Japanese, front-loading the legacy status and the recommendation to use 'search'. It avoids unnecessary detail and is easy to parse, though it could be slightly more structured. Overall, it is efficient and focused.
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 tool with only two parameters and no output schema, the description provides the essential routing information (use 'search' instead) but lacks clarity on the return format—only that it is 'different'. Since the tool is deprecated, this might be acceptable, but an agent could still invoke it and would benefit from knowing what the response looks like. The description is minimally complete for calling the tool, but not fully informative.
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% (only 'query' has a description; 'limit' lacks one). The description adds no information about parameter semantics—it doesn't explain 'limit' behavior or how the query should be formatted. It fails to compensate for the missing schema documentation, leaving the agent without additional guidance on parameters.
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 clearly states the tool's purpose: it searches within the site (earthenware.jp) and explicitly differentiates from its sibling 'search' by noting a different return format. The verb and resource are specific, and the legacy status is clarified, removing ambiguity for an agent.
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?
The description provides explicit guidance: it states this is a legacy tool kept for existing connections and instructs new users to use 'search' instead ('新しく使うときは search を使ってください'). This clearly communicates when not to use it and names the preferred alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「慈」の概要を返します。柏崎剛がプロデュースする陶器「慈焼」の作品を紹介・販売するサイトで、運営は株式会社コンテンシャルです。どんなサイトかを最初に知りたいときに使います。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context by saying the tool returns an overview and summarizing the site's subject and operator, going slightly beyond the structured 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 description is two focused sentences: the first defines the returned resource, the second adds context and the intended use case. Every sentence earns its place with no redundancy.
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 parameterless, read-only overview tool with no output schema, the description fully states what is returned, why it matters, and when to invoke it. 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?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. Baseline 4 applies for parameterless tools.
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 specific action ('「慈」の概要を返します') and a clear resource: an overview of the site. It also explains what the site is, distinguishing this high-level overview from the sibling page- and search-level tools.
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 says to use this tool 'when you first want to know what kind of site it is,' which is clear usage context. However, it does not name alternatives or state when not to use it, so it stops short of full exclusion guidance.
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 の内容を検索して答える。ヨミタス経由）
SEO対策研究室（柏崎剛）の公開情報を検索・取得できる読み取り専用サーバー。出典は canonical URL に固定。
いざ貸すは、持ち家を貸したい方や、所有物件の賃貸管理を見直したい方のための賃貸管理一括査定サービスです。（izakasu.jp の内容を検索して答える。ヨミタス経由）
SEO 対策とサイト改善を手がける株式会社コンテンシャルの公式サイトです。（seo.contencial.co.jp の内容を検索して答える。ヨミタス経由）
Add one secure layer between your agents and this server.
