AI学習・オンライン教材を提供する「インスタント学習」は、資格試験・検定試験・ビジネススキルなどの学習を、イ…（instant.aigakushu.online の内容を検索して答える。ヨミタス経由）
Scored across 6 tools
Two pairs of tools (fetch/get_page and search/search_pages) are functionally identical with only different return formats, creating clear overlap. The descriptions state that get_page and search_pages are legacy and should be replaced by fetch and search, which helps, but an agent could still misselect if not reading carefully.
Names mix single verbs (fetch, search), verb_noun patterns (get_page, list_pages, search_pages), and a noun phrase (site_overview). While all use snake_case and are readable, the inconsistent verb styles and presence of legacy names reduce predictability.
Six tools is reasonable for a read-only website browsing and search server, falling within the ideal 3-15 range. However, two of the six are deprecated duplicates, so the effective tool set is smaller and slightly bloated with legacy entries.
The server covers the essential read-only workflows: site overview, page listing, full-text search, and full page retrieval. Minor gaps exist, such as no direct tool to fetch page metadata or navigate site structure beyond the overview, but these are workable around.
「オンライン学習 講座 生成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 | |
| candidates | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description consistently adds scope detail: only loaded pages are searched, the live internet and post-load updates are excluded, and results come back as excerpts with URLs. This reinforces the closed-world read profile with useful context rather than contradicting it.
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?
Purpose is front-loaded and each subsequent sentence (scope limits, fallback behavior, failure protocol) carries operational value. It runs a bit long for a one-parameter search tool, but nothing is redundant 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?
Because an output schema exists, return-value details need not be restated, and the description is otherwise complete for a search tool: scope, behavior, and failure handling are all covered. The one missing piece is any distinction from the very similar 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 coverage is 100% with a single query param, so the baseline is 3. The description goes further by advising how to formulate and reformulate the query (formal names for abbreviations, synonyms), which adds real meaning for how to set this parameter beyond the schema's single example.
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 within pages loaded from the site) and what it returns (excerpts with URLs), so the operation is unmistakable. The main gap is that it never differentiates itself from the sibling search_pages, which sounds nearly identical, leaving selection between the two to inference.
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 explicit context ('when asked about the site, use this first') plus a concrete fallback loop: vary wording, expand abbreviations, then read returned page candidates, and never guess if still unfound. It does not name any alternative tool (e.g. search_pages, site_overview), so when-not-to-use-this is left implicit.
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.
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"
+}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.
XR（AR/VR/MR）に関する情報をメインに扱うサイトです。（orecen.com の内容を検索して答える。ヨミタス経由）
いざ貸すは、持ち家を貸したい方や、所有物件の賃貸管理を見直したい方のための賃貸管理一括査定サービスです。（izakasu.jp の内容を検索して答える。ヨミタス経由）
Add one secure layer between your agents and this server.
