Skip to main content
Glama
Sign In
systemsomicslab

ms-data-parser

by systemsomicslab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

console_run

Run MS-DIAL Console analysis jobs from a prepared JSON file, and detach long runs to avoid blocking the caller while results are finalized.

Instructions

MS-DIAL Console を実行します。

job_path: analysis-job.json へのパス。省略時は session.current_job_path を使用します。 事前に console_plan を実行しておく必要があります。

detach: True にすると監視ワーカーを親から切り離して起動し、待たずに戻ります。 実データ 60 サンプルは約 44 分かかるため、既定の同期実行では 1 ツール 呼び出しがその間ずっと戻らず、呼び出し元が中断されると生成物ごと失います。 長い実行ではこちらを使ってください。

返る `pid` は**監視ワーカーのもの**で、MS-DIAL Console のものではありません
（Console の pid は run_dir の execution-result.json に載ります）。ワーカーが
終了まで見張り、生成物の収集とジョブの確定まで行うので、`console_status` を
呼ばなくても結果は確定します。

どちらの経路でも run_dir に終了証跡（execution-result.json）が残ります。 終了コードが 0 でも、主 mzTab-M が一意に選べ、定量行列に有限値があり、予定した 入力が全て assay に対応していなければ completed にはなりません（partial / failed）。

実行完了後、session.current_job_path は同じジョブを指し続けます。 結果は console_status または dataset_load で確認してください。

Input Schema

NameRequiredDescriptionDefault
detachNo
job_pathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes far beyond the annotations: it discloses that detach returns immediately with a worker pid (not the Console pid), that the worker also collects artifacts and finalizes the job, that execution-result.json is always written to run_dir, and that exit code 0 alone does not mean completed (partial/failed criteria are named). It also notes session.current_job_path persists after the run.

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?

The lead sentence is front-loaded and the content is dense and necessary, but the detach section is verbose with bold emphasis and the pid/worker explanation is extended. Nearly every sentence earns its place, though the layout could be tighter.

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?

No output schema exists, so the description must cover return semantics — it explains the returned pid, the run_dir execution-result.json artifact, the completion criteria (unique main mzTab-M, finite values in the quantification matrix, all planned inputs mapped to assays), and where to read results. Nothing an agent needs to call this correctly is missing.

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 description carries the full burden — and it does. job_path is defined as the path to analysis-job.json with a stated default (session.current_job_path), and detach is defined behaviorally (detached worker, no wait, pid semantics) rather than just as a boolean.

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 ('MS-DIAL Console を実行します') and immediately anchors it in the workflow by requiring console_plan beforehand. This makes it clearly distinguishable from console_plan, console_status, and console_cleanup.

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 says console_plan must be run first, gives a concrete rule for choosing detach=True (60 samples ≈ 44 min, sync calls can be interrupted and lose artifacts), and directs to console_status or dataset_load to check results. The when/when-not conditions are spelled out.

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

Deploy Server

Other Tools