CovaSyn Chemistry Tools

covnmr_verify

Does this NMR data match this structure (smiles, required)? Returns a verdict, the evidence it was read from, and per-atom assignments.

The data is ONE of: a spectrum file (`path`), a peak list (`peaks`, or its
JSON text `peaks_json`), or peak lists keyed by experiment (`experiments` /
`experiments_json`, e.g. {"1H": [...], "13C": [...]}). Absorbs the retired
covnmr_verify_peaks (the peak-list form) and the 1D form of covnmr_assign.
Multi-step: paste literature text into covnmr_parse_nmr_string first and
pass its `peaks` here.

READ `verdict` AND `evidence`, NOT `match_score`. `verdict` ("match" /
"possible match" / "inconclusive" / "no match") comes from decoy-calibrated
evidence (`evidence.z`, the share of the spectrum left unexplained, and
thresholds set on decoy structures in `evidence.verdict_calibration`).
`match_score` is coverage (`match_score_basis`) and decides nothing. A
structure with fewer predicted signals than any calibrated one gets
"inconclusive"; 19F and 31P have no error model, so on their own they are
always "inconclusive".

A peak list that declares its nucleus outranks `nucleus`; a list spanning
several nuclei is scored per nucleus (`per_nucleus`) and the combined
verdict is the most cautious of the nuclei that have an error model. 19F
and 31P are still scored but do not set that verdict
(`nuclei_not_in_verdict` says why). With `path` the file decides the
nucleus.

`peaks_json` may also be the whole answer of covnmr_parse_nmr_string
({"nucleus": ..., "peaks": [...]}); its nucleus counts as the list's own.

Combine 1H/13C with HRMS, from a file or a peak list: pass `hrms`, e.g.
{"formula": "C9H8O4", "mz": 181.0495, "adduct": "[M+H]+"}. The response
then lists each check in `evidence_checks` -- HRMS formula, HRMS mass
within `hrms_ppm_tolerance` ppm (default 10), the 1H integral sum against
the proton count, the 13C line count against the carbon count, and the
shifts -- and gives one answer in `verdict_combined`: a failed HRMS check
makes it "no match", a failed count check caps it at "inconclusive",
otherwise it is the shift verdict. `verdict` itself is unchanged. The count
checks run on a file too (from its integrals and picked lines).

Give `candidates` (up to 20 alternative SMILES) and `verdict_relative` says
whether this structure beats the best alternative. It may also say the
data cannot tell this structure from a regioisomer: then it is
"inconclusive" with `regioisomer_ambiguous: true`, and
`competing_candidate` names the regioisomer that is not ruled out. Omit
`tolerance_ppm` and the window follows the nucleus (1H 0.3 ppm, 13C 3.0).
For several spectra or 2D data of one compound use covnmr_sudoku.

Input Schema

Name	Required	Default
`hrms`	No
`path`	No
`peaks`	No
`smiles`	No
`api_key`	No
`nucleus`	No
`solvent`	No	CDCl3
`max_peaks`	No
`candidates`	No
`peaks_json`	No
`experiments`	No
`tolerance_ppm`	No
`max_unassigned`	No
`experiments_json`	No
`hrms_ppm_tolerance`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedNov 1, 2026

addedInput schema / properties / candidates

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Candidates"
+}

addedInput schema / properties / experiments

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Experiments"
+}

addedInput schema / properties / experiments_json

Added value: +{
+  "default": "",
+  "title": "Experiments Json",
+  "type": "string"
+}

addedInput schema / properties / hrms

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Hrms"
+}

addedInput schema / properties / hrms_ppm_tolerance

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Hrms Ppm Tolerance"
+}

addedInput schema / properties / max_peaks

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Max Peaks"
+}

addedInput schema / properties / max_unassigned

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Max Unassigned"
+}

addedInput schema / properties / path / default
```
Added value: +""
```

addedInput schema / properties / peaks

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Peaks"
+}

addedInput schema / properties / peaks_json

Added value: +{
+  "default": "",
+  "title": "Peaks Json",
+  "type": "string"
+}

addedInput schema / properties / smiles / default
```
Added value: +""
```

removedInput schema / required

Removed value: -[
-  "path",
-  "smiles"
-]

First observedOct 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it warns that `match_score` is coverage and 'decides nothing', that verdicts come from decoy-calibrated evidence, that 19F/31P have no error model and are always 'inconclusive' alone, and how `verdict_combined` is capped by failed HRMS/count checks. It also discloses the default ppm windows (1H 0.3, 13C 3.0) and the regioisomer-ambiguity outcome.

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 core question and the input-form menu before the interpretive detail, and each paragraph has a distinct job (inputs, verdict semantics, multi-nucleus, HRMS, candidates). It is dense and long at ~350 words, though nearly every sentence carries non-obvious behavioral information rather than filler.

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?

For a 15-parameter, annotation-free tool the description covers the decision-relevant surface: how to supply data, how the verdict is computed, HRMS combination logic, and candidate comparison. Gaps remain around max_peaks, max_unassigned, solvent, and api_key; the output schema being present means return-value enumeration is rightly omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 15 params, so the description must compensate and largely does: it explains smiles, path, peaks, peaks_json (which may be a whole covnmr_parse_nmr_string answer), experiments/experiments_json, nucleus precedence, hrms sub-fields, hrms_ppm_tolerance default (10), tolerance_ppm defaults, and candidates (up to 20). It leaves max_peaks, max_unassigned, solvent, and api_key unexplained, so not fully compensating.

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?

Opens with a specific question-form verb+resource: 'Does this NMR data match this structure', with `smiles` flagged as required. It also positions itself against siblings by naming covnmr_parse_nmr_string as a prerequisite step and covnmr_sudoku as the tool for multi-spectrum/2D cases, and notes it absorbs the retired covnmr_verify_peaks and the 1D form of covnmr_assign.

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?

Explicit routing: 'paste literature text into covnmr_parse_nmr_string first and pass its `peaks` here', and 'For several spectra or 2D data of one compound use covnmr_sudoku.' It also states which input form to pick (path vs peaks vs peaks_json vs experiments) and when to add `hrms` to combine 1H/13C with mass spec.

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

All CovaSyn Chemistry Tools 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.