接待に、会食に。創業60年以上の、銀座 の 一日一組 の 完全個室 の老舗 ふぐ料理店 、高級和食店 、ぎんざ姿 でございます。（fugusugata.jp の内容を検索して答える。ヨミタス経由）
Scored across 6 tools
fetch/get_page and search/search_pages are near-duplicate pairs that could be confused; descriptions mitigate this by explicitly flagging get_page and search_pages as legacy aliases with different output formats, but the overlap remains.
Names mix conventions: bare verbs (fetch, search), verb_noun (get_page, list_pages, search_pages), and a noun phrase (site_overview). Readable but not a predictable pattern.
Six tools is well-scoped for a read-only site-content server, though two are deprecated duplicates that dilute the effective surface to four distinct capabilities.
fetch, search, list_pages, and site_overview cover the read-only lifecycle (discover, browse, search, retrieve) needed for a content site; no write operations, which is appropriate here, so coverage is solid.
「銀座の貸切個室で高級天然とらふぐ料理と近江牛 ぎんざ姿」（fugusugata.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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the whole body text is returned and that the scope is this one site, but says nothing about truncation limits, size, or what happens on a missing/invalid id.
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, no filler, and the accuracy instruction lands at the end as a clear call to action. The site name is front-loaded in a slightly awkward way, but overall the text is tight and readable.
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-value shape need not be explained, and the description correctly focuses on input sourcing and when to trust fetched content. For a single-parameter read tool this is close to complete; only edge-case behavior (invalid id, oversized page) is unaddressed.
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% and the single `id` parameter is already documented as accepting a search-result id, a URL, or a path, including Japanese characters. The description largely restates that same information, adding no new syntax or format 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?
States a specific verb+resource: returns the full body text of a loaded page on the target site (fugusugata.jp). It is clear what comes back, but it never distinguishes itself from the sibling get_page, which by name appears to do something very similar, so the agent must guess between the two.
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?
Gives a concrete usage trigger: verify the body text before answering anything where accuracy matters (prices, dates, conditions, terms). It also hints at the workflow by saying the id can come from search results. No explicit alternatives or exclusions are named, though.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「銀座の貸切個室で高級天然とらふぐ料理と近江牛 ぎんざ姿」（fugusugata.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 and non-destructive behavior. The description adds useful context: it returns page body text similar to fetch but in a different format. It does not specify what that format is, which is a notable omission for a deprecated alias, but annotations carry most of the safety burden.
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 first sentence is an unexplained reference to a restaurant name, which is confusing and front-loads non-informational content. The key fact (legacy alias, use fetch instead) appears later. It is not verbose but is poorly organized.
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 deprecated alias, the description adequately covers the replacement path and basic behavior. It omits the return format difference from fetch, which matters if an agent must handle this tool's output, but that gap is narrow.
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%, so the schema fully documents the single 'url' parameter including the Japanese path allowance. The description adds nothing about the parameter, which is acceptable given the schema baseline.
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 identifies this as a legacy alias of the 'fetch' functionality, which is its core purpose. However, it does not state plainly what the tool does at the start – the first clause is an opaque note about a business name. The agent must read to the end to learn it returns page body content.
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 names the replacement tool ('fetch') and instructs new users to use it, while explaining why the alias persists. This is exactly the when-to-use/when-not guidance that helps an agent route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「銀座の貸切個室で高級天然とらふぐ料理と近江牛 ぎんざ姿」（fugusugata.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 read-only, non-destructive, non-open-world behavior, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot: pagination of 50 per call, a limit ceiling of 200, and offset-based continuation, plus the shape of the returned data.
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 compact sentences, front-loaded with what is returned, then pagination mechanics, then usage conditions. The embedded brand name in the first sentence is slightly heavy but serves to identify 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?
For a two-parameter, zero-required, read-only listing tool with no output schema, the description covers return shape, pagination, and usage context. Little an agent needs to call 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 0%, so the description must carry the load, and it does: it explains the default page size of 50, that limit maxes at 200, and that offset retrieves the continuation. It stops short of stating offset units explicitly, but the semantics are inferable from '続き'.
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 (一覧を返す/list) and resource (pages loaded from the site) plus the returned fields (title and URL), which is more than a restatement of the name. It does not explicitly name which sibling it contrasts with, though the 'when search fails' framing implicitly positions it against search/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?
Gives clear when-to-use conditions: when you want to know what pages exist, or when a search attempt has failed to surface a page. It implies the search-then-list fallback workflow without explicitly naming the alternative tools or stating exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「銀座の貸切個室で高級天然とらふぐ料理と近江牛 ぎんざ姿」（fugusugata.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?
Adds real behavioral context beyond the annotations: only pre-loaded pages are searchable, the whole internet is out of scope, and updates made after loading are not reflected (consistent with openWorldHint=false). It also discloses the retry/fallback policy and instructs the agent not to guess, which is useful operational detail.
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 is front-loaded, but the very long site name is repeated verbatim twice and the fallback/rephrasing instructions run long. Several sentences carry guidance that could be tightened without losing meaning.
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-format detail is unnecessary. The description covers scope limits, retry strategy, and failure behavior, leaving only sibling differentiation unaddressed.
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?
One parameter with 100% schema description coverage, including a concrete example (料金 支払い方法). The description adds no query syntax or matching semantics beyond what the schema already provides, so the baseline of 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 (探す/search) and a clear resource scope: pages loaded from fugusugata.jp, returning excerpts and URLs. It does not, however, differentiate itself from the sibling tool search_pages, which an agent could easily confuse with this generically-named '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?
Explicitly directs the agent to use this first when asked about 銀座の...ぎんざ姿, and prescribes escalation behavior (rephrase with abbreviations/synonyms, then read returned candidate pages, then admit failure). It never contrasts with the sibling search_pages or fetch/get_page, so the routing guidance is clear but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「銀座の貸切個室で高級天然とらふぐ料理と近江牛 ぎんざ姿」（fugusugata.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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds the deprecation/backward-compatibility status and warns that the return shape differs from `search`, which is useful context, but it never explains how the shape differs or what is returned.
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 compact sentences that front-load the site identification and the legacy status, then the sibling routing. Efficient, with only mild redundancy between the title's 'previous name' and the body's 'previously named feature.'
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 2-parameter search with no output schema, the purpose and routing are adequately covered. However, since it explicitly claims the return shape differs from `search` and there is no output schema, the description leaves a real informational gap about what callers actually get back.
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?
At 50% schema description coverage, the description must compensate for undocumented parameters, and it offers nothing about `limit` (range 1-20, default 5) or any query syntax beyond what the schema already contains. The description adds no parameter meaning over the schema.
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 identifies a concrete verb+resource (site search) and explicitly frames this as the legacy/renamed version of the search feature retained for backward compatibility. It clearly differentiates itself from the sibling `search` by noting the same behavior with a different return shape, though the 'previous name' framing makes the identity slightly indirect.
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 states an explicit when-not-to-use and names the alternative: 'When using it newly, please use search' and 'kept for those already connected.' An agent knows exactly to prefer `search` for new work and to only fall back to this tool for existing integrations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「銀座の貸切個室で高級天然とらふぐ料理と近江牛 ぎんざ姿」（fugusugata.jp）がどんなサイトかを返します。種類・紹介文・読み込んだページ数・主なページが分かります。最初にサイトの全体像をつかみたいときに使います。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, non-destructive, closed-world operation, so the safety burden is covered. With no output schema, the description usefully discloses the return contents (type, intro, page count, main pages), which is real added value, though nothing is said about caching, freshness, or limits.
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, front-loaded with what is returned before the usage hint. The opening sentence embeds a long, oddly specific restaurant name/domain, which adds bulk without helping an agent decide or call; otherwise efficient.
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 tool with no output schema, the description does the essential work of enumerating the returned fields and stating when to call it. Auth, quota, and failure behavior go unmentioned, but little is genuinely missing for correct invocation.
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 and the schema is trivially covered, so the baseline is 4. The description appropriately adds no parameter detail because there is nothing to document.
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 specific verb and resource: it returns what a site is, listing what's available (種類・紹介文・読み込んだページ数・主なページ). This is clearly a site-level summary distinct from the page-level siblings (get_page, list_pages, fetch), though it never names a sibling to make the boundary explicit.
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?
"最初にサイトの全体像をつかみたいときに使います" gives an explicit when-to-use condition (first, to grasp the overall picture). However, it names no alternative tool or when-not condition, leaving sibling routing to inference.
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_overview銀座の一日一組の個室料理店、ぎんざ姿が提供する、天然とらふぐ料理と近江牛すき焼き・しゃぶしゃぶのネットショップ…（shop.ginzasugata.online の内容を検索して答える。ヨミタス経由）
SEO コンサルタントの柏崎剛が運営する、検索エンジン対策の情報サイトです。（tsuyoshikashiwazaki.jp の内容を検索して答える。ヨミタス経由）
いざ貸すは、持ち家を貸したい方や、所有物件の賃貸管理を見直したい方のための賃貸管理一括査定サービスです。（izakasu.jp の内容を検索して答える。ヨミタス経由）
CodeNate(こうでねーと)は、プロのコーディネーターがデザイン料0円でお部屋のインテリアを提案するサービスです。（codenate.jp の内容を検索して答える。ヨミタス経由）
Add one secure layer between your agents and this server.