柏崎剛がプロデュースする陶器「慈焼」の公式サイトです。（earthenware.jp の内容を検索して答える。ヨミタス経由）
Scored across 4 tools
Each tool has a clearly distinct role: site_overview explains the site, list_pages enumerates pages, search_pages finds matching content with excerpts, and get_page returns the full text of a page. There is no meaningful overlap between them, and search_pages is explicitly positioned as the entry point for content queries.
Three tools follow a clear verb_noun pattern: get_page, list_pages, search_pages. site_overview deviates slightly by being a noun phrase rather than a verb_noun construction, but all names use consistent snake_case and are easy to predict.
Four tools is a well-scoped size for a read-only website content server. Each tool earns its place: overview, index, search, and full-page retrieval cover the core operations without redundancy.
The tool set covers the complete read-only lifecycle for this site: understanding what the site is, seeing available pages, searching for specific details, and reading full page content. No create, update, or delete operations are needed for this domain, so there are no obvious gaps.
「慈」のページの本文を、最初から最後まで返します。search_pages で見つけた作品の説明・サイズ・価格や、販売の条件をくわしく読むときに使います。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ページの URL かパス（日本語のままでも可） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the behavioral burden. It discloses the main behavior (the full page body is returned), but it doesn't specify response format, errors, or access assumptions. This is adequate for a simple read tool but not rich.
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 compact sentences, each earning its place: the first states the core behavior, the second states the usage context. No filler or repetition.
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 tool with no output schema, the description covers what is returned, the source of the URL, and when to call it. It could be more complete by mentioning output format or failure behavior, but nothing essential is missing for a straightforward call.
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 schema already covers the url parameter 100%, so the baseline is 3. The description adds context that the URL should be for pages found via search_pages and that it contains work details, giving the parameter a purpose beyond its raw syntax.
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 operation: returns the body text of a page from start to finish ('「慈」のページの本文を、最初から最後まで返します'). It also ties the tool to a specific use case, reading details of works found via search_pages, which distinguishes it from siblings like search_pages and list_pages.
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 when to use it: 'search_pages で見つけた作品の説明・サイズ・価格や、販売の条件をくわしく読むときに使います'. It doesn't enumerate when-not-to-use or mention list_pages/site_overview as alternatives, so it falls just short of full guidance.
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?
With no annotations, the description carries the burden of explaining behavior. It states that the call returns a list of titles and URLs and scopes the result to pages loaded in '慈', but it does not disclose whether results are paginated, ordered, or limited to metadata only. This is adequate for a read-style listing, though not a rich behavioral disclosure.
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 short sentences: the first gives the core result and return shape, the second gives domain context and the intended use case. There is no filler and no repetition of schema 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?
For a simple optional-parameter listing with no output schema, the description gives the essential return shape (title/URL list), the scope, and the intended use case. It could go further by mentioning default pagination, but nothing critical is missing for making a basic call.
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% for the two parameters, and the description says nothing about limit or offset. Even though the parameter names and schema constraints hint at pagination, the description does not add any meaning beyond what the schema already provides.
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 uses a clear verb ('返します') and identifies the exact resource: pages loaded in '慈', returning their titles and URLs. It also explains the /asp-products/ subpath, which helps an agent distinguish this flat list from sibling tools like get_page, search_pages, and site_overview.
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 provides an explicit use case: 'use when you want to line up and introduce what works exist.' It does not explicitly contrast itself with search_pages or get_page, so the when-not guidance is left implicit, but the context is clear enough.
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 |
|---|---|---|---|
| limit | No | ||
| query | Yes | 探したい言葉（例: 料金 支払い方法） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that results include excerpts (抜粋つき) and defines the searchable scope. However, it doesn't describe result count or shape, behavior on no matches, or how many pages are searched, leaving notable gaps for a search tool.
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 compact sentences. The first front-loads the core function (site, verb, excerpt behavior), and the second adds concrete scope examples plus a use-first directive. Every sentence earns its place with no filler.
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 low-complexity search tool with 2 params, no output schema, and no annotations, the description covers the search scope, result form (excerpts), and invocation context. Gaps like exact return format and no-match behavior are moderate, and the limit parameter's effect on results is left implicit, but the description is nearly sufficient on its own.
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 50%: query has a description with concrete examples ('料金 支払い方法'), while limit has only type/default/min/max. The tool description adds no parameter-level meaning, but limit's semantics are reasonably inferable from its name and numeric default, so the schema gap is a minor issue rather than a critical one.
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 resource: searching pages of the 'Ji' pottery site for passages matching words, with excerpts. It enumerates concrete findable content (work names, sizes, prices, sold-out status, purchase methods, sales conditions), which clearly distinguishes it from the sibling tools get_page, list_pages, and site_overview.
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 final sentence gives an explicit trigger condition: 'If asked about works or purchases, use this first.' This tells the agent when to invoke the tool. It doesn't name alternative tools or state when not to use it, but the routing instruction is clear and actionable.
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?
No annotations are provided, so the description carries the burden. It clearly says the tool 'returns' an overview rather than mutating anything, and it describes what the overview covers. For a zero-parameter informational tool, this is sufficiently transparent, though it could be more explicit about side effects or data source.
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: the core action, the site context, and the usage condition. It is front-loaded with the most important information and contains no redundant or filler content.
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 no-parameter informational tool, the description fully covers what the tool returns, what the site is, and when to use it. The lack of an output schema is not a gap because the tool's return value is a simple site overview and the description already sets expectations.
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, so the schema is trivially complete. There is nothing meaningful for the description to add about parameter semantics, and a baseline of 4 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 opens with a specific verb and resource: '「慈」の概要を返します'. It also explains what the site is about (Jiyaki pottery by Kashiwazaki Tsuyoshi, operated by Contential), which makes the tool's purpose concrete. This clearly differentiates it from page-level siblings like get_page, list_pages, and search_pages.
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 explicitly states when to use the tool: 'どんなサイトかを最初に知りたいときに使います'. It does not explicitly name alternatives or exclusions, but the 'first, site-level overview' framing contrasts naturally with the sibling page-focused tools, giving an agent enough 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.
get_pagelist_pagessearch_pagessite_overviewSEO コンサルタントの柏崎剛が運営する、検索エンジン対策の情報サイトです。（tsuyoshikashiwazaki.jp の内容を検索して答える。ヨミタス経由）
SEO対策研究室（柏崎剛）の公開情報を検索・取得できる読み取り専用サーバー。出典は canonical URL に固定。
サイトのページを読み込んで、AI アプリがつなげる形（MCP サーバー）にして配信する無料のサービスです。（yomitasu.jp の内容を検索して答える。ヨミタス経由）
Add one secure layer between your agents and this server.
