Skip to main content
Glama
systemsomicslab

ms-data-parser

dataset_feature_search

Read-only

Search dataset features by feature ID, m/z, or retention time, or match target compounds by InChIKey and adduct rules to resolve annotated candidates (read-only).

Instructions

DatasetState の特徴を探し、目的の物質に当たる特徴を規則で判定する(読み取り専用)。

2 つの使い方があり、targets の有無で切り替わる(同時指定は DATASET_BAD_REQUEST)。

窓検索(targets なし): feature_ids(SMF_ID の完全一致)・min_mz/max_mz・ min_rt/max_rt(分)の AND。境界を含む。何も指定しなければ FEATURE_SEARCH_EMPTY_QUERY (全件を返さない)。feature_ids=[] は「どの ID でもない」条件で 0 件。並びは m/z 昇順。 戻り値 features は TSV(feature_id mz rt evidence name inchikey adduct n_sme。 evidence は sme/sml/none)。注釈の無い特徴にも統計を付ける。

目標照合(targets あり、1 回 50 件まで): 各要素は target_id・inchikey(必須。 先頭 14 文字で照合)と、formula か(expected_mz と adduct)。任意で name ppm (既定 10)rt_min rt_tol_min(既定 0.3)adduct_tiers polarity。付加体の層を上から、 証拠の水準 sme_match → sml_match → unannotated の順に見て、qualified がちょうど 1 つの ときだけ resolved。2 つ以上なら needs_input(multiple_qualified_candidates)、無ければ needs_input(no_qualified_candidate)。強度・ppm・RT の近さでは選ばない。 unannotated は rt_min があるときだけ qualified。SME(MS/MS 同定)が別物質なら落とす。 極性はジョブの宣言 → mzTab-M の付加体の多数決の順に決め、rule.polarity_source に書く。 目標の極性は polarity、省けば明示した付加体(adduct/adduct_tiers)の符号で、 データセットと違う目標は not_applicable(陽陰が混ざる付加体は FEATURE_TARGET_INVALID)。 戻り値 targets(目標ごとの判定と段ごとの件数)・candidates(TSV。目標ごとに max_results 件まで)・rule(正規化した規則と rule_hash。result_id・表示名 name・ 目標の並び順を含まないので、同じ目標・同じ極性なら別の session でも同じ hash)。hash は表示用の丸め(理論 m/z を 4 桁に)より前の値から作るので、返された rule.targets から計算し直すことはできない ——照合は rule_hash の値どうしで行う。

result_ids: 統計を付ける 2 群比較(dataset_differential)の結果。省略時は今も有効な 2 群比較の全部(古いものは使わず notes に挙げる)。名指しした ID が無い・古いときは missing_state。差次的結果が 1 件も無ければ統計なしで返す。 max_results: 窓検索の行数・目標ごとの候補数の上限(既定 20)。打ち切りは notes に書く。

stats は TSV(feature_id result_id status log2fc p q mean_a mean_b detected_a detected_b)。 status は tested / not_in_matrix(前処理で落ちた)/ not_testable(p が無い)で、 後の 2 つは数値欄が空(「差が無かった」ではない)。detected_* は群ごとの実検出例数 (gap-fill を数えない。検出状態が無ければ空)。results に BH の母集団 (bh_population)と caveat。キュレーションのフラグは反映しない(あれば notes)。 欄の意味は lipidmix://docs/output-format/mztab。

Input Schema

NameRequiredDescriptionDefault
max_mzNo
max_rtNo
min_mzNo
min_rtNo
targetsNo
result_idsNo
feature_idsNo
max_resultsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

readOnlyHint already covers the safety profile, but the description adds substantial behavioral detail beyond it: qualification ordering (adduct tiers, sme_match → sml_match → unannotated), the rule that exactly one qualified candidate is required and that intensity/ppm/RT proximity are NOT used for selection, polarity resolution order with rule.polarity_source, and the rule_hash normalization caveat. Recording these in the description rather than annotations means non-DB-reading agents cannot rely on them, and the two modes' error/omission behavior (notes, missing_state) is fully described, so 4 rather than higher.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is long, but the length buys real information: purpose first, then the two modes under bold headings, then parameter notes. A few clauses (recomputing rule_hash, display-rounding of theoretical m/z) are dense but justified because they prevent a specific misuse; nothing is pure filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description specifies return shapes in detail: features TSV columns with the evidence enum, targets/candidates/rule with rule_hash, and stats TSV columns with status semantics (not_in_matrix/not_testable are not 'no difference'), detected_* definition, and results containing bh_population plus caveat. It even points to a docs resource for field meanings, which is all an agent needs to call and interpret this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the whole burden and does: it defines feature_ids as SMF_ID exact match (with empty-list semantics), min/max mz and rt as inclusive AND bounds, max_results default 20 with truncation in notes, result_ids as differential groups with defaults and staleness handling, and the nested `targets` object field-by-field including required fields, inchikey 14-char prefix matching, ppm default 10 and rt_tol_min default 0.3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (search features in DatasetState, rule-based judgment against target compounds) and immediately declares the read-only nature. The two operating modes are named and separated, so an agent can tell it apart from siblings like dataset_statistic or library_match_feature without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states that mode selection is driven by the presence of `targets`, that combining modes yields DATASET_BAD_REQUEST, and describes each mode's own preconditions (empty query → FEATURE_SEARCH_EMPTY_QUERY, >50 targets, polarity conflicts → FEATURE_TARGET_INVALID). It also says what happens when result_ids are missing or stale (missing_state).

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