Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

アノテーションが一切ないため、説明文が動作に関する負担をすべて負う。「取得します」は読み取り操作を示すが、認証の必要性、ネットワークアクセス、レート制限、エラー時（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?

「KEGG IDを指定して」という文が先頭で、資源が明確になっており、日本語として簡潔で1文のみで、無駄な言葉はない。パラメータの手順や代替手段の詳細を盛り込む必要性に欠ける、整った構造である。

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?

入力は低複雑度（必須パラメータ1つのみ）で、出力スキーマも存在するため、返却値の構造は自己記述的。ただし、記述にはツールのエラーの動作（「見つからない場合は0件や空を返す」）や外部依存（KEGG REST API、ネットワーク認証、レート制限など）については書かれておらず、これらは実行時には不明な点となる。

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?

入力スキーマは kegg_id（文字列）のみでカバレッジ0%。説明文は「KEGG IDを指定」とだけ述べており、スキーマの名前と同じで実質的な意味を追加していない。唯一の追加情報は「search_drugで得たkegg_idを渡してください」というメタ手順の指示で、データ形式やフォーマット、IDの由来は説明されていない。

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?

「KEGG IDを指定して医薬品の詳細（一般名・分類・標的・相互作用など）を取得します」は、具体的な動詞「取得」とリソース「医薬品詳細」、および一意の識別子「KEGG ID」を明示しており、ツールの目的は明確。姉妹ツール search_drug はリスト取得用であることが「search_drugで得たkegg_idを渡してください」の記述から差別化されている。

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?

「search_drugで得たkegg_idを渡してください」という記述が、直近の検索フローからのIDを渡すワークフローを示しており、使用タイミングは暗黙に示されている。ただし、代替案や不使用条件は明示されていないものの、このワークフローの示唆は十分に明確である。

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden and does well: it states the abstract is returned verbatim with no summarization/translation/interpretation, and that structured abstracts are split by section. It does not cover failure modes or edge cases such as missing abstracts, but the core behavior is transparent.

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, each adding distinct information: retrieval scope, verbatim behavior, and structured-abstract handling. No filler or 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 simple fetch-by-ID tool with an output schema available, the description covers the main behavioral facts and return characteristics. It lacks guidance on invalid/missing PMIDs or array size behavior, but those are minor against an otherwise complete picture.

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 0%, and the description only minimally compensates by saying 'specify PMID'. It does not clarify that pmids accepts an array, what counts as a valid PMID, or any limits; however, the single parameter's name and type are semantically obvious.

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 specific verb ('取得します') and resource ('抄録の全文と書誌情報') keyed to PMIDs, making the operation concrete. It is clearly distinct from sibling search_pubmed, which searches rather than fetches by ID.

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 implies the tool is for when PMIDs are already known, but it does not explicitly state that search_pubmed should be used to discover PMIDs or exclude alternative retrieval paths. Usage context is only inferred, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals an important limitation: Minds search results are rendered in-browser and cannot be mechanically retrieved, so only a URL is provided. It also states the output structure (PubMed results and a Minds URL). This goes beyond what an agent could infer from the schema.

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 a single, well-structured sentence with two clauses that convey purpose, method, and a key limitation. Every phrase earns its place, and the limitation about Minds is essential behavioral context. Slightly more could be said about parameters, but that is a completeness concern, not a conciseness issue.

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?

While an output schema exists (relieving the need to describe return values), the description omits parameter usage details (limit, year_from) and any differentiation from sibling tools. Given the tool's moderate complexity (3 parameters, one required) and the lack of annotations, this is a notable gap. The description covers the core purpose and one behavior limitation, but not enough for confident 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 schema has no parameter descriptions (0% coverage), so the description must compensate. It addresses 'topic' implicitly ('あるトピック') but does not explain 'limit' (default 20) or 'year_from' (nullable) at all. Two of three parameters lack semantic meaning beyond their names and types, leaving agents to guess their effect.

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 tool's purpose: finding clinical practice guidelines for a topic. It specifies the resource (PubMed with guideline[pt] filter) and the Minds guideline library, and mentions the output is results plus a URL. This differentiates it from siblings like search_pubmed, which likely handles general PubMed searches, even though no explicit comparison is made.

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 does not provide explicit guidance on when to use this tool versus alternatives. It does not reference sibling tools such as search_pubmed or fetch_drug_entry, nor does it state conditions or exclusions. The purpose implies use for guideline searches, but the usage context is not articulated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It states the primary effect (fetch and import) and the one-time nature, but fails to disclose the 'force' parameter semantics, whether imports overwrite existing data, potential network/time requirements, or any side effects on the local DB. This is a significant transparency gap for a mutating operation.

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, three short sentences, with the main action front-loaded, followed by a clear usage hint, then a compact parameter list. Every sentence contributes value, and there is 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?

Given the tool is simple (2 params, output schema exists), the description covers the core purpose, the one-time setup role, and kind values, which is adequate for basic invocation. However, it omits the force semantics, explicit guidance on when to use versus alternatives, and any prerequisites like network access, leaving gaps that an agent would need to infer.

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 compensate. It explains 'kind' with its three enum values (shinryo, iyakuhin, tokutei) and their meanings, but it does not describe the 'force' parameter at all. Half of the parameters are left unexplained, and the description only partially compensates for the missing 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?

The description clearly states the tool retrieves the official master from the medical fee information service and imports it into the local DB, with a specific verb and resource. It also differentiates from search siblings by explicitly noting it is a one-time setup action and that subsequent searches work offline, making 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 provides clear usage context: '初回のみ実行が必要' (needs to be executed only once initially) and states that subsequent searches work offline, implying it should be run before using search tools. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of fully explicit routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden, yet it only states the basic search-and-filter function. It doesn't describe behavior of the 'limit' parameter, pagination, whether it's a live external API call, failure modes, or the result-set behavior — all significant for a tool with a default limit and externally sourced 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 short sentences in Japanese with zero waste: function first, filter dimensions second, use cases last. Every sentence earns its place and the structure is front-loaded with the core action. Appropriately sized for a search tool.

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 values don't need explanation. The description adequately covers the tool's purpose and main filter dimensions, but gaps remain: 'term' and 'limit' semantics are undocumented, and the accepted values for phase/status are unspecified. Adequate for a filtered search tool, but not exhaustive.

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%, placing the full burden on the description. It does map five of the seven parameters to filter dimensions (condition, intervention, status, phase, country), but it omits 'term' and 'limit' and provides no acceptable value formats for phase/status. With no enums in the schema either, an agent has no concrete guidance for populating those fields.

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+resource ('searches ClinicalTrials.gov') and lists its filtering dimensions (disease, intervention, status, phase, country). It also gives concrete use cases — checking ongoing trials and a drug's development stage. It doesn't name siblings explicitly, but the resource and use cases clearly mark it as the clinical-trial search tool among the drug/pubmed/guideline siblings.

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 explicitly states when to use it ('to check ongoing trials and at what stage a drug is at'), providing clear usage context. However, it offers no exclusions and doesn't name alternatives like search_drug or search_pubmed, so an agent must infer the boundary between this and related search tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses a key behavioral trait: the tool does not return package insert full text but includes a PMDA search URL instead. It also reveals the data source (KEGG DRUG) and the ability to return JP listing status and brand names. This goes beyond simple action framing.

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 two sentences in Japanese, front-loading the primary action and then adding a crucial limitation (PMDA URL). Every sentence contributes meaningful information with no redundancy or 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 search tool with two simple parameters and an output schema, the description covers the essential aspects: what is searched, the data source, and a notable limitation. It does not detail the expected output structure, but the output schema likely handles that. Minor gaps like parameter usage for 'limit' are understandable.

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 has zero description coverage, so the description must compensate. It explains that the search term can be a generic or brand name, which directly clarifies the 'term' parameter. However, it does not address the 'limit' parameter; its meaning is only inferable from the default value. Since one of two parameters is clarified, this partially compensates.

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 tool's function: searching for drugs by generic or brand name, backed by the KEGG DRUG database. It also specifies additional capabilities (Japanese Pharmacopoeia status, brand names) and names the data source, making it distinct from sibling tools like search_pubmed or find_guideline.

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 implicitly establishes when to use this tool (for drug name lookups) and provides a clear limitation: full package insert text is not provided; instead, a search URL to PMDA is returned. This effectively tells the agent that for full text, it should consult PMDA directly, but it does not explicitly name alternative sibling tools or state exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It states that results include source URL and acquisition datetime, and implies that full abstracts are NOT returned by directing to fetch_pubmed_abstract. This is useful behavioral context. It doesn't mention rate limits or pagination, but these are less critical for a search tool and may be covered by the output schema.

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 short sentences, each adding value. The purpose is front-loaded, the filtering options are summarized, and the follow-up action is clearly stated. There is no redundant or filler language.

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?

Given the tool's complexity (9 parameters, 1 required) and the presence of an output schema, the description covers the essential information: purpose, key filtering capabilities, and a usage hint for abstracts. It doesn't explain every parameter or edge case, but the schema and output schema likely cover return details. Overall, it is sufficiently complete for an agent 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 compensate. It lists the conceptual filter dimensions (keyword, author, journal, year, study design), which maps to most parameters. However, it doesn't mention sort, limit, or free_full_text, though those are somewhat self-evident. The high-level mapping is helpful but not exhaustive, leaving some parameter details to the schema names and defaults.

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 tool performs a search over PubMed and returns a list of bibliographic information. It uses a specific verb ('search'), a specific resource ('PubMed'), and an explicit outcome, which distinguishes it from sibling tools like search_clinical_trials and search_drug. It also names fetch_pubmed_abstract as a follow-up, reinforcing its role as the search step.

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 instructs when to call fetch_pubmed_abstract next, providing a clear workflow. While it doesn't explicitly say when NOT to use other search tools, the focus on PubMed and the mention of abstract retrieval as a separate step is enough to guide usage. It could be improved by explicitly naming alternative search tools, but the main alternative is covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the behavioral disclosure burden. It discloses two relevant behaviors: it works offline (no network) and it attaches the included file name to results to indicate version due to fee revisions. It does not mention error handling, pagination, or the prerequisite that the master must be imported, though the latter is implied. Given the absence of annotations, a score of 3 is appropriate—it reveals some key traits but leaves gaps.

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 short Japanese sentences, each contributing a distinct fact: purpose, offline availability, and result metadata. It is front-loaded with the core purpose and does not contain fluff. It could be slightly more structured (e.g., listing parameters), but it is appropriately concise for its length.

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 leaves out essential context for correct invocation. It does not explain what each 'kind' value means, which is critical for selecting the right search scope. It also doesn't clarify that data must be imported first (though '取り込み済み' implies it) and doesn't reference the sibling shinryo_master_status for checking readiness. The output schema exists, so return value structure is likely covered, but the missing parameter semantics and prerequisite context make this incomplete for an agent.

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 compensate. It explains that the 'term' parameter can be a name, kana, or code, which adds value. However, it does not explain the 'kind' parameter (shinryo, iyakuhin, tokutei) or the 'limit' parameter beyond their schema defaults. The enum values are left undefined, and no examples are given, leaving the agent to infer their meaning. Partial coverage only, hence a low score.

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 verb 'search' and the resource 'ingested medical fee master', and specifies search criteria (name, kana, code). It also notes offline operation, which helps differentiate it from network-dependent search alternatives like search_drug. However, it doesn't explicitly name sibling tools or clarify that it covers both medical fees and drug prices (though the title implies this), so it stops short of a perfect 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 provides no explicit when-to-use or when-not-to-use guidance. It mentions offline capability and that results include a file name, but does not indicate when to prefer this over sibling tools like search_drug or fetch_drug_entry. The context that data must be ingested is only implicit via '取り込み済み' (ingested).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations were provided, so the description carries the full disclosure burden. It discloses that the tool is a read-style status query returning a list with publication dates, which is implicitly non-mutating. However, it does not explicitly state read-only behavior, permissions needed, or any quirks about the returned data. The behavior described is minimal but consistent with the tool's apparent nature.

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?

A single, tight sentence that states the purpose and return content with zero wasted words. The key information (returns locally-imported master list and publication dates) is front-loaded and immediately actionable.

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 and the tool has no parameters, so the description need not explain return values or arguments in depth. For a simple status-query tool this is largely sufficient. The only minor gap is not mentioning the expected pattern of pairing with import_shinryo_master, but for a zero-parameter read tool this is a small omission.

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 schema coverage is trivially 100%, so there is nothing for the description to add about argument semantics. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on the return value instead of parameters.

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 ('返します' - returns) and resource (診療報酬マスターの一覧), scoped to locally-imported masters with their publication dates. It implicitly distinguishes itself from siblings like import_shinryo_master (which imports) and search_shinryo_hoshu (which searches billing codes), since this tool reports ingestion status rather than performing those actions.

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?

No guidance is given for when to use this tool versus alternatives. The natural counterpart, import_shinryo_master, is a sibling but the description never points to it or explains that this tool is for verifying what has been ingested before importing/searching. Usage context is only implied, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.