nds-mcp

Overview Schema Source Related Servers Discussions Admin

nds_query_levels

Query nuclear energy levels from ENSDF and TUNL databases, returning level energies, spin-parity, half-lives, and resonance data for light nuclei.

Instructions

Query nuclear energy levels from ENSDF and TUNL. Returns level energies, spin-parity, half-lives. For A ≤ 20, automatically includes TUNL resonance data (widths, isospin, decay modes, table_label for TUNL publication provenance). Each result has a "source" field ("ENSDF" or "TUNL").

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": {
      "Z": "<Z>",
      "A": "<A>",
      "include_decay_datasets": "<include_decay_datasets>",
      "limit": "<limit>"
    },
    "name": "nds_query_levels"
  }
}

Input Schema

Name	Required	Description
`A`	Yes	Mass number
`Z`	Yes	Atomic number
`limit`	Yes
`energy_max`	No	Maximum level energy (keV)
`energy_min`	No	Minimum level energy (keV)
`include_tunl`	No	Include TUNL resonance data (default: true for A ≤ 20, false otherwise)
`include_decay_datasets`	Yes	Include levels from decay datasets (default: ADOPTED only)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Aug 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses return fields, the 'source' field, and conditional TUNL data (widths, isospin, decay modes, table_label). It doesn't mention pagination or auth, but these are not necessarily expected for a read-only query tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with no filler: first sentence gives purpose, second explains TUNL behavior, third describes the source field. Every sentence earns its place.

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?

The description, combined with the rich schema, gives a complete picture for a query tool: inputs are documented, outputs are listed, and special behavior is explained. Missing explicit return structure details but that's acceptable without an output schema.

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 86%, so the baseline is 3. The description adds the A ≤ 20 condition and TUNL-specific output details but does not further explain energy_min/max or limit beyond what the schema already provides.

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 clearly states 'Query nuclear energy levels from ENSDF and TUNL' and specifies the returned data (energies, spin-parity, half-lives), distinguishing it from sibling tools like nds_query_gammas and nds_query_decay_feedings.

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?

The description provides clear context that this tool is for energy level queries and explains the automatic TUNL inclusion for A ≤ 20, which is useful. However, it doesn't explicitly compare with alternatives or state when not to use this tool.

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