Parses MS-DIAL .arf2 catalog files and returns summary metadata on dataset quality and annotation coverage for overview assessment.
.arf2 ファイル（MS-DIALの全体カタログ）を解析し、データセットの全体像（メタデータ）を要約して返します。 このファイルにはサンプル個別の強度データは含まれていないため、PCA等の多変量解析は実行できません。 データ全体の品質や、アノテーション状況の概観を把握するために使用します。
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation covers safety and the description is consistent with it, while adding real behavioral context beyond the annotations: the file contains no per-sample intensity data, so multivariate analysis is impossible, and the return is a metadata summary. It does not describe output shape or failure modes for unreadable paths, which keeps it from 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 short sentences, each earning its place: what it does, what it cannot do, and when to reach for it. The capability statement is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must say something about returns, and it does (dataset overview/metadata summary). Combined with the explicit limitation warning, an agent has enough to call it correctly; only the null/unset file_path case 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?
There is one parameter (file_path) with 0% schema description coverage, so the description must carry the burden. It does imply the path must point to a specific .arf2 MS-DIAL catalogue file, which is meaningful, but it never explicitly ties this constraint to the file_path argument or discusses optionality (the param is not required and defaults to null).
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 (.arf2 file, MS-DIAL全体カタログ), and states what the output is: dataset overview metadata. It does not explicitly distinguish itself from the similarly-named sibling arf_parser, which an agent would likely confuse it with, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a positive use case (把握するために使用します for overall quality and annotation status) and an explicit when-not: PCA and other multivariate analyses cannot be done with this file. It stops short of naming the alternative tool (e.g. arf_pca_* / arf_parser), so routing between siblings is still partly left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.