nds-mcp

by fkguo

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Most tools have clearly distinct purposes, targeting specific databases and data types. A few pairs, like nds_get_decay vs nds_query_decay_feedings and nds_get_mass vs nds_find_nuclide, could cause minor confusion, but the descriptions provide enough context to differentiate them.
Naming Consistency3/5
Tool names consistently start with 'nds_' but mix verbs like get, query, list, search, find, and interpolate. There are also noun-style names such as nds_info and nds_catalog, so the pattern is not fully uniform, though still readable and descriptive.
Tool Count3/5
With 26 tools, the server is on the heavy end, exceeding the typical 3-15 tool range. However, the broad scope covering multiple nuclear databases (NUBASE, AME, ENSDF, JENDL, EXFOR, CODATA) justifies a larger tool surface, making it borderline but not excessive.
Completeness4/5
The tool surface covers major nuclear data types: nuclide properties, masses, decay, levels, gammas, cross sections, EXFOR, and constants. Minor gaps exist, such as no direct access to raw ENDF-6 BLOB payloads and TUNL data only for A≤20, but these are workable limitations.
Average 3.8/5 across 26 of 26 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'safe' and 'no raw SQL input', implying protection against injection, but does not disclose whether the operation is read-only, what the response format is, how errors are handled, or that there is a hard limit cap (which is only in the schema). The description adds minimal value beyond the schema's own type/constraint information.
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?
The description is a single, tightly worded sentence of 12 words. It is front-loaded with the core purpose ('Safe structured query builder') and follows with essential capabilities ('filter/sort/paginate; no raw SQL input'). Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested filtering objects, multiple database libraries) and the absence of an output schema, the description is too terse to be complete. It does not mention the supported libraries, the fact that it queries nuclear/EXFOR data, or the default selection behavior. The schema provides structure, but the description fails to provide essential high-level context needed by an agent to appropriately invoke this tool.
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 71%, so the baseline is 3. The description adds a high-level conceptual summary ('filter/sort/paginate') that maps to the where, order_by, limit, and offset parameters, but it does not provide any specific parameter-level semantics beyond what the schema already offers. It does not compensate for the 29% of parameters lacking schema descriptions (e.g., offset lacks a description, but the summary covers its general role).
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?
The description clearly identifies the tool as a structured query builder over SQLite tables, with explicit mention of filter/sort/paginate and no raw SQL input. This distinguishes it from raw SQL execution tools, but it does not explicitly contrast it with the specialized sibling query tools (e.g., nds_query_gammas, nds_query_levels), so it falls short of full sibling differentiation.
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?
The description provides minimal guidance on when to use this tool versus the specialized query tools. It implies safe, structured querying but does not state when to choose nds_query over nds_query_gammas or others, nor does it mention any exclusions or prerequisites. Instead of guiding selection, it relies on the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the behavioral difference between raw and sampled modes, including the ENDF-6 NBT/INT interpolation rules. However, it does not mention pagination, default parameter behavior, or error conditions, and there are no annotations to fall back on.
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?
The description is two sentences, efficiently conveying the core action and mode-specific behavior with no wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, 8 required) and no output schema, the description is too sparse. It does not explain how to choose between mt and reaction, energy range defaults, or pagination, leaving significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning for 'mode' by explaining what each mode returns, but it does not explain key parameters like e_min_eV, e_max_eV, n_points, limit, and offset, which also lack schema descriptions. With schema coverage at 50%, the description fails to compensate for the missing parameter context.
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?
The description clearly identifies the tool as retrieving JENDL-5 pointwise cross-section tables and explains the two return modes. It is specific and unambiguous, but it does not differentiate from sibling tools like nds_interpolate_cross_section or nds_get_reaction_info.
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?
No guidance is provided on when to use this tool versus alternatives such as nds_interpolate_cross_section or nds_get_reaction_info. The description only explains the modes, not the use case, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the return contents but does not disclose whether the operation is read-only, requires authentication, has rate limits, or behaves differently for invalid nuclides. The query nature is implied but not explicitly stated as safe.
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?
A single, front-loaded sentence that states the purpose and expected outputs. Every word contributes, with no redundancy or 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 simple query tool with three parameters and no output schema, the description adequately names the returned data types. It is slightly incomplete on usage scenarios and safety, but the core behavior is well covered.
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%, with each parameter described in the schema. The description adds context by framing Z/A as 'parent nuclide' and linking to decay modes, but it does not provide new syntax or format details beyond the schema.
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 uses a specific verb 'Query' with a clear resource ('beta/EC decay feeding patterns from ENSDF') and lists concrete returned data (branching ratios, log(ft), endpoint energies). This distinguishes it from siblings like nds_get_decay or nds_query_levels.
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?
No guidance is given on when to use this tool versus alternatives such as nds_get_decay or nds_query_gammas. The description states what it does but does not mention exclusions, prerequisites, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It only states the search action, without mentioning return format, pagination, required fields, or any operational constraints. For a read-only search, it should at least indicate how results are returned or limited, but it does not.
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?
The description is a single, front-loaded sentence with no fluff. It efficiently conveys the tool's core purpose and key filtering dimensions, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no annotations, no output schema, and multiple sibling tools, one short sentence is insufficient. It lacks guidance on energy filters, result limits, output structure, and how it differs from similar EXFOR-related tools, making the description incomplete for effective tool selection and invocation.
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?
With schema description coverage at 36%, the description must compensate. It mentions target, projectile, reaction, and quantity, which maps to several parameters, but omits energy range (e_min/e_max) and kT range parameters, which are essential for MACS searches. The phrase 'including MACS' adds some value but doesn't explain the required kT inputs.
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 'Search EXFOR experimental reaction data points' with a specific verb and resource, distinguishing this tool from generic search tools like nds_search by naming EXFOR and the data type. It also lists the key search facets (target/projectile/reaction/quantity) and explicitly includes MACS, which is a unique capability.
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 description implies usage when EXFOR experimental reaction data points are needed, but it provides no explicit when-to-use vs alternatives like nds_get_exfor_entry or nds_get_cross_section_table. There are no exclusions or alternative tool names mentioned, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It mentions the return of data and lists output fields, but does not state whether the operation is read-only, what happens for invalid targets, whether any authentication is needed, or any potential errors. For a seemingly simple read operation, the description leaves significant behavioral uncertainty.
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?
The description is a single, compact sentence that leads with the action verb and resource, then lists the output fields. It contains no filler or redundant information, making it highly concise and appropriately structured for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists expected output fields but fails to explain their meaning (e.g., what 'mt' stands for, units of e_min_eV and e_max_eV, or the format of the channel list). With no output schema, this is a notable gap. However, the focus on JENDL-5 and the specific field list provides enough context for a basic understanding.
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 80% (4 of 5 parameters have descriptions), so the schema does most of the work. The tool description adds no parameter-specific explanations; it only lists output fields. The baseline score of 3 is appropriate because the schema covers parameters well, and the projectile's enum makes its meaning clear.
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 the tool's action ('Return available JENDL-5 reaction channels'), specifies the exact data source (JENDL-5), and lists the output fields. This distinguishes it from sibling tools like nds_get_cross_section_table and nds_interpolate_cross_section, which focus on numeric cross-section data rather than channel listings.
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 description implies when to use the tool: to get reaction channel metadata for a given target. However, it provides no explicit guidance on when not to use it or mention of alternatives, such as using cross-section tools if the user needs numerical data. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful behavioral detail by specifying the exact interpolation rules (ENDF-6 NBT/INT), which is beyond the schema. However, it does not explicitly state that the operation is read-only or describe any potential side effects, though they are likely minimal for this type of lookup.
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?
The description is a single, front-loaded sentence with no redundant words. Every element contributes to understanding the tool's function: interpolation, JENDL-5, specific energy, and ENDF-6 rules.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no annotations, and no output schema, the description is too sparse. It omits how to identify the nuclide (Z, A, state), how to select a reaction (mt or reaction), and what the expected return value is. This makes it insufficient for an agent to confidently invoke the tool correctly without additional research.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with state, projectile, mt, and reaction lacking schema descriptions. The description adds no parameter-specific guidance beyond the mention of 'specific energy,' and does not compensate for the undocumented parameters. It fails to explain how to specify a reaction via mt or reaction, or the role of projectile/state.
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 identifies the tool as an interpolation operation for JENDL-5 cross sections at a specific energy, using specific ENDF-6 NBT/INT rules. This distinguishes it from sibling tools like nds_get_cross_section_table, which likely returns a table rather than a single interpolated value.
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 implies the tool is for single-energy interpolation, contrasting with the table-based sibling tools. However, it does not explicitly mention alternatives or exclusions, so while context is clear, it stops short of providing explicit when-to-use vs when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. 'List' implies a read-only operation and filtering/pagination are mentioned, but the exact_only parameter is not surfaced in the description, and no return behavior is described.
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?
The description is a single sentence that front-loads the action and resource. Every phrase adds relevant information, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity listing tool with full schema coverage, the description is adequate but minimal. It omits the exact_only behavior and does not mention what shape the returned list takes, which would be useful in the absence of 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 description coverage is 100%, so the schema already documents all parameters. The description adds a high-level framing of 'keyword filtering and pagination' but provides no detail beyond the schema, so it earns the baseline score.
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 uses a specific verb ('List') and a specific resource ('CODATA fundamental constants'), and clearly conveys the tool's scope. It distinguishes this from siblings like nds_get_constant by emphasizing plural listing behavior with optional filtering and pagination.
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?
It states the tool lists constants and supports optional keyword filtering and pagination, giving some context for when to use it. However, it does not explicitly mention alternatives like nds_get_constant or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning return format, data source details, or any side effects. For a type of operation, it provides almost no behavioral transparency beyond the tool name.
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?
The description is a single, front-loaded sentence that directly states the tool's purpose without excessive wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool with two optional parameters, but it does not describe the return format or behavior when no references are found. Given the absence of an output schema and annotations, a bit more detail would improve completeness.
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?
The input schema fully documents A and keynumber with descriptions. The description adds the 'or' relationship indicating that either parameter can be used, which is helpful but not extensive. Since schema coverage is 100%, 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 clearly identifies the tool's function as looking up bibliographic references, specifies the two lookup keys (keynumber and mass number), and differentiates it from sibling tools like nds_query or nds_search which handle broader data queries.
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 gives clear context for when to use this tool: to retrieve references by NSR keynumber or mass number. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions that only ground-state nuclides are returned, which is a useful behavioral trait. However, it does not disclose other important behaviors such as how stable nuclides are handled (null half_life_seconds and exclusion from half-life searches), which is only mentioned in the schema. Limits, sorting, or pagination are not described. This is a partial disclosure.
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?
The description is one concise sentence that is front-loaded with the action and resource. Every word contributes: it specifies the search type, property examples, and result focus. There is no wasted text, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the core purpose and return focus, but lacks details about the output format since there is no output schema. It does not explain whether results are a list, how they are sorted, or what fields each nuclide contains. Given the tool's complexity (six parameters, multiple properties) and the absence of an output schema, the description is not fully complete for an agent to confidently infer expected results.
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?
All parameters have schema descriptions (100% coverage), so the description does not need to repeat them. The tool description adds minimal value beyond the schema—it mentions the two property names, but the schema already defines an enum that includes these and aliases. The min/max and Z_min/Z_max are well-documented in the schema. The description does not clarify the relationship between the property aliases or the range semantics beyond what the schema 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 the tool's purpose: searching nuclides by property range, with specific examples of properties (half_life_seconds, mass_excess_keV). It also clarifies that it returns ground-state nuclides, which narrows the scope and helps distinguish it from other search tools. The verb 'Search' and resource 'nuclides' are specific, and the scope is well-defined.
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 description implies use for property-range searches, but does not explicitly state when to use this tool over alternatives like nds_find_nuclide or nds_query. It lacks exclusions or guidance on choosing between search methods. The context is clear enough for a basic understanding, but no explicit 'when to use' or 'when not to use' is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions source-aware comparison and mode-based recommendation vs full source list, adding context beyond the name. However, it does not describe the return format, edge cases (e.g., CODATA unavailable), or whether the operation is read-only, leaving some behavioral traits undisclosed.
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?
The description is two concise sentences, front-loaded with the main verb and resource. It avoids redundancy and every sentence adds meaningful information. The mode control is explained efficiently without unnecessary elaboration.
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?
While there is no output schema, the description sufficiently conveys the tool's core purpose and mode behavior for a simple query tool. It does not explain return values or uncertainties, but given the straightforward nature of a charge radius lookup and the clarity of the description, it is reasonably complete. A dedicated note on output format would elevate it, but not critically needed.
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 the baseline is 3. The description adds a clarifying sentence about mode=best|all|compare controlling recommendation vs full source list, but this largely mirrors the schema's enum descriptions. No additional semantic detail is provided for Z or A beyond what the schema already includes.
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 the tool's purpose with a specific verb ('Get') and a unique resource ('nuclear charge radius (rms)'). It distinguishes itself from sibling tools by emphasizing source-aware comparison across IAEA, laser spectroscopy, and CODATA. The mode parameter is explicitly mentioned, further clarifying the scope.
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 description provides implied context about when to use this tool—for nuclear charge radius data—but does not explicitly state when to use it over alternatives or list exclusions. The mode explanation (best/all/compare) offers usage guidance for parameter options, not tool selection. This is clear but not fully explicit in differentiating from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add context by listing the exact quantities returned (mass excess, binding energy/A, beta-decay energy, atomic mass), which sets expectations for the output. However, it does not explicitly state that this is a read-only operation, mention error behavior, or discuss any limitations or permissions.
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?
The description is a single, well-structured sentence that front-loads the core action and resource, then efficiently lists the specific data items. Every element adds value and there is no redundant information.
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?
Given the tool's simplicity (two parameters, no output schema), the description is quite complete. It specifies the data source (AME2020) and enumerates the return fields, which is essential without an output schema. It could add units or a note on error handling, but the current description provides sufficient context for an informed agent.
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% with adequate descriptions for Z (atomic number) and A (mass number). The description only reiterates that these parameters define a nuclide, adding no extra meaning about ranges, units, or relationships. Since schema coverage is high, the baseline of 3 is appropriate.
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 the tool's function with a specific verb ('Get'), a specific resource ('atomic mass data'), and precise scope ('nuclide (Z, A) from AME2020'). It also enumerates the exact data returned (mass excess, binding energy/A, beta-decay energy, atomic mass), distinguishing it from sibling tools like nds_get_separation_energy and nds_get_q_value.
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 description implies when to use this tool by specifying the data type and source (AME2020), but it does not explicitly mention alternatives or state when not to use it. There are no exclusions or comparisons to sibling tools, so the usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It does reveal that the output contains both discrete lines and continuous-spectrum summaries, which is non-obvious and useful, but it does not discuss read-only safety, result size, pagination, or any limitations beyond that content detail.
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?
The description is a single, front-loaded sentence that immediately states the tool's core function, data source, and output content with no unnecessary words. It is optimally concise and structured.
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 schema fully documents all parameters, and the description adequately covers the core output content and scope, making the tool's purpose and invocation sufficiently clear. However, the absence of an output schema or annotations means a brief mention of return structure or usage caveats would make it more complete, but this is not a critical gap.
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% for all 7 parameters, so the description adds minimal semantic value beyond the schema. It mentions radiation types and summary nature, which loosely relates to the 'type' parameter, but it does not explain any parameter in a way that is not already in the schema.
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 states the specific verb 'Get' and the resource 'decay radiation spectra from JENDL-5 Decay', and further clarifies the scope by enumerating radiation types (gamma/beta/alpha/X-ray) and output forms (discrete lines and continuous-spectrum summaries). This explicitly differentiates it from sibling tools like nds_query_gammas or nds_get_decay, which focus on different aspects of decay data.
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 description implies the tool should be used when decay radiation spectra are needed, but it offers no explicit 'when not to use' or alternative tool recommendations. The context is clear only through the tool's purpose, not through explicit comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns basic properties from NUBASE2020, implying a read-only lookup. However, it does not explain how multiple criteria are combined, whether multiple matches are returned, or what 'basic properties' includes, leaving behavioral ambiguity.
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?
The description is two concise sentences with no filler. It front-loads the primary purpose immediately and states the data source, making it easy for an agent to quickly understand the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with three well-described parameters, the description covers the core purpose. However, with no output schema and no annotations, it omits important context such as the output format, how criteria are combined, and whether results are singular or plural. This is a moderate gap for an agent deciding whether this tool meets a query.
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?
The schema already describes each parameter (A, Z, element) with 100% coverage. The description adds meaningful semantic value by explicitly using 'and/or', clarifying that the parameters are optional, flexible filters rather than requiring all to be provided. This goes beyond the schema's individual field descriptions.
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 uses a specific verb ('Find'), identifies the resource ('nuclides'), and clearly defines the search scope by element symbol, Z, and/or A. This clearly distinguishes it from sibling tools like nds_get_mass or nds_search, which target different aspects of nuclear data.
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 description implies when to use this tool: when you need to find nuclides by basic identifiers and retrieve basic properties. However, it does not explicitly state when not to use it or mention alternatives such as nds_get_mass or nds_search, so usage guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description is the primary source for behavioral details. It does disclose a key behavior—never returns BLOB payloads—but omits other details like pagination behavior, error semantics, or permissions. This is adequate but not comprehensive.
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?
One tight sentence that leads with the action and resource, and parenthetically adds a critical behavioral caveat. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool, the description states the core purpose and key limitation, and the schema covers parameters. However, without an output schema, it does not convey the structure of the returned metadata, leaving some ambiguity about the response format.
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 descriptions cover 4 of 5 parameters well (q, limit, library, projectile), giving the agent necessary semantics. The description itself adds no extra parameter information, but with high coverage it does not need to.
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 identifies the action (list), the resource (embedded upstream ENDF-6 zip archive metadata), and the library scope (FENDL/IRDFF), distinguishing it from sibling list tools.
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 for when to use this tool—browsing raw archive metadata—but does not explicitly mention alternatives or state when not to use it. The note about never returning BLOB payloads implies a distinction from payload-returning tools, but no sibling is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds the useful trait of case-insensitive matching by default, but it does not disclose what happens if the constant is not found, the return format (e.g., value and units), or any error behavior. This is a basic yet incomplete disclosure.
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?
The description is a single, front-loaded sentence that immediately conveys the action and target. Every word is meaningful, with no filler or redundancy.
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 tool is simple with only two required parameters, both fully documented in the schema. The description provides the core purpose and a behavioral nuance, which is sufficient for a straightforward lookup. However, the absence of an output schema means the agent does not know the return structure, so it is not a 5.
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% for both parameters (name and case_sensitive), with examples and defaults provided. The description adds no additional parameter-level meaning beyond what the schema already contains, so baseline 3 is appropriate.
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 uses a specific verb ('Get') and clearly identifies the resource ('one CODATA fundamental constant') and the retrieval method ('by name'). It distinguishes itself from siblings like nds_list_constants, which lists constants, by focusing on single-constant retrieval.
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 implies the tool is used when you need a specific constant by name, which provides clear context. However, it does not explicitly mention when not to use it or name alternatives, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose that the result includes all subentries and points, which is useful, but it does not mention output format, potential large payload, error behavior, or whether any specific access conditions apply.
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?
The description is a single, front-loaded sentence that communicates the essential purpose and scope with no redundant wording.
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?
Given the simplicity of a one-parameter retrieval tool and no output schema, the description adequately covers what the tool returns. Minor gaps remain around error handling and output size, but the core information is present.
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?
The schema fully describes the only parameter (entry_id as 'EXFOR entry number'), and the description adds no extra semantics beyond restating that the tool works by entry number. This meets the baseline for high schema coverage.
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 the tool retrieves one EXFOR entry including both subentries and data points, keyed by entry number. This specific verb-plus-resource pairing differentiates it from sibling search and listing tools.
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 implies usage: use when you have a known EXFOR entry number and need the full entry. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough for a simple lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description indicates a read operation (Get) with a data source (AME2020). It does not disclose output format, default behavior when 'type' is omitted, or error handling, but the low-risk nature of a query tool keeps it at a mid-level score.
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?
The description is a single, front-loaded sentence stating the action and listing the Q-value types. No filler words, every element is informative.
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?
Given the tool's simplicity (3 parameters, no output schema), the description covers the essential purpose and differentiates from siblings. It could mention that omitting 'type' returns all Q-values, but that is already captured in the schema, so the context is adequate.
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%, so all parameters (Z, A, type) are already documented. The description adds human-readable Q-value notation (e.g., Q(2β⁻)) that maps to enum values, but this is marginal beyond the schema's own 'Q-value type (omit for all)' description.
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 uses a specific verb 'Get' with the resource 'Q-values from AME2020', and explicitly lists the available Q-value types, clearly distinguishing this from sibling tools like nds_get_mass and nds_get_separation_energy.
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 clearly implies usage when Q-values are needed and lists all types, but it does not explicitly mention when not to use it or name alternatives. This provides clear context without exclusions, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the data source (AME2020) and available types, but does not explicitly state that this is a read-only operation, describe output format, or mention error behavior. The gaps are notable but not severe for a simple retrieval 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?
The description is a single, well-structured sentence that conveys the action, resource, source, and supported types with zero wasted words. It is appropriately concise and front-loaded.
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 tool is simple with fully documented parameters and a clear one-line purpose. The description does not explain the return format, but given the absence of an output schema and the straightforward nature of the retrieval, the provided information is nearly sufficient. A small gap remains regarding what the response looks like.
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%, so the baseline is 3. The description only echoes the enum values (Sn, Sp, S2n, S2p) already listed in the schema and adds no additional meaning about the Z, A, or type parameters beyond what the schema 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 uses a specific verb ('Get') and clearly identifies the resource ('nucleon separation energies from AME2020'), listing the exact energy types (Sn, Sp, S2n, S2p). This distinguishes it from sibling tools like nds_get_mass or nds_get_q_value.
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 clearly implies when to use this tool—whenever separation energies are needed—but it does not explicitly state when not to use it or mention alternatives. The specificity provides strong contextual guidance, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a list/read operation and mentions the data source (JENDL-5) and output concept (A/state), but does not describe return format, pagination, or any edge cases. This is adequate but not comprehensive for a read 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?
The description is a single, front-loaded sentence with no redundant words. It includes the essential verb, resource, and parameter context, earning a maximum score.
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 simple list tool with two parameters and no output schema, the description sufficiently conveys the tool's purpose and output concept (A/state targets). It does not fully describe return value structure, but the minimal complexity of the tool makes this acceptable.
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 50% (Z has a description, projectile has enum/default but no description). The description repeats the parameters without adding deeper semantics. The mention of 'A/state' hints at output structure but does not elaborate on parameter meaning beyond the schema.
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 a specific verb ('List') and resource ('available JENDL-5 XS targets (A/state)'), and specifies the required inputs (Z and projectile). This distinguishes it from sibling tools like nds_get_cross_section_table or nds_query, which are about retrieving data rather than enumerating available targets.
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 gives clear context for when to use the tool (when you need to list available targets for a given Z and projectile), but does not explicitly mention alternatives or exclusion scenarios. It implies usage but lacks a direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral transparency. It states the return fields, which adds value, but does not disclose filtering capabilities, output structure, pagination, or any limits/caveats. The behavior is partially transparent but leaves key usage details unmentioned.
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?
The description is one sentence, front-loaded with the primary action and target. It includes essential return information without any filler. Every word contributes to understanding the tool's purpose.
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 covers the core purpose and return types, which is sufficient given the high schema coverage. However, there is no output schema and the description does not mention the limit parameter or filter options, leaving minor gaps for a complete picture.
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 high (83%), so the schema already explains most parameters (Z, A, energy filters). The description adds no parameter-specific meaning beyond 'for a nuclide', which maps to Z/A. Since the schema handles the heavy lifting, baseline 3 is appropriate.
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 uses a specific verb ('Query') and resource ('gamma-ray transitions from ENSDF'), and explicitly lists the returned data types (energies, intensities, multipolarities, conversion coefficients). This clearly distinguishes it from sibling tools like nds_query_levels and nds_query_decay_feedings, which target different nuclear data.
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: it is used for querying gamma-ray transitions from ENSDF for a nuclide, implying the need for Z and A. It does not explicitly name alternatives or exclusions, but the scope is well-defined by the query target.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses that the tool operates on an 'installed' database library (implying local, not online) and that it inspects rather than modifies. However, it does not detail side effects, error conditions for missing libraries, or the exact response format, leaving some room for ambiguity.
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?
The description is a single, front-loaded sentence that efficiently communicates the tool's purpose and key scope options. There is no filler or repetition of schema details, making every word earn 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?
Given the simple tool with only two parameters and no output schema, the description adequately covers the what and the key optionality. It could be more complete by hinting at the output structure (e.g., returning table definitions), but the mention of tables/columns/foreign keys provides a reasonable mental model, so it is sufficiently complete for a low-complexity tool.
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?
The input schema fully documents both parameters with descriptions for 'library' (with an enum) and 'include_indexes' (with a default). The description adds a general hint about 'optional indexes' which aligns with include_indexes, but it does not meaningfully extend the schema's own parameter explanations. This matches the baseline for high schema coverage.
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 uses the specific verb 'Inspect' targeting the resource 'SQLite schema' and enumerates the scope (tables/columns/foreign keys, optional indexes). This clearly distinguishes the tool from sibling data-query tools like nds_query or nds_get_mass, making its purpose unmistakable.
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 description implies usage—when you need to inspect the schema of an installed database—but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites beyond the implicit notion of the library being installed. This meets the 'implied usage' criterion but lacks direct comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clarifies that the tool lists resources and directs to appropriate tools, but does not disclose output format, whether it scans local files or online sources, or any limitations. This is adequate but not rich in behavioral detail.
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?
The description is a single sentence, immediately front-loaded with the verb 'Catalog', and every phrase adds value. There is no redundancy or irrelevant detail.
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 simple no-parameter catalog tool, the description covers the essential purpose and the type of information returned. It could be more explicit about the output structure, but given the lack of output schema, it is reasonably complete for an agent to understand the tool's role.
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?
The tool has zero parameters, and the schema is an empty object with 100% coverage. Baseline for no params is 4, and the description adds no parameter-specific details (as none exist), which is appropriate.
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 uses a specific verb 'Catalog' with a clear resource: installed libraries and query entrypoints. The parenthetical explanation explicitly states what information is provided (existence, location, tool selection), which distinguishes it from sibling tools that query specific data.
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 implies when to use this tool: to discover what libraries exist, where to query, and which tool to use. However, it does not explicitly name alternatives or exclusions, leaving some ambiguity for an agent deciding between this and other discovery tools like nds_schema or nds_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of transparency. It discloses the data source (NUBASE2020) and explicitly enumerates the returned data fields, making it evident that this is a read-only retrieval operation. It does not mention edge cases like not-found behavior or units, but the description is sufficiently clear for a straightforward get 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?
The description is a single sentence that is concise, front-loaded with the main action, and contains no filler words. Every element (source, data types, isotopes) adds value and is directly relevant to tool selection and invocation.
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 simple 2-parameter retrieval tool without an output schema, the description adequately covers what the tool does, what data will be returned, and the data source. It could be slightly richer by specifying units or noting that all isomers are included, but it is complete for typical use cases.
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?
The input schema already provides complete descriptions for both parameters (Z: atomic number, A: mass number) with 100% coverage. The description does not add parameter-specific nuances beyond what the schema states, so the baseline score of 3 is appropriate.
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 uses a specific verb 'Get' with a clear resource 'decay information from NUBASE2020' and lists the exact data contents (half-life, spin/parity, decay modes with branching ratios, isomers). This clearly distinguishes it from sibling tools like nds_get_mass or nds_get_separation_energy, which focus on different nuclear properties.
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 clearly implies the use case: when decay information for a nuclide is needed, as it states the data types returned. It does not explicitly mention when not to use it or name alternative tools, but the context is clear and distinct from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explicitly uses 'Return' to indicate a read-only operation and lists the exact metadata fields returned. It does not discuss potential side effects or prerequisites, but for a simple metadata retrieval tool this is adequate context.
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?
The description is a single, front-loaded sentence with no fluff. Every phrase adds value: the verb, the resource, and the specific metadata items. It is concise and easy to parse.
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?
Given zero parameters and no output schema, the description is reasonably complete. It lists the key metadata categories returned, which is sufficient for an agent to decide whether to call this tool. It does not detail the response structure, but that is not critical for a metadata summary tool.
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?
The tool has zero parameters, so the schema is an empty object (100% coverage). The description adds meaning by specifying the content of the metadata returned, which is more than the schema provides. Baseline for zero parameters is 4, and the description meets it.
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 uses a specific verb ('Return') and clearly identifies the resource (NDS database metadata), enumerating specific items (data versions, nuclide counts, DB file hash). This clearly distinguishes it from sibling tools focused on querying specific data or operations.
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 description implies usage for obtaining general database metadata, but it does not explicitly state when to use this tool versus alternatives like nds_catalog or nds_schema. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the non-mutating nature (does not update), which is essential for trust. It doesn't describe return format or network error behavior, but the most critical trait is covered.
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?
Two short sentences with the key information front-loaded. No wasted words, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return value or outcome. While it clearly states the check and non-update behavior, it doesn't indicate what the tool returns (e.g., a version number, a boolean, or a message). This is a gap, though the tool's simplicity mitigates it somewhat.
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?
The input schema has zero parameters, so the description has no parameters to explain. The baseline for zero parameters is 4, and the description is appropriate.
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?
Clearly states it checks the npm registry for a newer nds-mcp version, using the specific verb 'check' and resource. This distinguishes it from sibling tools, which all focus on nuclear data queries.
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?
Provides a clear context for use (checking for newer versions) and explicitly states what it does not do ('does not perform updates'). It lacks named alternatives, but the exclusion is valuable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![nds-mcp MCP server](https://glama.ai/mcp/servers/fkguo/nds-mcp/badges/card.svg)](https://glama.ai/mcp/servers/fkguo/nds-mcp)

Score Badge

Copy to your README.md:

[![nds-mcp MCP server](https://glama.ai/mcp/servers/fkguo/nds-mcp/badges/score.svg)](https://glama.ai/mcp/servers/fkguo/nds-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fkguo/nds-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server