SEO コンサルタントの柏崎剛が運営する、検索エンジン対策の情報サイトです。（tsuyoshikashiwazaki.jp の内容を検索して答える。ヨミタス経由）
Scored across 6 tools
fetch and get_page overlap in purpose (same function, different return format), as do search and search_pages. Descriptions clearly mark get_page and search_pages as deprecated and advise using fetch/search, which helps, but the redundancy still creates potential for misselection if an agent doesn't read carefully.
Mixed verb styles: fetch and search are bare verbs; get_page, list_pages, and search_pages use verb_noun; site_overview is a noun phrase. No consistent pattern, though all names are snake_case and readable.
6 tools is a reasonable count for a content site, but two are redundant deprecated duplicates (get_page and search_pages), effectively reducing the unique tool set to 4. This slightly inflates the count without adding new capability.
The surface covers core read operations: searching articles, listing pages, fetching full page content, and getting a site overview. No write operations are needed for a public site, though a minor gap exists for explicit page metadata retrieval beyond what fetch returns.
「SEO対策研究室」のページの本文を、最初から最後まで返します。search で見つけた記事の手順や根拠をくわしく読むとき、アンケート結果の選択肢ごとの割合を確かめるときに使います。ページの 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?
The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the tool returns the page body 'from beginning to end' and that it targets the SEO対策研究室 site, but it does not reveal other behavioral details such as formatting, limits, or error behavior. This is adequate 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 sentences with no filler. The main behavior is stated first, followed by practical use cases and the required parameter format. 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?
For a simple, read-only fetch operation with a single fully documented parameter, an output schema present, and safety annotations available, the description is complete. An agent has enough information to select and call this tool without additional context.
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 has 100% description coverage: the single required parameter id is fully explained as the page URL or path, and the description also says to specify the URL or path. The description adds no extra meaning beyond the schema, 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 the action: return the full body text of a specified page on the SEO対策研究室 site. It also names concrete use cases (reading article procedures/evidence, checking survey percentages). It does not explicitly distinguish itself from the sibling get_page, so it stops short of a 5.
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 gives clear when-to-use context: after finding articles via search or when verifying survey result percentages. It does not state exclusions or explicitly compare with alternatives like get_page, but the provided use cases are specific enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「SEO対策研究室」（tsuyoshikashiwazaki.jp）の以前の名前の機能です（すでにつないでいる人のために残しています）。fetch と同じようにページの本文を返しますが、返す形が違います。新しく使うときは fetch を使ってください。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ページの URL かパス（日本語のままでも可） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate read-only and non-destructive behavior, the description adds important context: this is a deprecated legacy alias, returns content like fetch, but has a different return format. It could be more specific about that format difference, but the deprecation notice is valuable.
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 concise and front-loads the legacy/deprecation context, then routes to fetch. Each sentence serves a purpose, though the parenthetical clarification could be seen as slightly redundant with the opening phrase.
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?
The description covers deprecation, usage guidance, and safety via annotations, and the schema covers the parameter. However, since there is no output schema, the vague statement that the return format differs from fetch leaves a meaningful gap for anyone who actually needs to call this legacy tool.
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 input schema already fully documents the single required url parameter, including that Japanese text is allowed. The description adds no additional parameter-level detail beyond what the schema provides, 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 clearly states that the tool returns a page's body in the same way as fetch, and the title explicitly identifies it as reading page content. It also distinguishes itself from fetch by noting the different return format and its legacy status.
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 directs new users to use fetch instead and notes that the tool is kept only for those already connected. This provides clear guidance on when to use this tool versus the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「SEO対策研究室」に読み込まれているページの一覧（タイトルと URL）を返します。/blog/ は SEO の解説記事、/datasets/ は SEO に関するアンケート結果、/seo-case-studies/ と /initiatives/ は支援事例、/news/ は登壇・寄稿などのお知らせ、/paper/ は資料です。分野ごとに記事をまとめて紹介したいときに使います。
| 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, covering the safety profile. The description adds useful behavioral context by specifying the exact return content (titles and URLs) and the meaning of different URL path prefixes, which goes beyond what the annotations 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 compact and front-loaded, leading with the core behavior and then adding category details and a usage note. The URL path enumeration is somewhat dense but earns its place by clarifying what the returned pages will contain. No filler or redundant phrasing is present.
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 two-parameter list tool with no output schema, the description covers the return shape, the page categories, and the intended use case. It does not mention ordering or pagination behavior, but the schema already provides limit/offset constraints, so nothing critical 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 schema description coverage is 0%, and the description does not mention the limit or offset parameters at all. The parameter names and schema constraints are fairly self-explanatory, but the description fails to compensate for the lack of schema descriptions, so an agent gets no guidance on how pagination works in this tool.
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 that the tool returns a list of page titles and URLs for the 'SEO対策研究室' site, and it enumerates the URL path categories. It does not explicitly differentiate itself from sibling tools like search or search_pages, but the verb '返します' and resource scope make the purpose unambiguous.
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 gives a clear usage context: '分野ごとに記事をまとめて紹介したいときに使います' (use when you want to introduce articles grouped by field). It does not mention when not to use it or name alternative tools, but the stated use case is sufficient for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「SEO対策研究室」（SEO コンサルタント柏崎剛のサイト）の記事から、言葉に当てはまる箇所を抜粋つきで探します。SEO、Google のアルゴリズム、キーワード選定、内部リンク、E-E-A-T、AI 検索への対策（LLMO）など、検索エンジン対策について質問されたら、まずこれを使ってください。「サイテーション」「中古ドメイン 違法」のように短い言葉で探します。SEO 担当者へのアンケート結果、支援事例、登壇・寄稿のお知らせも探せます。答えには、見つけたページの 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds that the scope is one specific site and that results carry excerpts and URLs, which is useful context. It does not discuss pagination or result limits, so a 3 is appropriate.
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 paragraph is front-loaded with scope and the trigger condition, and most sentences carry unique information. It is somewhat long and the list of covered topics is verbose, but nothing is purely 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?
With one fully documented parameter, an output schema, and complete safety annotations, the description supplies the domain scope, trigger context, and query examples an agent needs. The only notable omission is differentiation from the sibling 'search_pages'.
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% for the single 'query' parameter, so the schema already documents it. The description only adds query-style guidance ('short words', with examples) which overlaps the schema's own example. Baseline 3 fits.
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: search the articles of a named site ('SEO対策研究室') for matching passages with excerpts. This is far better than a tautology. However, it does not distinguish itself from the near-identical sibling 'search_pages', which an agent would likely confuse it with.
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 trigger ('when asked about SEO, Google algorithms, keyword selection, internal links, E-E-A-T, LLMO, use this first') and query style ('short words like サイテーション'). But it never says when NOT to use it or names the alternative 'search_pages', so the agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「SEO対策研究室」（tsuyoshikashiwazaki.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 cover read-only and non-destructive behavior. The description adds legacy/deprecation status and warns that the return format differs from `search`, which is not visible in the annotations. It could specify the return shape further, but it adds meaningful behavioral context beyond 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?
Three short Japanese sentences, each earning its place: what it is, how it differs from `search`, and which tool to use instead. No filler or repetition of schema 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 read-only legacy search tool with two simple parameters, the description adequately explains what it does, how it relates to `search`, and what a new caller should do. The unspecified return format is a minor gap, but the explicit redirect to `search` makes it non-critical.
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 covers `query` with an example, but `limit` has no description; the tool description adds no parameter-level detail to compensate. However, the parameters are simple and the default/min/max constraints provide enough guidance for correct invocation.
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?
Description clearly states it searches inside the site ('サイトの中を探します') and explicitly identifies itself as the old-name version of `search` with a different return form ('返す形が違います'). This makes its purpose concrete and differentiates it from the sibling `search`.
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 new users should use `search` instead ('新しく使うときは search を使ってください') and explains it is kept only for those already connected ('すでにつないでいる人のために残しています'). This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「SEO対策研究室」の概要を返します。SEO コンサルタントの柏崎剛が、検索エンジン対策の基本から AI 検索への対策、WordPress 向けの無料 SEO プラグインまでを、初心者にもわかる言葉で解説しているサイトです。だれが書いているか、何が調べられるかを最初に知りたいときに使います。
| 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, so the safety profile is covered. The description adds useful content context (author, topics, audience) but does not disclose any additional behavioral traits such as output shape, length, or dynamic behavior. This is adequate 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?
The description is three compact sentences: action, content summary, and usage condition. It is front-loaded with the core action and every sentence adds distinct information without 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 no-parameter read-only overview tool, the description fully covers what the tool returns, the site's subject matter, and when to call it. No output schema exists, but the content summary and usage guidance are sufficient for an agent to select and invoke the tool correctly without missing essential information.
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 description coverage is 100%, so there is no parameter burden for the description to carry. Per the baseline for 0-param tools, a 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 object: '「SEO対策研究室」の概要を返します' (returns the overview of the SEO対策研究室 site). It then clarifies the site's content and author, and the final sentence positions it as the entry point for learning who writes the site and what can be researched, distinguishing it from content-fetching siblings like get_page and search.
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: 'だれが書いているか、何が調べられるかを最初に知りたいときに使います' (use when you first want to know who writes it and what can be investigated). It gives clear context but does not name exclusions or alternative tools, so it stops short of a 5.
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.
search1 field changedOutput schema / properties / candidatesAdded value: +{
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}fetchsearchget_pagelist_pagessearch_pagessite_overviewSEO対策研究室（柏崎剛）の公開情報を検索・取得できる読み取り専用サーバー。出典は canonical URL に固定。
SEO 対策とサイト改善を手がける株式会社コンテンシャルの公式サイトです。（seo.contencial.co.jp の内容を検索して答える。ヨミタス経由）
いざ貸すは、持ち家を貸したい方や、所有物件の賃貸管理を見直したい方のための賃貸管理一括査定サービスです。（izakasu.jp の内容を検索して答える。ヨミタス経由）
XR（AR/VR/MR）に関する情報をメインに扱うサイトです。（orecen.com の内容を検索して答える。ヨミタス経由）
Add one secure layer between your agents and this server.
