Jean by Melad Labs

infer_proteins

Read-only

Protein inference from peptide-spectrum matches (validated against OpenMS BasicProteinInferenceAlgorithm on PXD000001): maps each peptide to the protein database, keeps the best match per spectrum, scores each protein by aggregating its peptides' best scores, reports the proteins its evidence cannot tell apart as indistinguishable groups, and the percent of each sequence the matches cover.

Input Schema

Name	Required	Description	Default
`psms`	Yes	the matches as a table with a header row naming spectrum, peptide, charge and score (tab- or comma-separated); peptides are ProForma.
`_files`	No	The project: record references shaped like _subject. Their records become library documents a tool names in sequences/parts/document; a trace or alignment is found by file name.
`_subject`	No	The record to act on: exactly one of sequence, accession (+source), sample (an id from list_samples) or file ({name, text} or {name, base64}); record_index picks one record of several.
`database`	Yes	the protein database searched, as FASTA; the accession is the header up to the first space.
`coverageOf`	No	the accession whose sequence coverage is drawn; empty draws the first protein of the best group, as the Coverage tab opens on.
`aggregation`	No	how a protein's peptide scores combine: best one, mean (sum over count), or product.	best
`minPeptides`	No	report only proteins with at least this many evidences (0 reports every matched protein).
`scoreColumn`	No	which column holds the score inference uses, when the table carries several (OpenMS score_type); a column named pep or q-value sets its own direction.	score
`ilEquivalent`	No	treat isoleucine and leucine (and a database J) as the same residue when mapping peptides.
`scoresArePep`	No	the scores are posterior error probabilities: matches compete lowest first, and each protein combines 1 − PEP into a posterior probability (higher is better); implies higherIsBetter false.
`higherIsBetter`	No	true for scores like HyperScore; false for e-values, q-values and PEPs.
`useSharedPeptides`	No	let a peptide that maps to several proteins count for each of them.
`maxAmbiguousResidues`	No	how many ambiguous database residues (B, J, Z, X) one peptide match may resolve.
`greedyGroupResolution`	No	razor peptides: give each shared peptide only to its best-scoring protein or group (ties to the one with more matches) and drop proteins left with no peptide of their own.
`chargeVariantsSeparate`	No	count each charge state of a peptide as its own evidence.
`peptideProteinResolution`	No	resolve shared peptides between indistinguishable groups: in each connected set of groups the highest-probability group (then the one with more peptides) takes its peptides from the rest, and each set is reported as an ambiguity group; not combined with greedyGroupResolution.
`modificationVariantsSeparate`	No	count each modified form of a peptide as its own evidence.

Output Schema

Name	Required	Description
`count`	Yes	proteins reported
`groups`	Yes	indistinguishable protein groups, best first: probability (the best member score) and accessions
`method`	Yes	the inference algorithm and mapping that produced these proteins, named
`proteins`	Yes	one row per protein: accession, score, evidences counted, sequence coverage (%)
`coverageMap`	Yes	one protein's sequence with the peptides that identified it laid under the residues they cover, unique in blue and shared in orange: the Coverage tab's picture of `coverageOf`
`scoreColumn`	Yes	the column the match scores were read from, which decides whether higher or lower is better
`ambiguityGroups`	Yes	with peptide–protein resolution: one group per connected set of groups, best group first, with the best probability. Null when that resolution was not asked for, because an empty list would read as a dataset with no ambiguity in it

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 23, 2026

addedInput schema / properties / coverageOf

Added value: +{
+  "default": "",
+  "description": "the accession whose sequence coverage is drawn; empty draws the first protein of the best group, as the Coverage tab opens on.",
+  "type": "string"
+}

addedOutput schema / properties / coverageMap

Added value: +{
+  "description": "one protein's sequence with the peptides that identified it laid under the residues they cover, unique in blue and shared in orange: the Coverage tab's picture of `coverageOf`",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "proteins",
-  "groups",
-  "ambiguityGroups",
-  "count",
-  "scoreColumn",
-  "method"
-]New value: +[
+  "proteins",
+  "groups",
+  "ambiguityGroups",
+  "count",
+  "scoreColumn",
+  "method",
+  "coverageMap"
+]

Changed3 schema fields changedOct 21, 2026

addedOutput schema / properties / method

Added value: +{
+  "description": "the inference algorithm and mapping that produced these proteins, named",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / scoreColumn

Added value: +{
+  "description": "the column the match scores were read from, which decides whether higher or lower is better",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "proteins",
-  "groups",
-  "ambiguityGroups",
-  "count"
-]New value: +[
+  "proteins",
+  "groups",
+  "ambiguityGroups",
+  "count",
+  "scoreColumn",
+  "method"
+]

First observedOct 20, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the exact algorithm validated against OpenMS BasicProteinInferenceAlgorithm on PXD000001, the best-match-per-spectrum rule, and that results include indistinguishable groups and per-sequence coverage. It does not disclose output shape beyond that or any computational cost/ordering concerns, so it sits at adequate rather than rich.

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?

A single dense sentence, but it is front-loaded with the purpose before the pipeline details, so the agent gets the core identity immediately. It is long yet every clause adds substantive algorithm information; no filler or restatement of the name.

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?

With 17 parameters, an output schema, and full schema coverage, the description supplies the necessary mental model: inputs (PSMs + FASTA database), processing rules, and what the report contains (indistinguishable groups, coverage). The one missing piece for an agent choosing correctly is differentiation from bayesian_protein_inference, which is a real but bounded gap given how rich the structured metadata already is.

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 coverage is 100%, so the 17 parameters are fully documented in structured fields and the baseline of 3 applies. The description only loosely reinforces one of them ('aggregating its peptides' best scores'), which describes the default aggregation mode rather than adding semantics beyond the schema; the many tuning flags (greedyGroupResolution, peptideProteinResolution, ilEquivalent, etc.) are left entirely to the schema.

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

Purpose4/5

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

The description names a specific verb and resource ('Protein inference from peptide-spectrum matches') and enumerates the concrete steps: peptide-to-protein mapping, best match per spectrum, score aggregation, indistinguishable groups, and coverage. It is clear what the tool does, but it never acknowledges the sibling bayesian_protein_inference, so an agent cannot fully disambiguate the two inference tools from the description alone.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative (bayesian_protein_inference) that shares the protein-inference purpose. Usage is only implied by the phrase 'protein inference from peptide-spectrum matches', leaving the agent to infer selection criteria from the schema.

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

All Jean by Melad Labs tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?