AI学習・オンライン教材を提供する「インスタント学習」は、資格試験・検定試験・ビジネススキルなどの学習を、イ…（instant.aigakushu.online の内容を検索して答える。ヨミタス経由）
Scored across 6 tools
fetch and get_page perform the same function (differing only in output format), and search and search_pages are likewise near-duplicates. The descriptions do flag get_page/search_pages as legacy and tell agents to prefer fetch/search, which mitigates the confusion, but the set still contains two redundant pairs that an agent could misselect.
All names are snake_case, but the verb conventions are mixed: bare verbs (fetch, search) coexist with verb_noun forms (get_page, list_pages, search_pages) and a noun phrase (site_overview). It is readable but not a single predictable pattern.
Six tools is a reasonable size for a site-reading server. However, two of the six (get_page, search_pages) are deprecated aliases that duplicate existing functionality, so the effective surface is smaller than the count suggests.
The read surface is well covered: site_overview for the big picture, list_pages to enumerate, search to find, and fetch to retrieve full content. No write operations exist, but a content-lookup server plausibly does not need them.
「オンライン学習 講座 生成AI IT 資格講座」（instant.aigakushu.online）の、読み込んだページの本文を全文返します。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 it returns the entire page body and is scoped to one site, which is useful, but says nothing about truncation limits, pagination, or what happens with an 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?
Three short sentences that front-load what the tool returns before explaining the id and the accuracy rationale. No filler, though the embedded domain and course name adds some noise without much functional value.
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 one-parameter read tool with an output schema (so return values need not be described), the description covers what it returns, where the id comes from, and when to call it. The one missing piece is how it relates to the near-identical sibling get_page.
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 id parameter's schema description already states it accepts a search-result id, URL, or path, including Japanese. The description largely repeats that ('探した結果の id ... か、ページの URL・パスを渡します') rather than adding syntax or format detail 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?
States a specific verb and resource in Japanese: it returns the full body text of a loaded page on a named domain. The scope (whole body text, specific site) is concrete. However, it never distinguishes itself from the sibling get_page, which by name alone appears to do something very similar, so an agent cannot route between them from this text.
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 clear condition for use: verify the page body before answering when accuracy matters (pricing, dates, conditions, terms), and explains where the id comes from (search results). It offers context but no exclusions and no explicit comparison to alternatives like get_page or search_pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「オンライン学習 講座 生成AI IT 資格講座」（instant.aigakushu.online）の以前の名前の機能です（すでにつないでいる人のために残しています）。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, openWorldHint=false, and destructiveHint=false, so safety is covered structurally. The description adds genuinely useful context beyond the annotations: this is a deprecated alias kept for backward compatibility, and its output shape differs from fetch's, which is important behavioral information for an agent deciding between the two.
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?
Front-loaded with the legacy framing, then the behavioral difference, then the routing advice. Slightly padded by restating the site name and the 'kept for connected users' clause, but each sentence carries routing or behavioral value.
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?
No output schema exists, and the description says the return format differs from fetch without describing it, which is a minor gap. However, for a deprecated shim whose primary purpose is to redirect agents to fetch, the essential information is present.
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 url parameter, and the schema already explains that URLs or paths (including Japanese) are accepted. The description adds nothing about parameter handling, 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 states a specific action (returns the page body) and explicitly frames the tool as the legacy/previous name of a page-reading function, with the site host named. It distinguishes itself from the sibling fetch by noting the return format differs, though it never spells out what that format actually is.
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 plainly when to use it versus the alternative: it is retained only for existing connections, and new usage should call fetch instead. The condition selecting the sibling is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「オンライン学習 講座 生成AI IT 資格講座」（instant.aigakushu.online）で読み込んだページの一覧を、タイトルと 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 readOnly, non-destructive and closed-world. The description adds useful behavior beyond that: returns title+URL pairs, paginates 50 at a time, and continuation is via offset. It does not state ordering or what happens past the last page, hence not 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?
Two sentences, front-loaded with what is returned and the pagination contract, then the usage cue. No filler and nothing repeated from structured fields.
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 read-only list tool with no output schema, the definition covers return content, page size, cap and continuation. Ordering and end-of-list behavior are unstated, which is a minor gap but not one an agent needs to call it correctly.
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 burden, and it does explain both parameters: 'limit で最大 200 件' and '続きは offset で取れます'. It does not restate types or the minimum bounds, but the semantics of each parameter are conveyed, compensating for the empty schema descriptions.
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 ('読み込んだページの一覧を、タイトルと URL で返します') plus the concrete site scope (instant.aigakushu.online). An agent can tell this is a paginated listing tool, but it never explicitly distinguishes itself from sibling listing/search tools like search_pages or 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?
Gives clear situational guidance: use it when you want to know what pages exist, or when a search fails to find something ('探しても見つからないときに使います'). No alternatives are named by name, but the fallback-after-failed-search condition is meaningful routing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「オンライン学習 講座 生成AI IT 資格講座」（instant.aigakushu.online）から読み込んだページの中を言葉で探し、当てはまる箇所を抜粋と URL つきで返します。オンライン学習 講座 生成AI IT 資格講座 について質問されたら、まずこれを使ってください。探せるのは読み込んだページだけで、ネット全体や、読み込んだあとの更新は含みません。見つからないときは、略語を正式な名前にする、同じ意味の別の言葉にするなど、言い方を変えて探し直してください。それでも見つからなければ推測で答えず、このサイトには書かれていないと伝えてください。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 探したい言葉（例: 料金 支払い方法） |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/non-destructive/non-open-world, so the safety profile is covered. The description adds genuinely useful behavior: the search corpus is only the already-loaded pages, excludes the wider internet, and excludes post-load updates, plus the explicit no-guessing fallback. It stops short of describing result ordering or matching semantics.
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 scope are front-loaded, and the later sentences about fallback behavior each carry instructions the agent needs. It is somewhat long for a one-parameter search tool, though nothing is purely redundant.
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 an output schema present, return values need no explanation, and the description covers scope limits, corpus freshness, and failure handling for a simple keyword search. The remaining gap is that it never relates itself to its five siblings, particularly the near-namesake `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 carries the semantics and the baseline of 3 applies. The description adds only a rephrasing strategy (expand abbreviations, try synonyms), which is guidance about querying rather than new meaning for the parameter itself.
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 (探す/search), resource (読み込んだページ/loaded pages from the named site), and return shape (抜粋と URL/excerpts with URLs), and it bounds the scope to the loaded pages of one site. What it never does is distinguish itself from the sibling `search_pages`, whose name suggests the same job.
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 when-to-use guidance (質問されたらまずこれを使ってください) plus a fallback procedure: rephrase with expanded abbreviations or synonyms, and if still absent, tell the user the site does not cover it rather than guessing. Strong, but it names no sibling alternative, so the agent cannot route between `search`, `search_pages` and `fetch`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「オンライン学習 講座 生成AI IT 資格講座」（instant.aigakushu.online）の以前の名前の機能です（すでにつないでいる人のために残しています）。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, so the safety profile is covered. The description adds meaningful behavioral context beyond the structured fields: this is a deprecated/legacy endpoint retained for backward compatibility, and its response format differs from the sibling 'search'. It does not detail the response shape or pagination, keeping it below 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 compact sentences, front-loaded with the legacy-identity context and then the alternative. No filler, and the key routing advice lands before any secondary detail. Slightly more identity framing than strictly necessary, but it earns its place for disambiguation.
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 2-parameter, read-only, no-output-schema tool with annotations covering safety, the description conveys purpose, legacy status, and the sibling alternative. It leaves the undocumented 'limit' parameter and the nature of the differing return format unaddressed, which are the remaining gaps for an agent calling it correctly.
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 only 50%: 'query' is documented in the schema, but 'limit' (default 5, max 20, min 1) has no description anywhere. The description does not compensate for this gap – it says nothing about parameters, so the agent must infer 'limit' behavior from the raw schema constraints alone.
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 (searches inside the site, like the sibling 'search' but with a different return shape) and clarifies that this is a legacy alias of the 'search' feature. An agent can distinguish it from 'search' without opening schemas. It stops short of a crisp standalone statement of what it does, since the 'former name' framing adds some ambiguity.
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 names the alternative ('新しく使うときは search を使ってください' – use 'search' for new usage) and gives the condition that selects it, plus the rationale for its continued existence (kept for already-connected users). This is exactly the when/when-not/alternative guidance the dimension rewards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
「オンライン学習 講座 生成AI IT 資格講座」（instant.aigakushu.online）がどんなサイトかを返します。種類・紹介文・読み込んだページ数・主なページが分かります。最初にサイトの全体像をつかみたいときに使います。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, non-destructive, closed-world read, so the safety burden is covered. The description adds real behavioral value by disclosing the payload an agent can expect (type, intro text, page count, main pages), which is meaningful because there is no output schema. It does not discuss paging, cost, or freshness, but the core disclosure is solid.
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 returned and closed with the usage cue. No filler or redundancy. It could be marginally tighter, but every clause carries 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 zero-parameter summary tool with annotations covering the safety profile and no output schema, the description supplies what an agent needs: the target site, the returned contents, and the when-to-use cue. Only the absence of sibling routing keeps it from being fully complete.
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 the baseline is 4. The description correctly implies a no-argument, whole-site call and introduces no parameter terminology that could confuse the agent.
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?
Names a concrete resource (the site instant.aigakushu.online) and enumerates what is returned: site type, description text, number of pages loaded, and main pages. This is more than a restatement of the name. It does not explicitly contrast itself with siblings like list_pages or get_page, which would be needed for 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?
Clearly states the trigger condition: 'use when you first want to grasp the overall picture of the site.' That gives the agent a concrete moment to reach for it. However, it names no alternatives or exclusions (e.g. when to prefer list_pages or search_pages instead), so it stops short of full routing 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_overviewオンラインインスタント学習は、資格試験や各種学習に役立つオンライン教材・学習コンテンツを提供するオンライン学…（online.instantgakushu.jp の内容を検索して答える。ヨミタス経由）
Search and read 550+ free AI course tracks and 21,000+ lessons, so answers can cite a real lesson.
SEO コンサルタントの柏崎剛が運営する、検索エンジン対策の情報サイトです。（tsuyoshikashiwazaki.jp の内容を検索して答える。ヨミタス経由）
株式会社一創（issoh.co.jp）の技術記事・サービス・制作実績を検索できる MCP サーバー。システム開発・AI・クラウド・Web 制作の日本語情報
Add one secure layer between your agents and this server.
