jean — Molecular Biology & Genomics

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

TableJSON 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.
`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

TableJSON Schema

Name	Required	Description
`count`	Yes	proteins reported
`groups`	Yes	indistinguishable protein groups, best first: probability (the best member score) and accessions
`proteins`	Yes	one row per protein: accession, score, evidences counted, sequence coverage (%)
`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.

First observedOct 20, 2026

TDQS

A4/5.0

Behavior4/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 safety is covered. The description adds genuine behavioral context beyond that: it states that proteins its evidence cannot distinguish are reported as indistinguishable groups and that per-sequence coverage is computed, and cites a concrete validation target. It does not discuss runtime, memory, or input-size limits.

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 verb+resource and the validation anchor, then the algorithm steps in one dense but well-ordered sentence. Every clause describes actual behavior, though the single mega-sentence could be split for scannability.

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?

With an output schema present, the description need not explain return values; it instead covers the processing logic and the salient result concept (indistinguishable groups, coverage percent). Combined with 100% schema coverage, nested parameter objects, and full annotations, an agent has everything needed to call it correctly.

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% (including defaults and enum semantics for aggregation, scoreColumn, higherIsBetter), so the schema does the heavy lifting for all 16 parameters. The description adds no parameter-level detail beyond what is already documented, so the baseline of 3 applies.

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?

The description names a specific verb and resource (protein inference from PSMs) and spells out the pipeline it runs: peptide-to-protein mapping, best match per spectrum, per-protein score aggregation, indistinguishable groups, and percent coverage. It also anchors the method (OpenMS BasicProteinInferenceAlgorithm, PXD000001), which implicitly distinguishes it from the competing sibling bayesian_protein_inference. An agent can tell what this does 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 Guidelines3/5

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

The detailed algorithm description strongly implies the use case (you have PSMs plus a FASTA database and want protein-level inference), but there is no explicit when-to-use, prerequisites, or routing to alternatives such as bayesian_protein_inference. Usage is inferable rather than stated.

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

All jean — Molecular Biology & Genomics 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?