Skip to main content
Glama
systemsomicslab

ms-data-parser

curation_suggest

Generates ranked annotation candidates for spots flagged as wrong or left unannotated, returning a review TSV and HTML viewer for selecting and submitting curation decisions.

Instructions

キュレーションで「間違い」になったスポットと未注釈スポットに、注釈の候補を並べる (候補付けレビュー)。先に library_load と curation_review。

対象: wrong="flagged_or_likely"(既定)= wrong フラグ + 元レビューの likely_wrong、 "flagged" = wrong フラグだけ。unannotated=True で未注釈スポットも。判断済み (assign / redundant)のスポットは include_decided=True のときだけ含める。 元レビューは review_id(省略時はこのアラインメントの最新のレビュー)。 候補: ① MS-DIAL の下位候補、② 閾値を緩めた再検索(スコアの足切りなし)、 ④ 注釈付きの別スポットの同位体・アダクト・インソース断片としての説明。 スペクトル類似度で並べ、極性矛盾・|Δm/z| ≥ 10 mDa は削り、非典型アダクト・RT–m/z 傾向の外れ・ 一致ピーク 0 は順位を下げる。MS-DIAL の脂質規則は評価していない(鎖組成は保証しない)ので、 既定では和組成で記録する。 戻り値は 1 スポット 1 行の TSV(強い説明のあるものが先、先頭 max_rows 行)・件数・html_path。 ユーザーには html_path をブラウザで開いてもらい、選んだ内容をビューアの 送信 で送ってもらう (記録と _tags.xml の反映はビューアが直接行う。submit.via == "viewer")。送信用テキストを 貼るよう頼まない。Copy のテキストが貼られたとき(受け口の時間切れ・submit.via == "copy")は curation_submit(submission_text=...) に渡す。 ユーザーの同意なしに curation_submit を呼ばない。

Input Schema

NameRequiredDescriptionDefault
top_nNo
wrongNoflagged_or_likely
max_rowsNo
file_pathNo
review_idNo
rt_windowNo
thresholdsNo
unannotatedNo
relation_min_rNo
include_decidedNo
relation_mz_tolNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

注釈は readOnlyHint=false 等を提供するが、説明はそれを超えて候補の生成元(MS-DIAL 下位候補・緩和再検索・同位体/アダクト説明)、極性矛盾や |Δm/z|≥10 mDa の除外、非典型アダクト等の順位低下、脂質規則未評価の注意、戻り値形式(TSV・件数・html_path)と送信フローまで開示している。

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?

長めだが「対象」「候補」「戻り値」と段落が分かれ、前提条件が冒頭に置かれている。太字で重要制約(先に library_load と curation_review、同意なき submit 禁止)が目立つ。やや情報量は多いが無駄な文は少ない。

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?

出力スキーマはないが、戻り値の形(1 スポット 1 行 TSV・件数・html_path)とビューア送信という後続フロー、脂質規則未評価の注意まで説明されており、複雑な 11 パラメータツールとして必要な情報はほぼ揃う。

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

Parameters3/5

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

schema の description カバレッジが 0% で 11 パラメータあるうち、wrong・unannotated・include_decided・review_id・max_rows については説明が意味を補っている。一方 top_n・file_path・rt_window・thresholds・relation_min_r・relation_mz_tol は説明も schema も沈黙しており、補完は不十分。

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?

「間違いになったスポットと未注釈スポットに注釈候補を並べる」と動詞+対象を具体的に述べ、curation_review や curation_submit との役割の違いも文脈から明確。何をするツールか一目で分かる。

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?

「先に library_load と curation_review」という前提条件、wrong/unannotated の使い分け、判断済みスポットの扱い、ビューア送信と curation_submit への引き渡し条件、同意なき submit 禁止まで明示されており、いつ使うか・どう進めるかが具体的。

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