Skip to main content
Glama

CovaSyn Chemistry Tools

covnmr_sudoku

Assign every atom of a KNOWN molecule from several experiments at once (1H, 13C, APT, DEPT-135, DEPT-90, HSQC, HMBC, COSY), by constraint propagation across all of them.

Absorbs the retired covnmr_multi_analyze (`output="table"`: one row per
atom, per-experiment summaries, publication NMR strings, and the atoms
nothing could be assigned to with a reason) and the 2D form of
covnmr_assign (`paths_2d`: [{"experiment": "HSQC"|"HMBC"|"COSY",
"path": "<url>"}]). Default `output="assignments"` returns the solver's
assignment with `explanation`, which says why atoms stayed unassigned.

The carbon-edited slots say different things: an APT shows every carbon
and separates them by the PARITY of the proton count; a DEPT-135 shows only
protonated carbons (CH2 negative); a DEPT-90 shows CH only. Supply a
DEPT-135 together with a plain 13C whenever you have both: the quaternary
carbons come from the difference. The file decides which sequence it is --
a spectrum in the wrong slot is analysed as what it is and named in
`experiment_warnings`, as is every experiment that did not enter the
solve. `path` takes one 1D file whose own nucleus picks the slot.

Omit `tolerance_ppm` and each experiment gets its nucleus' window (1H 0.3
ppm, 13C 3.0). In the table, `sudoku_result.verdict` is the most cautious
of the per-nucleus verdicts; `match_score` is coverage and decides nothing.

Input Schema

NameRequiredDescriptionDefault
pathNo
outputNo
smilesYes
api_keyNo
path_1hNo
solventNoCDCl3
max_rowsNo
path_13cNo
path_aptNo
paths_2dNo
field_mhzNo
path_cosyNo
path_deptNo
path_hmbcNo
path_hsqcNo
path_dept90No
path_dept135No
tolerance_ppmNo
max_crosspeaksNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / field_mhz
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Field Mhz"
      +}
    • addedInput schema / properties / max_crosspeaks
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Max Crosspeaks"
      +}
    • addedInput schema / properties / max_rows
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Max Rows"
      +}
    • addedInput schema / properties / output
      Added value: +{
      +  "default": "",
      +  "title": "Output",
      +  "type": "string"
      +}
    • addedInput schema / properties / path
      Added value: +{
      +  "default": "",
      +  "title": "Path",
      +  "type": "string"
      +}
    • addedInput schema / properties / path_dept
      Added value: +{
      +  "default": "",
      +  "title": "Path Dept",
      +  "type": "string"
      +}
    • addedInput schema / properties / paths_2d
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "additionalProperties": true,
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Paths 2D"
      +}
  2. First observed

TDQS

A4.5/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 well: it explains the two output modes (assignments vs table), that unassigned atoms come with a reason, that experiment_warnings names misfiled or unused experiments, that tolerance defaults are per-nucleus (1H 0.3, 13C 3.0), and that verdict is the most cautious per-nucleus result while match_score decides nothing. These are exactly the behavioral details an agent cannot infer elsewhere.

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-loads the core action in the first sentence, then layers output options and per-experiment semantics in a logical order. It is dense and the retired-tool paragraph is somewhat historical, but nearly every sentence conveys information an agent needs to fill slots correctly.

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, yet the description still usefully explains the shape of assignments/table results and warning behavior. For a 19-param tool with no annotations it is nearly complete, with the main gaps being the role of solvent, field_mhz, and the max_rows/max_crosspeaks limits.

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 19 params, so the description must compensate, and it does for the hard ones: output modes, paths_2d format with experiment/path pairs, the single-file path slot, the APT/DEPT-135/DEPT-90 distinctions, and tolerance_ppm defaults. It leaves several parameters (solvent, field_mhz, max_rows, max_crosspeaks, api_key) unexplained, so it is strong but not complete.

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 — 'Assign every atom of a KNOWN molecule' — and adds the distinguishing mechanism ('constraint propagation across all of them'). The emphasis on KNOWN molecule implicitly separates it from identification siblings like covnmr_identify or covnmr_rank_candidates, so an agent can tell what it is for 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 Guidelines4/5

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

Gives concrete when-to guidance: supply DEPT-135 with a plain 13C when both exist, and the quaternary carbons come from the difference; it also notes that a spectrum in the wrong slot is analysed as what it is. It stops short of explicitly routing against live siblings (e.g. covnmr_analyze) and only names the retired tools it absorbs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.