Skip to main content
Glama
Sign In
systemsomicslab

ms-data-parser

by systemsomicslab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

eic_plot_compounds

Read-only

Overlay extracted ion chromatogram (EIC) traces for selected compounds in one sample and return a PNG image, so you can inspect co-elution directly without file output.

Instructions

Overlay several identified compounds' EIC traces for ONE sample — as a PNG image by default.

Read-only; writes no file.

output="image" (the default) renders the overlay server-side and returns it as an image block plus a one-line caption, so the figure appears directly in the chat. output="payload" instead returns the client-neutral lipidmix.eic.multi.v1 JSON for a client that draws its own interactive chart (Use-LLLM's Plotly view); the deployment default can be flipped with the LIPIDMIX_PLOT_OUTPUT environment variable. Prefer the image — one overlay's coordinate payload costs tens of thousands of tokens and an LLM cannot read a trace usefully.

One call plots one sample: file_id is required. To compare samples, call this tool once per sample and show the figures side by side. top_n caps how many compounds are overlaid (default 8: more than that is unreadable in one figure and multiplies the payload).

Compounds are selected from the ARF2 annotation: names matches ARF2 Name as a case-insensitive substring and ontologies matches ARF2 Ontology exactly (case-insensitive); the two results are unioned. At least one of them is required.

spot_id = AlignmentID is verified against the EIC spot RT and m/z, so a compound whose identity cannot be confirmed is not drawn. EIC files written by MS-DIAL before 2023-11-20 carry no spot m/z (-1); those spots borrow the ARF2 MassCenter after an RT check, and a caveat says so. Everything that was excluded — mismatch, missing trace, or falling outside top_n — is listed with its reason in selection.dropped; read it before concluding that a compound is absent from the sample.

Input Schema

NameRequiredDescriptionDefault
namesNo
titleNo
top_nNo
outputNo
file_idYes
arf2_pathNo
file_pathNo
normalizeNonone
ontologiesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well past the readOnlyHint annotation by disclosing that no file is written, that output can be flipped deployment-wide via LIPIDMIX_PLOT_OUTPUT, and that the coordinate payload costs tens of thousands of tokens. It also exposes verification semantics (spot_id checked against RT and m/z), the pre-2023-11-20 m/z=-1 fallback with a caveat, and the dropped-with-reason list.

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?

Front-loaded with the one-line what-it-does and the read-only guarantee, then grouped into output-format, per-sample, selection, and verification paragraphs. Dense but each paragraph carries distinct information; a few clauses (e.g. the token-cost justification) run longer than strictly necessary.

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

Completeness4/5

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

Given no output schema, the description does describe the return shape (image block plus one-line caption, or the lipidmix.eic.multi.v1 JSON) and the selection.dropped side channel. The remaining gap is the four undocumented optional parameters (title, normalize, arf2_path, file_path), which matter for an agent trying to steer the plot or point it at alternative inputs.

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?

With 0% schema description coverage the description must carry all 9 parameters, and it explains only the load-bearing ones: file_id, names (ARF2 Name substring, case-insensitive), ontologies (exact match, unioned with names), top_n (default 8), and output (image vs payload). title, arf2_path, file_path, and normalize are left completely undocumented in both schema and description.

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 ('Overlay several identified compounds' EIC traces') with a hard scope constraint ('for ONE sample'), and declares the default rendering explicitly. This distinguishes it from eic_plot_chromatograms and from cross-sample comparison work without the agent needing to open a 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?

Gives explicit routing rules: use output=image by default, use output=payload only for a client that draws its own chart, and call the tool once per sample to compare samples side by side. It also states the selection prerequisite ('At least one of them is required') and instructs the agent to read selection.dropped before concluding a compound is absent.

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