Jean — Molecular Biology & Genomics

enumerate_protonation_states

Read-only

Enumerate a small molecule's protonation states across a pH window with Dimorphite-DL (Ropp et al. 2019): each ionisable group it recognizes (substructures with pKa means and spreads taken from measured pKa values) is kept protonated, deprotonated or both, and every combination is returned as SMILES.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "molecule": "<molecule>"
    },
    "name": "enumerate_protonation_states"
  }
}

Input Schema

Name	Required	Description
`_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.
`ph_max`	No	upper end of the pH window.
`ph_min`	No	lower end of the pH window.
`_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.
`molecule`	Yes	the structure: SMILES or a molfile.
`precision`	No	how many standard deviations of each group's pKa widen its window, 0–10.
`max_variants`	No	stop enumerating past this many states (later groups are then not visited).

Output Schema

Name	Required	Description
`sites`	Yes	per ionisable site: Dimorphite name, SMARTS, each pKa (mean, stdev, state) and its atoms on the input (0-based, implicit hydrogens), or null when they do not map
`capped`	Yes	true when the enumeration stopped at max_variants
`states`	Yes	every protonation state as canonical SMILES, sorted
`summary`	Yes	the enumeration in words, generated from this run, with its caveats

Schema Changelog

Changes observed during successful MCP inspections.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real behavioural context: it discloses that every combination of per-group states is returned as SMILES and that only groups Dimorphite recognises are varied. It does not mention the combinatorial explosion risk or the truncation behaviour, which lives only in the max_variants schema description.

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?

One front-loaded sentence with the verb first; the parenthetical citation and the explanation of Dimorphite's pKa substructures are informative rather than pure filler. It is dense but not padded, and the key output ('returned as SMILES') lands at the end.

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?

An output schema exists and annotations cover safety, so the description only needs to explain the computation path. It does that adequately for a seven-parameter but single-required-argument tool; the generic _subject/_files parameters are left to the schema, which is reasonable.

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 coverage is 100%, so all seven parameters are documented, which sets the baseline at 3. The description's mention of 'pKa means and spreads taken from measured pKa values' gives useful conceptual grounding for the pH window and the precision parameter, but adds no syntax or default detail beyond 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?

States a specific verb and resource ('Enumerate a small molecule's protonation states') plus the method (Dimorphite-DL) and the output form (every combination as SMILES). It is clear what the tool produces, but it never distinguishes itself from neighbouring small-molecule tools such as canonical_tautomer, generate_conformers or assess_small_molecule.

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?

Mentions 'across a pH window' which hints at the use case, but gives no explicit when-to-use, when-not-to-use, or alternatives. An agent must infer that this is the tool for pH-dependent state enumeration rather than tautomer canonicalisation or conformer generation.

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?