xraylib MCP Server

Server Quality Checklist

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

Latest release: v0.1.6
Disambiguation3/5
Many tools are systematically similar (e.g., CS_Total, CS_Total_Kissel, CS_Total_CP, CSb_Total, etc.) with only slight differences in units or method. Descriptions help distinguish them, but the sheer volume of near-identical tools can cause misselection.
Naming Consistency3/5
Naming conventions are mixed: some use CamelCase (AtomicNumberToSymbol), others use underscores (Atomic_Factors, CS_Total), and some are short (Fi, Fii). While prefixes and suffixes often indicate variations, the overall pattern is inconsistent.
Tool Count2/5
106 tools is excessive. Although the domain is complex, many tools are systematic variants (e.g., unit or method suffixes) that could be combined or reduced, making the server feel bloated.
Completeness5/5
The tool set covers a very wide range of X-ray atomic physics: elemental properties, cross sections (in two unit systems, with and without Kissel), scattering (differential, polarized), compound calculations, radionuclide data, and NIST compound constants. It is highly comprehensive.
Average 3.5/5 across 106 of 106 tools scored. Lowest: 2.6/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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under BSD 3-Clause.
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?
Without annotations, the description carries full burden but only states the basic retrieval action. It does not disclose what specific data fields are returned, whether the operation is read-only (implied but not explicit), or any potential side effects. The existence of an output schema is not leveraged in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with the purpose stated upfront. However, it could be slightly more structured (e.g., separate sections for purpose and parameter) without adding length.
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 large set of sibling tools (many similar 'Get...' functions), the description lacks completeness. It does not explain what 'radionuclide data' entails or how it compares to other data retrieval tools. The presence of an output schema reduces the need to describe returns, but the description should at least hint at the type of data (e.g., half-life, decay modes).
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 only parameter 'name' is described with examples ('55Fe', '241Am', '109Cd'), which adds concrete value beyond the schema's generic title. However, schema description coverage is 0%, and the description does not explain the expected format, encoding, or constraints (e.g., case sensitivity).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get radionuclide data by name' largely restates the tool name, adding only examples like '55Fe'. It is clear but fails to distinguish from sibling tools such as GetRadioNuclideDataByIndex or GetRadioNuclideDataList, which serve similar purposes with different lookup methods.
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 over alternatives. There is no mention of prerequisites, context, or scenarios where this lookup is preferred over sibling tools, leaving the agent to guess the intended usage.
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 should fully disclose behavior. It mentions the parameter range for Z (1-120) and provides transition examples, but does not describe side effects, performance, or assumptions. The tool's read-only nature is implied but not explicit.
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?
The description is short and front-loaded with purpose, followed by parameter details in a clear 'Args:' format. Every sentence is useful, though the 'Args:' prefix is slightly redundant but not harmful.
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 simple inputs and an output schema exists, so the description is somewhat adequate. However, it lacks any explanation of the return value or additional context like units or typical usage, which would help an AI agent fully understand the tool's behavior.
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 0%, so description must compensate. It explains Z as atomic number with range and auger_trans as a transition name with two examples. However, it does not specify the exact format or accepted values beyond the examples, which is a gap for correct invocation.
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 states the tool gets the Auger rate for a given transition, with specific verb 'Get' and resource 'Auger rate'. It lists parameters and examples, but does not differentiate from siblings like AugerYield which might be confusing for an AI, though the name itself provides some distinction.
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 explicit guidance on when to use or not use this tool compared to alternatives like AugerYield or other rate functions. The description lacks context about prerequisites or scenarios, leaving the AI to infer usage from the tool name alone.
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?
The description only states what it calculates and the units. With no annotations, it should disclose more behavioral traits (e.g., input validation, edge cases, return format). The existence of an output schema may cover return values, but the description itself is thin.
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?
The description is concise with a clear purpose sentence followed by parameter explanations. No unnecessary words, front-loaded effectively.
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?
Given the tool has only 2 parameters, an output schema, and a straightforward calculation, the description is minimally complete. However, it lacks context on input constraints and differentiation from siblings, which 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 description adds meaning to both parameters: compound is a chemical formula with examples, E is photon energy in keV. Since schema coverage is 0%, this is helpful, but it lacks details like valid range for E or compound format requirements.
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 states it calculates the Compton scattering cross section of a compound in barn/atom. The verb 'Calculate' and resource are specific. However, it does not differentiate from siblings like CS_Compt_CP (which may be for elements), but the compound focus is explicit.
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 on when to use this tool versus the many siblings (e.g., CSb_Compt, CS_Compt_CP). The agent must infer from the name and description that this is for compounds, but no explicit when-to-use or when-not-to-use information.
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 available. Description implies a pure computation but fails to state read-only nature, required data availability, or any side effects. Minimal behavioral disclosure.
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?
Short description with purpose and parameter list. Every sentence contributes. Could be slightly more structured with separate sections, but sufficient.
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 40+ sibling tools and no output schema explanation, description lacks differentiation and does not cover edge cases, return format, or when to prefer this variant over others.
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 has 0% description coverage. Description adds meaning: Z range (1-120), line name examples, E in keV. However, does not specify valid line names fully or describe restrictions beyond examples.
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?
Clearly states 'calculate the fluorescence line cross section using Kissel photoionization' with units. Distinguishes from basic CS_FluorLine but not from other Kissel variants like CSb_FluorLine_Kissel_Cascade.
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?
Lists parameters with examples but provides no guidance on when to use this tool versus sibling tools for different Kissel cascade options or other calculation methods.
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 the full burden. It only states the calculation type and parameters, but does not disclose side effects, input validation, error handling, or whether the tool is purely computational. For a non-destructive computation, a higher score could be argued, but given no behavioral details beyond the basic purpose, a 2 is appropriate.
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?
The description is very short and front-loaded: one sentence for purpose, then parameter details. No fluff, every sentence adds value. Could be more structured (e.g., separate behavior and usage), but for its length it's efficient.
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 high complexity (many similar siblings, 3 parameters, output schema exists), the description is too minimal. It does not explain 'full cascade', the meaning of 'b' in the name, or how output relates to inputs. The existence of an output schema reduces the need for return value details, but the description still fails to provide sufficient context for an agent to distinguish this from many siblings.
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 description adds meaning beyond the raw schema: Z is atomic number (1-120), shell is named like 'K_SHELL', E is in keV. These provide semantic context that the schema lacks (0% coverage). However, it does not list all valid shell names or specify allowed values, leaving gaps.
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 states it calculates fluorescence shell cross section with full cascade using Kissel, specifying units (barn/atom). However, among many similar siblings (e.g., CS_FluorShell_Kissel_Cascade, CSb_FluorShell_Kissel_no_Cascade), it does not distinguish what 'b' or 'full cascade' means relative to alternatives.
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 on when to use this tool vs. siblings. There are many similar tools differing only by cascade type and Kissel/non-Kissel, but the description offers no decision criteria, exclusions, or examples of appropriate scenarios.
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 transparency. It only states the calculation and parameter constraints (Z range, shell examples, E in keV), but omits details about the underlying model, assumptions, or limitations. The behavior is implied but not explicitly disclosed.
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 concise: one sentence summarizing the function followed by parameter explanations in a clean bullet-like format. Every element serves a purpose with no redundancy.
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 large sibling family (many fluorescence cross section tools), the description lacks contextual completess. It does not explain the difference between shell and line cross sections, nor the significance of units or when multiple variants (e.g., with/without cascade) apply. The output schema existence is noted but not leveraged.
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 has 0% description coverage, so the description must compensate. It provides useful context: Z range (1-120), shell name examples (K_SHELL, L1_SHELL), and energy unit (keV). However, it does not list all valid shell names or explain the meaning of shell designation, leaving gaps.
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 states the tool calculates 'fluorescence shell cross section (cm2/g)', which clearly identifies the physical quantity and distinguishes it from line or total cross sections among siblings. However, it does not explicitly differentiate from the similar CSb_FluorShell or other variants, leaving some ambiguity.
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 siblings like CS_FluorLine or CSb_FluorShell. The description only lists parameters without any conditional logic or context for selection, making it insufficient for guiding agent choice.
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 carry the full burden. It fails to disclose behavioral traits such as valid energy ranges, compound format constraints, error handling, or whether the Kissel method imposes limitations. The minimal description does not adequately inform the agent about tool behavior.
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?
The description is very concise with one sentence and two bullet points for arguments. It is front-loaded with the key action. However, the structure is minimal and could benefit from clearer separation between the purpose and argument descriptions.
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?
Despite having an output schema (unseen), the tool description is incomplete for its context. It does not clarify what 'CP' denotes, which is crucial given siblings like CS_Photo_Total. The Kissel method is not explained, nor are the output format or units reiterated. More context is needed for proper usage.
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 description adds meaning beyond the empty schema by providing examples for each parameter: compound ('SiO2', 'H2O') and E (photon energy in keV). This partially compensates for 0% schema coverage. However, it lacks details like acceptable value ranges or compound syntax rules, leaving gaps.
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 states it calculates total photoionization cross section in cm2/g using the Kissel method. The verb 'Calculate' and resource 'total photoionization cross section' are specific. However, the meaning of 'CP' is not explained, and there are many similar sibling tools (e.g., CS_Photo_Total, CS_Photo_CP, CS_Photo_Kissel_CP) without differentiation, slightly reducing clarity.
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 no guidance on when to use this tool versus alternatives such as CS_Photo_Total, CS_Photo_Kissel, or CS_Photo_CP. There is no mention of prerequisites, valid ranges, or method selection criteria, leaving the agent without context to choose appropriately.
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 provided, so description carries full burden. It mentions Z range and shell name examples but does not disclose further behavior, such as return format or error handling.
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?
Extremely concise: two sentences plus parameter list. No unnecessary words, every part adds value.
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?
Even though an output schema exists, the description does not explain what the function returns (e.g., float yield value). It also lacks details on valid shell names beyond two examples.
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 0%, but description adds meaning: Z explained with range (1-120) and shell with examples. This is helpful but not exhaustive, as no enum or full list is provided.
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?
Description clearly states it retrieves fluorescence yield for a given shell, with verb and resource. However, it does not distinguish from similar sibling tools like AugerYield or CS_FluorLine.
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 on when to use this tool versus alternatives. Among many similar tools, the description provides no context for selection.
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 provided, the description carries the full burden of behavioral disclosure. It does not mention any behavioral traits such as whether the calculation is for bound or free electrons, valid energy ranges beyond the parameter constraint, or any side effects. The brief description is insufficient for a tool with many similar siblings.
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?
The description is very concise with two sentences plus an Args list, no redundant text. It front-loads the main purpose. However, it could include more detail without becoming verbose, given the tool's complexity.
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 large number of sibling tools for various cross-sections, the description lacks detail on the specific variant (e.g., bound vs free). It does not mention the output schema or return value nature. The tool has an output schema, so the description need not repeat return values, but it still fails to specify output units or context.
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 0% description coverage, so the description compensates by explaining Z as atomic number (1-120) and E as photon energy in keV. This adds meaning beyond the parameter names. However, it does not describe the units or format of the return value or any additional constraints.
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 states the tool calculates the Compton scattering cross section of an element in barn/atom, providing a specific verb and resource. However, it does not differentiate from sibling tools like CS_Compt, CS_Compt_CP, or CSb_Compt_CP, making the purpose slightly ambiguous.
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 like CS_Compt, CSb_Compt_CP, etc. The description lacks any context about prerequisites or situations where this tool is preferred.
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 should disclose behavioral traits. It merely states the calculation and input format, omitting details like return format, error handling, performance, or limitations. The output schema might compensate, but the description adds minimal behavioral context.
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?
The description is concise with two lines and an argument list. It is front-loaded with the core action. However, it could be more structured (e.g., separate description and argument sections) but is efficient for the information provided.
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 complexity (2 params, no annotations, output schema exists), the description is too minimal. It does not explain the 'b' in the name, differences from similar tools like CS_Photo_CP, or the intended use case. An agent may misapply it without more context.
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 description coverage is 0%, so the description must add meaning. It provides clear explanations for both parameters: compound as chemical formula with examples, E as photon energy in keV. This is sufficient for an agent to understand inputs.
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?
Clearly states the tool calculates photoionization cross section for a compound, with units (barn/atom). However, it does not differentiate from sibling tools like CS_Photo_CP or CSb_Photo_Total, which may have similar purpose but different scope.
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 on when to use this tool versus alternatives. The description only lists required parameters but does not specify context, prerequisites, or exclusions. An agent cannot decide between CSb_Photo_CP and similar tools based on this description.
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 exist, so the description carries full burden. It does not disclose behavior on invalid formulas, case sensitivity, or whether it is purely computational (non-destructive). Minimal transparency.
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?
The description is very brief—two sentences with an Args block—which is efficient and front-loaded. It avoids unnecessary text, earning its place.
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 is simple with one parameter, and an output schema exists (not shown). The description covers basic usage but lacks details on error handling or formula constraints, making it minimally adequate.
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 description includes an Args section with examples ('SiO2', 'H2O', 'Ca5(PO4)3F'), adding meaning beyond the schema's bare type definition. This partially compensates for the 0% schema description coverage, though more format details could help.
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 explicitly states 'Parse a chemical compound formula and return its composition,' providing a clear verb and resource. It is distinct from sibling tools that handle atomic properties or compound data retrieval, though it could further clarify what 'composition' entails.
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 over alternatives. Given many sibling tools also involve compounds, the description lacks context for tool selection.
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 full burden. It discloses the calculation purpose and units, implying a pure read operation. However, it does not explicitly state that the tool is non-destructive or any other behavioral traits. For a computation tool, this is minimally adequate but lacks explicit safety guarantees.
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?
The description is short and front-loaded with the purpose. The Args section is clear. It could be more concise by removing the args header and integrating into the sentence, but overall it is efficient and easy to parse.
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 large number of similar siblings (e.g., CS_FluorLine_Kissel_Cascade, CSb_FluorLine_Kissel, etc.), the description fails to explain what 'full cascade' means or the difference between 'b' and non-'b' versions. It does not mention what the tool returns (though an output schema exists). The description is insufficient for an agent to correctly differentiate and invoke this tool over others.
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 has 0% description coverage, so the description must compensate. It briefly describes Z (1-120), line (with examples), and E (keV). This adds meaning beyond type/title but lacks details like valid ranges for E or exact format for line. It helps but is incomplete.
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 states it calculates fluorescence line cross section with full cascade using Kissel in barn/atom. It identifies the resource (cross section) and verb (calculate). However, it does not distinguish this tool from siblings like CS_FluorLine_Kissel_Cascade (without 'b') or other variants, leaving the agent unsure which to use.
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. The description does not mention when to use cascade vs non-cascade, or the significance of the 'b' prefix. Without context, the agent may select incorrectly.
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 provided, so description carries full burden. It only describes the calculation but does not disclose behavioral traits like output format, error conditions, or prerequisites (e.g., valid shell names beyond examples).
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?
Description is short and front-loads the purpose. Parameter details are appended in a structured docstring format. No wasted words, but could be slightly more compact by integrating the purpose with parameter context.
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?
Output schema exists, so return values are not needed in description. However, given the domain complexity and many sibling tools, the description lacks context on what the 'b' prefix means and how this tool differs from similar cross-section tools.
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 description coverage is 0%, but the description lists parameters with semantic hints: Z range (1-120), shell naming convention (e.g., 'K_SHELL'), and E unit (keV). This adds meaningful value beyond the schema's type constraints.
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?
Description states 'Calculate the fluorescence shell cross section (barn/atom)' with a clear verb and resource, plus units. However, it does not distinguish from very similar sibling tools like CS_FluorShell or CSb_FluorLine, which likely perform analogous calculations.
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 on when to use this tool versus alternatives such as CS_FluorShell (without 'b') or CSb_FluorLine. The description only states what it does, without context for selection.
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 fully disclose behavior. It lacks details on return format, error handling for invalid compounds, energy range restrictions, or whether the calculation is for a single energy or multiple. The description only specifies the calculation but not its operational boundaries.
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?
The description is highly concise: two lines of text plus parameter explanations. It avoids fluff and gets to the point. However, it could benefit from a brief note on output or usage context without significantly increasing length.
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?
Given the tool has an output schema (not shown), the description does not need to explain return values. However, among many sibling tools, this description provides minimal context about how it differs from others (e.g., CS_Energy for elements). It covers the essential inputs but lacks safety or constraint information, making it adequate but not complete.
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?
With 0% schema coverage, the description must add meaning. It provides example formulas ('SiO2', 'H2O') for compound, explaining it's a chemical formula, and states E is photon energy in keV. This adds basic semantics but lacks accepted formats, allowed characters for compound, or energy range constraints.
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 action ('Calculate'), the property ('mass energy-absorption cross section'), the substance ('compound'), and includes units ('cm2/g'). Among many cross-section sibling tools (CS_Total, CS_Photo, CS_Energy), this specific tool for compound mass energy-absorption is distinctly identified.
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 does not provide any guidance on when to use this tool versus alternative cross-section tools (e.g., CS_Total_CP, CS_Energy for elements), nor does it mention prerequisites or preferred use cases. It simply states what it does, leaving the agent to infer usage context.
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 must provide behavioral details. It only states the basic calculation without cascade, omitting assumptions, limitations, or side effects. For a physics tool, more context about the model and constraints is needed.
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?
The description is short and includes an args list, which is efficient. The structure is clear but could be more formal. Every sentence adds value.
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?
The description lacks explanation of what 'without cascade' means, how this relates to other Kissel-based tools, and what the output is (despite an output schema existing). Given the complexity and many siblings, it is incomplete.
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 0%, so the description adds some meaning: Z range (1-120), line examples (KL3_LINE, KA_LINE), and E in keV. However, it does not fully document valid line names or energy constraints, leaving gaps.
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 task: 'Calculate the fluorescence line cross section without cascade using Kissel (cm2/g)'. It specifies the verb, resource, method, and units, distinguishing it from siblings that include cascade or use different methods.
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 on when to use this tool versus alternatives like CS_FluorLine_Kissel (with cascade) or other similar tools. Given the large number of siblings, the lack of usage context makes it difficult for an agent to choose correctly.
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 present, and the description does not disclose any behavioral traits such as valid energy/angle ranges, assumptions, side effects, or dependencies. For a scientific computation tool, this is insufficient.
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 extremely concise, with a one-line purpose immediately followed by a clear parameter list. Every sentence adds necessary information; no wasted words.
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 complexity of the domain and numerous sibling tools, the description lacks context about how this tool differs from similar ones (e.g., what 'b' or 'CP' means). An output schema exists, so return values are not needed, but limitations or prerequisites are absent.
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%, but the description adds critical semantic information: units for E (keV) and theta (radians), and an example for compound. This compensates for the bare schema titles.
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 states the tool calculates the differential Rayleigh scattering cross section of a compound, including units (barn/atom/sr). However, among siblings like DCS_Rayl and DCS_Rayl_CP, it does not differentiate why this specific variant should be used.
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 like DCS_Rayl, DCSb_Rayl, or DCS_Rayl_CP. The description simply lists parameters without usage context 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?
No annotations are provided, so the description should disclose behavioral traits. It only says 'calculate', implying a read-only computation, but does not explicitly state idempotence, side effects, or any constraints (e.g., quantum efficiency limits, required input ranges). With zero behavioral context, the description fails to inform the agent about potential pitfalls.
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?
The description is short and front-loaded with the purpose. The parameter list is presented clearly in a bullet-like format (using Args:). It wastes no words, though integrating the purpose and parameters into a single coherent sentence could be slightly more structured. Nonetheless, it is appropriately concise.
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?
Given that an output schema exists, the description is not required to detail return values. However, the description lacks context about what the tool returns (e.g., complex number, unit) and does not mention any prerequisites or typical use cases. For a tool with three parameters and many siblings, the description is minimal but sufficient for a basic understanding.
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%, but the description adds meaningful parameter details: compound (chemical formula with examples), E (photon energy in keV), density (g/cm3). This clarifies units and format beyond the schema's type-only definitions. Slight deduction for not specifying valid ranges or default values.
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 states it calculates the real part of refractive index for a compound. This verb+resource purpose is specific and implicitly distinguishes from the sibling 'Refractive_Index_Im' (imaginary part). However, it does not explicitly mention what the output is or differentiate further from other related tools like 'Atomic_Factors'.
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 on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., valid compound formula) or contraindications. The description merely states what it does without context for selecting it among the many sibling tools.
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 must disclose behavioral traits. It does not mention side effects, permissions, rate limits, or what happens with invalid inputs. The tool appears safe but lacks transparency.
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?
The description is short and to the point, with two sentences and a list of arguments. It could be more efficient by combining the argument descriptions into prose, but overall it is not verbose.
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?
Given there is an output schema (not shown), the description need not explain return values. However, it lacks context about what natural width represents, units, or common use cases. For a tool among many similar atomic data tools, more context 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 description adds some meaning beyond the schema by specifying valid range for Z (1-120) and providing example shells. However, it does not explain the concept of natural width or how the shell parameter affects the result. Schema has 0% description coverage, so the description partially compensates.
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 'Get the natural width of an atomic level' with a specific verb and resource. It distinguishes itself from siblings like LineEnergy or EdgeEnergy by focusing on width.
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 usage guidelines provided. The description does not specify when to use this tool over alternatives like LineEnergy or FluorYield, nor does it mention any 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?
No annotations provided. Description is minimal and does not disclose any behavioral traits beyond the basic calculation. No mention of precision, side effects, or assumptions.
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?
Extremely concise with clear docstring structure. Every sentence adds value with no waste.
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?
Adequate for a simple calculation tool with output schema present. But lacks details on edge cases and differentiation from numerous siblings.
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?
Adds significant meaning: Z is atomic number 1-120, line examples like KL3_LINE, E in keV. This compensates for 0% schema coverage.
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 states the tool calculates fluorescence line cross section with units. However, it does not differentiate itself from many similar sibling tools like CS_FluorLine or CSb_FluorLine_Kissel.
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 on when to use this tool versus alternatives. Missing context about prerequisites or preferred scenarios.
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 provided, so description carries full burden. It mentions input ranges and units but does not disclose error handling, side effects, or performance. The tool is likely read-only but not explicitly stated.
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?
Extremely concise: one sentence plus a clear parameter list. Every part is necessary, and the structure is easy to scan.
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?
Parameter semantics are covered, but the description omits context about the 'CSb' prefix, differences from similar tools, and any output details (though an output schema exists). In a large family of siblings, this leads to ambiguity.
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?
Input schema has zero description coverage, but the description compensates by providing essential semantics for all three parameters: Z range (1-120), shell naming convention with examples, and energy units. This is highly valuable for correct usage.
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?
Clearly states the tool calculates fluorescence shell cross section using Kissel photoionization with units. However, it does not differentiate from similar sibling tools like CS_FluorShell_Kissel or CSb_FluorShell_Kissel_Cascade, which share the same description pattern.
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 on when to use this tool versus the many similar Kissel shell cross-section tools. The description lacks any conditions, context, or exclusions to aid selection among siblings.
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 bears the full burden. It does not disclose behavioral traits such as whether it is a read-only operation, input validation behavior, or performance characteristics. Only basic input constraints are given.
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 extremely concise: one sentence stating the operation and unit, followed by a minimal but clear list of parameters. No superfluous words.
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?
Given the output schema exists (not shown but indicated), the description does not need to explain return values. However, it lacks context about the model or database used (e.g., whether it's for free atoms) and does not differentiate from highly similar siblings. Adequate but could be more complete.
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 description coverage is 0%, and the tool description adds meaningful context: for Z it specifies the allowed range (1-120), and for E it specifies the unit (keV). This significantly aids correct parameter usage beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates the photoionization cross section in barn/atom. The verb 'Calculate' and resource 'photoionization cross section' are specific. However, it does not distinguish from the sibling 'CS_Photo' or other cross-section tools, leaving ambiguity.
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 on when to use this tool versus alternatives like 'CS_Photo' or 'CS_Photo_Total'. No usage context or prerequisites are mentioned.
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 the full burden. It states the tool computes a cross section, which is a read-only calculation, but does not disclose any side effects, data sources, or constraints. With no annotations, more detail would be expected.
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 extremely concise with no wasted words. The purpose and arguments are clearly listed in a front-loaded manner. Every sentence contributes 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?
Given a simple tool with few parameters and an output schema, the description is adequate but lacks context on units (barn/atom) and potential input constraints. It does not explain the 'b' prefix or how this differs from CS_Rayl_CP. Complete enough for basic use but not comprehensive.
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 description coverage is 0%, but the description adds useful meaning: examples for compound ('SiO2', 'H2O') and clarifies that E is photon energy in keV. This compensates for the lack of schema descriptions. The parameter meanings are clear.
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 states it calculates the Rayleigh scattering cross section of a compound in barn/atom. However, there is a sibling tool 'CS_Rayl_CP' and the 'b' prefix is not explained, which may cause confusion. The verb and resource are specific but not fully differentiated.
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 on when to use this tool vs. alternatives like CS_Rayl_CP or CSb_Compt_CP. No context or exclusions are provided. The description is minimal and does not help an agent decide when this tool is appropriate.
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 provided; description only states the calculation, without disclosing side effects, authentication needs, rate limits, or behavior for out-of-range inputs.
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?
Extremely concise: two sentences plus bullet points for parameters; no wasted words and front-loaded with the core action.
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?
Minimally adequate given output schema exists; but lacks differentiation from siblings and does not explain prerequisites or output units, leaving gaps for an agent.
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?
Adds meaning beyond schema by specifying Z range (1-120) and E unit (keV); schema has 0% description coverage, so this information is crucial.
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?
Clearly states it calculates total cross section in barn/atom, but does not differentiate from sibling tools like CS_Total; the 'b' suffix is unexplained.
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 on when to use this tool versus similar siblings such as CS_Total or CSb_Photo; lacks context for selection.
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 full burden but only states the basic calculation. It does not disclose constraints (e.g., compound must be in a database, energy range limits), error handling, or side effects. The behavior is opaque beyond the stated function.
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 extremely concise: a single sentence followed by a parameter list. Every word provides value, and the structure is front-loaded with the core purpose.
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?
Despite having an output schema, the description lacks context for a domain with many siblings. It does not explain what the 'b' or 'CP' mean, nor when to prefer this over other cross-section tools. The unit 'barn/atom' is mentioned but not elaborated.
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 0%, so the description compensates marginally. 'compound' is clarified with examples ('SiO2', 'H2O'), and 'E' is explained as 'Photon energy in keV'. However, no additional syntax or constraints are provided beyond the schema types.
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 action ('Calculate the total cross section of a compound') and specifies the output unit (barn/atom). It differentiates from siblings by explicitly mentioning 'compound', which aligns with the 'CP' suffix and distinguishes it from element-only cross-section tools like CS_Total.
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 the many sibling tools (e.g., CS_Total_CP, CSb_Total). The description does not explain the significance of the 'b' prefix or 'CP' suffix, leaving the agent without context for selection.
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 exist, and the description only states it calculates the cross section. It does not disclose any behavioral traits such as computational cost, input validation, or side effects. The description does not contradict annotations (none provided).
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?
The description is concise, consisting of a single sentence for the functionality and a list of parameters. It is front-loaded and uses clear structure, though the parameter details could be more compactly integrated.
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?
Given the complexity and numerous sibling tools, the description is somewhat complete for a knowledgeable user but fails to explain what 'full cascade' entails or how it differs from other cascade options. The output schema is present, so return format is 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?
The description adds meaning for 'Z' by specifying the range (1-120) and provides examples for 'line', but does not list all valid line names. 'E' is only described as 'Photon energy in keV' with no further details. With 0% schema coverage, the description partially compensates but is not exhaustive.
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 verb 'Calculate' and the resource 'fluorescence line cross section with full cascade using Kissel (cm2/g)'. The tool name and description explicitly distinguish it from sibling tools like CS_FluorLine_Kissel and other cascade variants.
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 (e.g., other cascade types). There is no mention of prerequisites, limitations, or context for choosing this tool.
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 provided, so description carries full burden. It states it calculates a cross section, implying a read-only operation, but lacks information on permissions, computational cost, or the nature of the cascade calculation. The output schema exists but is not 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?
Extremely concise: one sentence for purpose and three lines for parameters. No wasted words, front-loaded with the key action. Ideal length for quick comprehension.
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?
Given the large family of sibling tools with similar names, the description lacks differentiation that would help an agent choose correctly. It covers the basic what and parameters, but not the why or how it differs. The presence of output schema reduces the need to describe returns, but more context on the nonradiative cascade is needed.
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?
With 0% schema description coverage, the description adds valuable parameter meaning: Z range (1-120), line examples (KL3_LINE, KA_LINE), and E units (keV). This helps an agent understand what values to provide, though line could be further detailed.
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?
Description clearly states it calculates fluorescence line cross section with nonradiative cascade using Kissel method, specifying verb and resource. However, it does not explicitly differentiate from siblings like CS_FluorLine_Kissel_Cascade or CS_FluorLine_Kissel_no_Cascade, though the naming convention provides some distinction.
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 on when to use this tool versus alternatives like radiative cascade or no cascade. The description does not explain the concept of nonradiative cascade or indicate prerequisites or context, leaving the agent without decision criteria.
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 provided; description only states the calculation. It does not disclose prerequisites (e.g., valid compound format), error handling, or constraints (e.g., energy range or precision).
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?
Extremely concise: two lines of purpose and two bullet-like parameter explanations. No wasted words, highly scannable, and front-loaded with the main action.
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?
Given an output schema exists, describing return is not needed. However, the description lacks completeness about edge cases, failure modes, or how this tool differs from similar cross-section calculators. It meets minimum viability but leaves gaps.
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%, but description explains both parameters: compound as chemical formula with examples, E as photon energy in keV. This adds meaningful context beyond the bare schema, enabling correct usage.
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?
Description clearly states the tool calculates photoionization cross section in units of cm2/g, specifying the verb and resource. However, it does not differentiate from sibling tools like CS_Photo or CS_Photo_Total, leaving the meaning of the '_CP' suffix unclear.
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 on when to use this tool versus alternatives. With many similar cross-section siblings (CS_Photo, CS_Photo_Total, CSb_Photo, etc.), the description should indicate context or selection criteria.
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 provided, the description carries the full burden of behavioral disclosure. It only specifies parameter ranges (Z: 1-120, E in keV) but fails to mention output format, return values, error conditions, or any side effects. The tool's behavior remains opaque beyond its basic purpose.
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 extremely concise: a single line stating the purpose, followed by a two-line parameter list. Every sentence is necessary, and the key information (what it calculates and the inputs) is front-loaded without any redundant text.
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?
Despite the tool's scientific complexity and lack of annotations, the description omits critical details such as the output format or return value semantics. Although an output schema exists (per context), it is not shown, and the description does not explain what the result represents beyond 'cross section,' making it incomplete for reliable agent use.
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 has no descriptions for parameters (0% coverage), so the description's parameter list adds meaningful context: 'Z: Atomic number (1-120)' and 'E: Photon energy in keV.' This provides valid ranges and units, but no further details like allowed values or constraints beyond type.
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: 'Calculate the Rayleigh scattering cross section of an element (cm2/g).' It includes the specific verb 'calculate' and the resource 'Rayleigh scattering cross section,' which distinguishes it from related siblings like CS_Photo or CS_Compt that compute different cross sections.
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 no guidance on when to use this tool versus alternatives such as CS_Total or CS_Compt. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without context to choose appropriately among many sibling cross-section tools.
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 present, and the description only states the calculation's purpose. It does not mention side effects, input validation, error cases, or output characteristics, leaving the agent without important behavioral 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 extremely concise: one sentence and a bullet list of parameters. No fluff, front-loaded, and efficient for quick understanding.
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 calculation tool with an output schema, the description covers the essentials. However, it lacks context on typical usage scenarios or potential pitfalls (e.g., units must be consistent), which would make it more complete for an AI agent.
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 description adds meaning beyond the schema by providing units (keV, radians) and valid range for Z (1-120). However, it does not specify valid ranges for theta and phi, which would further improve clarity.
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 states it calculates the polarized differential Rayleigh scattering cross section with units. However, among siblings like DCS_Rayl, DCSP_Rayl, and DCSb_Rayl, it does not explain the distinction provided by the 'Pb' prefix (likely barn units), leaving some ambiguity.
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 similar siblings such as DCS_Rayl or DCSP_Rayl. The user must infer from the name and description, which may lead to incorrect tool selection.
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 present, so the description bears full responsibility for behavioral disclosure. It implies a pure calculation with no side effects, but does not explicitly state it is read-only, safe, or what happens with invalid inputs. The return value is not 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 highly concise: one sentence summarizing the purpose, followed by a clean list of parameters with brief explanations. Every word is necessary, and the structure is easy to parse.
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?
Despite an output schema existing (not shown), the description does not explain what the function returns. It also lacks information about error handling, performance, or how this tool relates to similar siblings. The four parameters are standard but edge cases are not addressed.
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 has 0% parameter descriptions, but the description adds meaning: it specifies Z range (1-120), E in keV, theta and phi in radians. However, it omits ranges for E, theta, and phi, and does not clarify any constraints or defaults 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 the tool calculates the polarized differential Rayleigh scattering cross section with units (cm2/g/sr). This specific verb+resource distinguishes it from siblings like DCS_Rayl or DCSP_Compt, which calculate related but different cross sections.
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 DCS_Rayl or DCSP_Compt. The description lacks context about prerequisites, preferred scenarios, or when to avoid using it.
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 burden. It only says 'calculate' without disclosing computational assumptions, error handling, or whether the operation is read-only.
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 sentences plus a parameter list. No wasted words. Front-loaded with the purpose.
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?
Given no annotations and many sibling tools, the description is adequate but lacks details like output format or meaning of 'CP' suffix. An output schema exists but is not described.
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?
With 0% schema coverage, the description compensates by explaining each parameter: compound (chemical formula with examples), E (keV), theta (radians). This adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates differential Rayleigh scattering cross section with units (cm2/g/sr). However, it does not differentiate from sibling tools like DCS_Rayl or DCSb_Rayl_CP, which may have similar names but different purposes.
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 on when to use this tool versus alternatives (e.g., DCS_Rayl). No exclusions or prerequisites provided.
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, description should disclose behavioral traits. Only states basic function; no mention of read-only nature, valid input ranges, or side effects.
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 purpose first, then parameter details. No extraneous content.
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?
Given simple inputs and existence of output schema, description is adequate but does not explain return value. Would benefit from stating what the returned energy represents.
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%, but description adds meaning: Z: atomic number 1-120, shell: e.g., 'K_SHELL'. Good compensation for missing schema descriptions.
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?
Description states 'Get the absorption edge energy for a given shell' with specific verb and resource. Clear but could more explicitly distinguish from similar tools like LineEnergy.
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 on when to use this tool versus alternatives. Does not mention any conditions 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?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, has side effects, or requires specific permissions. It only mentions arguments and ranges, omitting details about return format or computational nature.
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 extremely concise with two clear sentences. It front-loades the purpose and then lists parameter details. No wasted words.
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?
Given the existence of an output schema and two parameters, the description is adequate but minimal. It lacks context about the output's meaning and how this tool fits among numerous sibling tools, which would improve completeness.
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%, so the description adds meaning by specifying valid ranges for Z (1-120) and units for q (1/Angstrom). This is helpful beyond the raw schema types.
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 states 'Calculate the Rayleigh form factor' which is a clear verb+resource. However, it does not distinguish from sibling tools like CS_Rayl or DCS_Rayl, which are related but different.
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?
There is no guidance on when to use this tool versus alternatives. The description provides parameter constraints (Z: 1-120, q in 1/Angstrom) but no context about when to choose FF_Rayl over other similar tools.
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 fully disclose behavior. It only states the basic function without mentioning read-only nature, output structure, or any constraints, leaving significant gaps.
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 concise with two sentences: one for purpose and one for the parameter. No unnecessary words or repetition, making it efficient to parse.
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?
Despite an output schema existing, the description does not explain what 'NIST compound data' entails or the format of the output. This leaves the agent without sufficient context to fully understand the tool's capabilities.
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 description adds 'NIST compound index (0-based)' to the parameter, which clarifies indexing but is minimal. With 0% schema coverage, this provides some necessary context but not comprehensive semantics.
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 'Get NIST compound data by index number', using a specific verb and resource. It distinguishes from siblings like GetCompoundDataNISTList (list) and GetCompoundDataNISTByName (by name).
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 on when to use this tool vs alternatives. With many siblings like GetCompoundDataNISTByName and GetCompoundDataNISTList, the description lacks any contextual cues for selection.
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 provided, and the description lacks behavioral details such as read-only nature, error handling for invalid inputs, or output format. The description is minimal.
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?
Concise, front-loaded with the main purpose, and uses clear formatting. Every sentence is essential.
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 the tool and presence of an output schema, the description covers the essential inputs and purpose. Minor gap: no mention of output structure or potential errors.
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 description adds meaning beyond the schema by specifying valid ranges for Z (1-120) and giving examples for shell (e.g., 'K_SHELL'). This compensates for the 0% schema coverage.
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 states the action ('Get') and the resource ('Auger yield'), with specific parameters (Z, shell). However, it does not differentiate from sibling tools like AugerRate, which may be confused by agents.
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 on when to use this tool vs alternatives. With many similar sibling tools (e.g., AugerRate, FluorYield), explicit usage conditions would help agents decide.
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, and the description does not disclose any behavioral traits such as whether the operation is read-only, side effects, or rate limits.
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 extremely concise: one sentence plus argument list. Every word is earned 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 two parameters. An output schema exists, so return values are covered. However, a bit more context about the Compton profile concept or units of output could help.
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 description adds meaning to parameters: Z is atomic number (1-120), pz is projection of electron momentum in atomic units. This goes beyond the schema which has no descriptions.
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 states 'Calculate the Compton profile for an element' with a specific verb and resource. It is clear, but lacks explicit differentiation from sibling tools like ComptonProfile_Partial.
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 on when to use this tool vs alternatives. No context about prerequisites or when not to use.
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 full burden. It does not disclose behavioral traits such as whether it is read-only, performance characteristics, or edge cases like invalid Z or E. Only basic function 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 extremely concise yet contains the core purpose and parameter details in a clean format. Every sentence is necessary 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?
Given the presence of an output schema (not shown), the description need not detail return values. It covers the tool's function and parameters adequately for a simple cross-section calculator, but completeness is slightly reduced by lack of usage context.
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 description coverage is 0%, so the description compensates by explaining Z as atomic number (1-120) and E as photon energy in keV, adding meaningful semantic context beyond the schema's titles and types.
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 states it calculates the Compton scattering cross section of an element in cm2/g, which is clear. However, it does not distinguish it from sibling tools like CS_KN (Klein-Nishina) or other cross-section tools, so differentiation is lacking.
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 (e.g., CS_KN for free electron scattering). The description only defines parameters without any context on appropriate use cases.
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 mentions the output unit (barn/electron) but omits key details like valid energy range, whether it's differential or total cross section, or assumptions (e.g., free electron).
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 extremely concise with two sentences covering purpose and parameter. Every word adds value, no redundancy.
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?
Given the existence of an output schema (not shown), the description does not need to detail return values. However, the tool is part of a large family of cross-section calculators, and the description lacks context about when this specific model applies (e.g., free electron, relativistic). It is minimally adequate but not comprehensive.
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 0%, so the description must compensate. It states 'E: Photon energy in keV', which adds the unit and clarifies the physical meaning beyond the schema's simple title 'E'. However, it does not specify expected range or format.
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 'Calculate the Klein-Nishina cross section (barn/electron)', specifying the exact quantity and units. This uniquely identifies the tool among siblings like CS_Compt, which may represent a different Compton cross-section model.
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 on when to use this tool versus the many alternative cross-section tools (e.g., CS_Compt, CS_Total). There is no mention of prerequisites, limitations, or recommended scenarios.
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 provided. The description indicates a pure calculation (read-only) but does not disclose potential constraints like valid energy range or numerical stability. The Z range is given, but E and theta ranges are omitted.
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?
The description is concise, front-loading the purpose, then listing parameters. However, it could mention the output unit or behavior for clarity, but overall efficient.
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?
Given the presence of an output schema, the description need not explain return values. It covers parameter ranges and units, but lacks usage guidelines and sibling differentiation. Adequate for a simple tool, but could be more helpful.
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 description coverage is 0%, so the description must compensate. It provides physical meaning, units, and range for Z, and units for E and theta, adding significant value beyond the schema titles.
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 states the tool calculates the differential Compton scattering cross section with units (barn/atom/sr). However, it does not differentiate from similar sibling tools like DCS_Compt or CSb_Compt, which may cause confusion.
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 on when to use this tool versus alternatives. With many similar cross-section siblings, explicit usage context and limitations are missing.
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 provided, so the description carries full burden. It only states the calculation and units, but does not disclose side effects, read-only nature, model assumptions, or valid parameter ranges. Minimal behavioral 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?
Extremely concise: one sentence for purpose, then a brief list of parameters. No redundant words, fully front-loaded.
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?
With an output schema presumably documenting the return value, the description gives the essential context (purpose, units, parameter roles). However, it lacks details on valid compound formats, energy range, or relationship to sibling tools, making it minimally complete.
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 0%, but the description adds meaning by specifying that 'compound' is a chemical formula, 'E' in keV, and 'theta' in radians. This provides context beyond the bare schema, though constraints like allowable energy range are missing.
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 verb 'Calculate', the resource 'differential Compton scattering cross section of a compound', and includes units (cm2/g/sr). It distinguishes from siblings like DCS_Compt (likely for elements) via the '_CP' suffix and explicit mention of compound.
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 on when to use this tool versus alternatives (e.g., DCS_Rayl, DCS_Compt). The description does not mention prerequisites or when not to use it. Given many siblings, explicit differentiation is lacking.
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 provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, side effects, or any constraints. The description only states the calculation purpose, offering no insight into behavior beyond that.
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 extremely concise: one sentence plus a structured list of four arguments. Each sentence or line adds necessary information without redundancy. The argument list is clear and front-loads the 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?
Given the tool's moderate complexity (4 parameters), existence of an output schema, and scientific domain, the description adequately covers the core functionality and parameter semantics. It lacks details on return value structure, but output schema presumably handles that. Missing are usage constraints or typical scenarios.
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?
With 0% schema coverage, the description compensates by providing brief explanations for each parameter: compound as 'Chemical formula, e.g. SiO2, H2O', E as 'Photon energy in keV', theta and phi with units (radians). This adds meaning beyond the schema's type-only definitions.
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 states 'Calculate the polarized differential Compton scattering cross section of a compound (barn/atom/sr)' which uses a specific verb and resource, and the name 'DCSPb_Compt_CP' differentiates from sibling tools like 'DCS_Compt' (likely for elements) and 'DCSP_Compt' (possibly for unpolarized). However, it does not explicitly contrast with siblings.
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 on when to use this tool vs alternatives, no prerequisites, no conditions for use. The description only states what it does, leaving the agent to infer usage context from the name and parameter list.
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 provides minimal behavioral info: it calculates a cross section, but does not disclose whether it is read-only, computational cost, precision, or what happens with invalid inputs.
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?
The description is concise with a one-line purpose and a bullet-like list of parameters. It is front-loaded but could be more compact, e.g., by using inline parameter descriptions.
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?
Despite having an output schema (indicated in context), the description does not mention the output format or units, nor any constraints on inputs. For a tool with four required parameters, this is incomplete.
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 description adds types and units for all four parameters (e.g., 'Photon energy in keV'), compensating for the 0% schema description coverage. It could be more specific on compound format (e.g., case sensitivity).
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 calculates the polarized differential Rayleigh scattering cross section of a compound, with specific verb and resource, and distinguishes from sibling tools like DCS_Rayl or DCSP_Rayl by including the compound aspect.
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 on when to use this tool over siblings; the sibling list includes many similar cross section tools (e.g., DCS_Rayl, DCSP_Rayl, DCSb_Rayl) but the description does not clarify the differences or suggest appropriate scenarios.
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 provided, and the description offers minimal behavioral context beyond the calculation itself. Does not disclose edge cases, interpolation, or limitations.
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?
The description is concise with a clear main line and parameter list. No wasted words, though structure could be improved with a standard format.
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?
Lacks output format details, differentiation from many siblings, and any explanation of the physical calculation nuances. Insufficient for a non-trivial 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?
With 0% schema coverage, the description adds meaning: Z as atomic number (1-120), E in keV, theta in radians. This compensates for the bare schema, though ranges and units could be more explicit.
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 calculates the differential Rayleigh scattering cross section with units (cm2/g/sr), a specific verb and resource. It distinguishes from siblings like DCS_Compt and CS_Rayl.
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 on when to use this tool versus alternatives like DCS_Rayl_CP or DCSb_Rayl. No prerequisites, when-not-to-use, or context for selection.
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 burden. It only states the function without disclosing any behavioral traits (e.g., safety, side effects, rate limits). As a simple retrieval, minimal transparency is acceptable but it adds no value beyond the obvious.
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 extremely concise: two sentences with no filler. It is front-loaded with the purpose and efficiently conveys parameter details.
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 two-parameter tool with an output schema, the description covers the essentials. It could mention that it returns a numeric value, but the output schema likely handles that. Overall, it is sufficiently complete.
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 has 0% description coverage, but the description adds clear semantics: Z is an integer 1-120, shell is a string with examples. This compensates well for the schema's lack of detail.
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 states it retrieves the jump factor for an absorption edge, specifying the verb 'Get' and the resource 'jump factor'. It is specific enough to distinguish from many siblings, though it does not explicitly differentiate from similar tools like EdgeEnergy.
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 no guidance on when to use this tool versus alternatives. With many siblings related to absorption edges, the lack of usage context or exclusions limits its helpfulness for an AI agent.
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 provided. The description mentions 'using Kissel' but does not disclose other behavioral traits (e.g., return format, energy range constraints, or any side effects). For a tool with zero annotations, more behavioral context is needed.
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?
The description is appropriately short and front-loaded with the purpose. The argument list is clear. However, a slightly more structured format could improve readability.
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?
Given the simplicity (2 params, no nested objects) and presence of an output schema, the description is adequate but lacks details on return value format or constraints. It is complete enough for a basic calculator 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 input schema has 0% coverage, but the description adds meaning: compound as 'Chemical formula, e.g. SiO2, H2O' and E as 'Photon energy in keV'. This provides examples and units that are not in the schema, compensating well.
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 it calculates the total photoionization cross section using Kissel, with a specific verb 'Calculate' and resource 'total photoionization cross section' in barn/atom. This distinguishes from sibling tools like CS_Photo_Total which likely uses a different method.
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 on when to use this tool versus alternatives like CSb_Photo_Total or CS_Photo_Total_CP. The description lists arguments but does not specify context or 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, the description carries the full burden. It discloses the calculation and input constraints (Z 1-120, E in keV), but does not mention output format beyond 'barn/atom', data sources, precision, or error handling. 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?
The description is very concise: one sentence for purpose, then a two-line Args list. No unnecessary words, and the key information is front-loaded.
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?
Given the tool's simplicity (two numeric inputs) and the presence of an output schema (not visible), the description covers the basics. However, it lacks context about the tool's place among siblings (bound vs free atom) and what the output represents in practical terms. For a calculation tool, this is adequate but not fully complete.
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%, so the description must add meaning. It explicitly defines Z as atomic number (1-120) and E as photon energy in keV, which adds significant value beyond the schema's type-only fields. However, it omits details like E's valid range or output format details.
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 states the tool calculates the Rayleigh scattering cross section of an element, specifying output in barn/atom. The verb 'Calculate' and resource 'Rayleigh scattering cross section' are precise, but it does not differentiate from sibling tools like CS_Rayl or CSb_Compt, which may have similar purposes.
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 (e.g., CS_Rayl, CSb_Compt). The description focuses solely on parameters without mentioning use cases, 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?
No annotations are provided, so the description carries full burden. It does not disclose behavior beyond the calculation, such as error handling, input validation (e.g., Z range 1-120 not enforced in schema), or whether the tool is safe/read-only. No side effects or dependencies are mentioned.
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?
The description is short and to the point, with a clear function statement followed by parameter definitions. It avoids fluff but could be more structured, e.g., separating the main purpose from args. The example line names are useful.
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?
Given the complexity of the physics domain and numerous sibling tools, the description is incomplete. It does not explain what 'radiative cascade' means, how to choose between this and similar tools, or what the output contains (though an output schema exists). For a specialist, it may suffice, but for AI agents it's insufficient.
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 description adds meaning to all three parameters: Z is atomic number 1-120, line gives examples like 'KL3_LINE', and E is in keV. Schema coverage is 0%, so this compensates. However, it lacks details on accepted line formats or units for E beyond mention.
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 calculates fluorescence line cross section with radiative cascade using Kissel, and gives units (cm2/g). It distinguishes from sibling tools like CS_FluorLine_Kissel (without cascade) and CS_FluorLine_Kissel_Nonradiative_Cascade by specifying 'radiative cascade'. Examples of line names are provided.
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 on when to use this tool versus its numerous siblings (e.g., CS_FluorLine_Kissel_Cascade, CSb_FluorLine_Kissel_Radiative_Cascade, etc.). The description lacks context on prerequisites, assumptions, 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?
No annotations are provided, so the description bears full responsibility. It mentions that the tool calculates a cross section using the Kissel algorithm and radiative cascade, and gives units and argument ranges. However, it does not disclose any behavioral traits such as potential errors, performance, or output format beyond what the name implies.
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 extremely concise: one sentence clarifying the purpose, followed by a clean argument list. No unnecessary words, and the key information is front-loaded.
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?
Given the domain complexity and many sibling tools, the description covers basic constraints but does not explain what the returned cross section value represents or how it might be used. While an output schema exists to fill some gaps, the description could be more complete for a broader audience.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by defining each parameter: valid Z range (1-120), shell examples ('K_SHELL', 'L1_SHELL'), and E units (keV). This adds essential meaning that the schema lacks.
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 states 'Calculate the fluorescence shell cross section with radiative cascade using Kissel (cm2/g)', which includes a specific verb and resource. However, it does not differentiate from sibling tools like CS_FluorShell_Kissel_Cascade or CS_FluorShell_Kissel_Nonradiative_Cascade, missing an opportunity to clarify the unique aspect of 'radiative cascade'.
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?
There is no explicit guidance on when to use this tool versus the many similar siblings. No when-to-use, when-not-to-use, or alternative suggestions are provided. The user must infer from the name alone.
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 bears full responsibility for behavioral disclosure. It only states the calculation without mentioning side effects, read-only nature, or any prerequisite requirements. Minimal transparency.
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 extremely concise: one sentence explaining the tool and two lines for parameters. No wasted words, information is front-loaded.
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 two parameters and an output schema, so the description covers the basics. However, given the large set of sibling cross-section tools, it lacks context about the Kissel method's applicability or limitations, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage was 0%, meaning no parameter descriptions in the schema. The description adds crucial semantics: Z is atomic number (1-120) and E is photon energy in keV. This fully compensates for the missing schema descriptions.
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 states the tool calculates total cross section using Kissel photoionization with units cm2/g. However, it does not differentiate from sibling tools like CS_Total that may use other methods, so clarity is good but not fully distinguishing.
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 lists required parameters and their ranges but provides no guidance on when to use this Kissel variant versus other cross-section tools among the many siblings. No explicit when-to-use or when-not-to-use information.
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 provided. Description only says 'calculate', implying a read operation, but no disclosure of side effects, error handling, or output format. For a parameterized calculation, more transparency about validation or constraints is expected.
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?
Description is concise with a one-line purpose and a clear args block. No superfluous content, though the args style is code-like rather than natural language. Still efficient.
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?
With no output schema shown (but known to exist), and 3 parameters without enums, the description covers the basics but lacks usage context and behavioral details. Missing mention of limitations or when to use this specific variant.
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 description coverage is 0%, but the description adds meaning beyond the schema by specifying units (keV, radians) and providing an example for compound (e.g., 'SiO2'). This compensates for the lack of schema documentation.
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?
Description clearly states it calculates differential Compton scattering cross section for a compound (barn/atom/sr). Among siblings, many similar tools exist (e.g., DCSb_Compt, DCS_Compt_CP), and the explicit mention of 'compound' differentiates from element-specific variants.
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 on when to use this tool vs siblings like DCSb_Compt (likely for elements) or DCS_Compt_CP. Does not state when it is appropriate or when alternatives are preferred.
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 describes a pure calculation without side effects, which is acceptable, but it does not explicitly state that it is read-only or non-destructive. The output schema exists but the description does not hint at return structure or units beyond the parameter units.
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 extremely concise: one sentence for purpose plus a clean parameter list. No redundant information. Every part 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?
Given the tool has 4 parameters and an output schema, the description covers the basics but lacks usage context and differentiation from many sibling tools. It is adequate for a simple calculation, but could be more complete with examples or links to related tools.
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%, so the description provides essential context: Z range (1-120), E in keV, theta and phi in radians. This adds meaning beyond the bare schema titles. However, it could specify ranges for angles and note that all inputs are required.
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 states it calculates the polarized differential Compton scattering cross section. The verb 'calculate' and specific resource name make the purpose unambiguous. It distinguishes from siblings like DCS_Compt (unpolarized) and DCSP_Compt (possibly similar), though not explicitly.
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 on when to use this tool versus the many sibling tools. There is no mention of prerequisites or alternatives, leaving the agent without context for selection.
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 provided, so description carries full burden. It does not disclose computational cost, return format, or side effects beyond basic behavior. Only states the calculation and units.
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?
Description is short and front-loaded with the main purpose. The bullet-style arg list is clear and efficient. A minor improvement could be combining the list into a more natural flow.
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 output schema exists (not shown), the description adequately covers inputs and return unit. It could include an example or mention of output format, but overall it is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by providing clear, detailed meanings for all four parameters: compound (with examples), E (energy in keV), theta (polar angle in radians), phi (azimuthal angle in radians). Each parameter is well-defined.
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 states the verb 'Calculate' and the resource: 'polarized differential Compton scattering cross section of a compound' with units. It distinguishes from siblings by specifying 'compound', but could explicitly differentiate from similar tools like DCSP_Compt.
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 on when to use this tool vs alternatives like DCSP_Compt or DCS_Compt. The description implies usage for compounds but does not provide explicit context 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?
No annotations are present, so the description must disclose behavior. It does not mention safety, side effects, or error handling (e.g., out-of-range Z). It implies a read-only calculation but does not confirm.
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?
The description is concise, with a clear one-sentence purpose followed by parameter explanations. It is front-loaded and wastes no words, though the parameter details could be more structured.
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?
Given the output schema exists, return values are covered. However, for a tool among many siblings, the description could better differentiate usage. It provides the essential information but lacks depth on behavior and context.
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 description provides explicit meaning for both parameters: Z's range (1-120) and E's unit (keV), which are absent from the schema's titles. This adds significant value beyond the schema, despite zero schema description 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 explicitly states the tool calculates the real part of the anomalous scattering factor (delta f'), a specific verb+resource. It distinguishes itself from siblings like 'Fii' (likely imaginary part) and other atomic physics functions through the naming and mention of delta f'.
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, nor any context about prerequisites or conditions. The description only states the purpose without any usage direction.
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 only states 'List all available...', offering no additional behavioral details such as data freshness, rate limits, or that it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no wasted words, though it borders on under-specification.
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?
Given the simplicity (no params, output schema exists), the description is minimally complete, but could hint at return structure to better assist selection among many sibling list tools.
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 no parameters, so per rules the baseline is 4. No further semantics needed.
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 'List all available NIST compound constant names' uses a specific verb (List) and resource (NIST compound constant names), clearly distinguishing it from sibling list tools like ListLineConstants or ListShellConstants.
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, nor any context about prerequisites or constraints.
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 full burden but only notes the input range (1-120). It does not disclose error handling (e.g., out-of-range values), return format, or whether the operation is pure/lookup. This is insufficient for a tool with no other behavioral hints.
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?
Extremely concise: one sentence and an Args line. Front-loaded with the core purpose. Every word is useful, no fluff.
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 (one param, clear output), the description is nearly complete. It states the input range and the conversion purpose. The existence of an output schema (not shown) removes the need to explain return format. Minor gap: no mention of error behavior for out-of-range inputs.
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 has 0% coverage, so the description's 'Atomic number (1-120)' adds crucial meaning beyond the schema. It clarifies the valid range, which is essential for correct usage. However, it could be more explicit about inclusive bounds and what happens for invalid inputs.
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 states it converts an atomic number to element symbol, which is clear and specific. However, it does not explicitly distinguish it from the sibling tool SymbolToAtomicNumber, though the inverse relationship is obvious from the name.
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 have an atomic number and need the symbol, but it gives no explicit when-to-use or when-not-to-use guidance compared to alternatives like SymbolToAtomicNumber.
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?
Since no annotations are provided, the description carries the full burden. It implies a read-only computation, but does not explicitly state non-destructiveness or safety. The parameter constraints (Z range 1-120) add minimal transparency.
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 extremely concise with two sentences, front-loading the purpose. Every word is informative; no extraneous content.
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 an output schema (not shown), so return values are presumably documented there. The description covers inputs adequately for a simple probability getter, but lacks details on output format or units. It is sufficient but not thorough.
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 0% schema description coverage, the description adds value by specifying Z's range (1-120) and providing example transition names. However, it does not enumerate or explain all possible transitions, so it partially compensates.
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 the Coster-Kronig transition probability, using specific verb 'Get' and resource. This distinguishes it from sibling tools like LineEnergy or FluorYield.
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 on when to use this tool over alternatives (e.g., RadRate or AugerYield) or context for valid transitions. The description merely states the function without usage conditions.
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 full burden but only describes the calculation, units, and parameters. It does not disclose any side effects, error behavior, permissions, or limitations (e.g., what happens if parameters are out of range), leaving significant behavioral gaps.
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 brief, with two sentences: the first clearly states the purpose, and the second lists the arguments succinctly. Every sentence is necessary and informative, with no 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?
Given the tool has 3 parameters and an output schema, the description adequately covers inputs. However, it does not clarify how this tool relates to similar siblings, which would help in a crowded toolset. The output is not described, but since an output schema exists, that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds essential meaning to all three parameters: Z with range (1-120), line with examples (KL3_LINE, KA_LINE), and E with units (keV). Since schema description coverage is 0%, this fully compensates and provides clear guidance for correct invocation.
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 states it calculates fluorescence line cross section with radiative cascade using Kissel, specifying verb, resource, method, and units. However, it does not differentiate itself from numerous similar sibling tools like CSb_FluorLine_Kissel_Cascade, which could also imply radiative cascade, reducing clarity in distinguishing its exact function.
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 the many alternatives in the sibling list. There is no mention of prerequisites, context, or exclusions, leaving the agent to guess the appropriate selection among similar tools.
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 must disclose behavioral traits, but it only provides parameter descriptions and the unit. It does not mention error handling, valid shell name ranges, or what happens for invalid inputs (e.g., Z out of 1-120). This is insufficient for a scientific calculation 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 succinct: one sentence for purpose and three bullet points for arguments. No redundant phrases, and the key information is front-loaded.
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?
Given the output schema exists, return values are covered. However, the description lacks usage guidelines and behavioral transparency, which are needed due to no annotations and many sibling tools. It is adequate but not comprehensive.
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% (no property descriptions), but the description adds meaning for all three parameters: Z range (1-120), shell examples, and E unit (keV). This compensates well, though a list of valid shell names would improve clarity.
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 calculates a fluorescence shell cross section with nonradiative cascade using Kissel, with unit barn/atom. This specific verb-resource combination distinguishes it from siblings like CSb_FluorShell_Kissel or CSb_FluorShell_Kissel_Radiative_Cascade.
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. Given many siblings with similar names, the description does not clarify scenarios where nonradiative cascade is appropriate or how it differs from radiative or general cascade.
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 indicates a read-only computation ('calculate'), which implies no side effects, but does not disclose potential constraints, data sources, or error conditions. This is adequate but minimal for a calculation 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 extremely concise: one sentence plus an argument list. Every sentence is necessary and front-loaded with the core action. No superfluous content.
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 presence of an output schema (not shown) and no annotations, the description covers the essential inputs, output unit, and a basic example. It could mention valid shell-Z combinations or energy ranges, but it is sufficient for a well-defined computational 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?
Schema description coverage is 0%, but the description compensates by explaining each parameter: Z as atomic number (1-120), shell with example values, E as photon energy in keV. This adds meaning beyond the schema types and enables correct usage.
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 states the verb 'Calculate' and the resource 'fluorescence shell cross section with radiative cascade', including units (barn/atom). It is specific enough, though it does not explicitly differentiate from sibling tools like CS_FluorShell_Kissel or CS_FluorShell_Kissel_Nonradiative_Cascade; the name already signals the radiative cascade variant.
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 no guidance on when to use this tool versus the many sibling tools (e.g., CS_FluorShell_Kissel_no_Cascade). It lacks context for selection, such as scenarios requiring radiative cascade or conditions to avoid.
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 provided, and description does not disclose behavioral traits such as whether it is read-only, requires authorization, or has side effects. It only states the calculation purpose.
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?
Extremely concise: two lines of description plus parameter list. Every word serves a purpose, no redundancy.
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?
While the description covers core functionality, it lacks details about output format, valid energy range, or relationship to sibling tools. Given the large number of sibling tools, more context would help distinguish.
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 has 0% description coverage, so description adds value by clarifying Z is atomic number (1-120) and E is photon energy in keV, which is not 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?
Description clearly states the tool calculates total photoionization cross section using Kissel method in barn/atom, with parameter descriptions. The name 'CSb_Photo_Total' and mention of 'Total' distinguishes it from sibling tools like 'CSb_Photo_Partial'.
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 on when to use this tool versus alternatives like partial cross section tools or other methods. Does not specify prerequisites or context for use.
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, and the description only states the function. It does not disclose behavioral traits like read-only nature, required permissions, or side effects, leaving the agent to infer.
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 extremely concise, front-loading the core purpose in one sentence, followed by parameter definitions. No unnecessary words.
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 covers the essential inputs but does not mention output behavior. Since an output schema exists, this is partially mitigated, but the tool's role among many similar siblings suggests a need for more context.
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 description adds meaning to both parameters: Z range (1-120) and E units (keV), which are absent from the input schema. This aids correct invocation.
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 explicitly states the tool calculates total cross section using Kissel photoionization in barn/atom, with clear inputs. This differentiates it from siblings like CS_Total or CSb_Total by specifying the Kissel method.
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 on when to use this tool versus alternatives. With over 100 sibling tools covering various cross-section calculations, explicit when-to-use and when-not-to-use is missing.
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 exist, and the description does not disclose any behavioral traits such as energy range validity, accuracy, error handling, or whether it is a pure calculation or has side effects. For a scientific tool, this is insufficient.
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 concise sentences with no unnecessary words. Front-loaded with purpose, followed by parameter definitions.
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?
There is an output schema (not shown), so return value details are not required. However, the description lacks context on how this tool relates to siblings and any usage caveats. Adequate but could be improved.
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%, but the description provides clear semantics: 'compound' is a chemical formula with examples, and 'E' is photon energy in keV. This adds meaning beyond the raw 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 it calculates total cross section using Kissel photoionization, specifies units (barn/atom), and distinguishes from sibling tools that calculate other cross sections or use different methods.
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 explicit guidance on when to use this versus the many sibling tools (e.g., CS_Total_Kissel_CP). No prerequisites or exclusions mentioned.
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 must disclose all behavioral traits. It only states the calculation purpose and units. It does not mention computational complexity, input validation, error handling, or any side effects. The existence of an output schema is not leveraged in the description, and no behavioral constraints are provided beyond the basic operation.
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 extremely concise: one sentence for the purpose, followed by a bulleted parameter list. It front-loads the key action and units. No extraneous information is present, and every sentence serves a clear 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?
Given the tool's complexity (part of a large family with many cross-section variations) and the absence of annotations, the description is minimally adequate. It states the calculation and units, but lacks details on output format, interpretation, or constraints like energy ranges. Since an output schema exists, it does not need to describe return values, but the description does not reference it or provide confidence in the result's shape.
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?
Input schema provides 0% description coverage, but the tool description compensates well: it explains Z as atomic number 1-120, shell with examples like 'K_SHELL' and 'L1_SHELL', and E as photon energy in keV. This adds meaningful context beyond the parameter names alone, though a more exhaustive list of valid shell names would improve 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 clearly states the tool calculates fluorescence shell cross sections with full cascade using the Kissel method, specifying units (cm2/g). Among many sibling tools with similar names (e.g., CS_FluorShell_Kissel without cascade, CS_FluorShell_Kissel_Nonradiative_Cascade, etc.), this description uniquely identifies the 'full cascade' variant, providing strong 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?
No guidance is provided on when to use this tool versus the many alternative cascade variations or other cross-section tools. The description does not mention when full cascade is appropriate, nor does it differentiate between radiative/nonradiative cascades or other outputs (e.g., CSb versions). This leaves the agent to infer usage from the name alone.
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 provided, so description must carry full burden. Only states it 'calculates' a value; no disclosure of limitations, prerequisites, edge cases, or behavior beyond the calculation. Minimal behavioral insight.
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?
Extremely concise: two-line description plus argument list with no extraneous content. Every sentence serves a purpose.
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?
Given complexity of domain with many sibling tools, description is minimal. Does not explain 'without cascade' distinction or return value (though output schema exists). Adequate but could provide more scientific context.
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 0%, so description must compensate. Description lists parameters and gives some meaning: Z with range (1-120), shell with examples, E with unit (keV). However, shell does not list all valid values, and no constraints on E. Adds some value but insufficient for full parameter understanding.
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?
Description clearly states verb 'Calculate', resource 'fluorescence shell cross section', method 'using Kissel', units 'cm2/g', and qualifier 'without cascade'. This precisely distinguishes it from sibling tools like CS_FluorShell_Kissel_Cascade.
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?
No explicit when-to-use or when-not-to-use guidance, but the description and name imply it is for Kissel-based shell cross sections without cascade. Lacks exclusions or alternatives compared to similar tools.
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 the full burden. It only states the calculation purpose without disclosing side effects, prerequisites, or limitations (e.g., energy range restrictions).
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 extremely concise with two sentences and a docstring, containing no unnecessary words while covering purpose and arguments.
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 explains the calculation and parameters, but given the many sibling tools like CS_Photo and CS_Photo_Partial, it lacks differentiation context. The presence of an output schema reduces the need to explain returns, but the description could still be more helpful for selection.
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%, but the description adds meaning by specifying Z as atomic number 1-120 and E as photon energy in keV, which is essential for correct parameter usage.
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 specific verb 'Calculate' and resource 'total photoionization cross section using Kissel (cm2/g)', distinguishing it from siblings like CS_Photo (partial) and CSb_Photo_Total (bound).
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 CS_Photo or CS_Photo_Partial. There is no mention of exclusions or preferred use cases.
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 provided, and the description adds minimal behavioral context. It states units (cm2/g) but does not disclose return format, any side effects, or limitations like valid energy ranges beyond the parameter description.
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?
Extremely concise: two-line description plus parameter list. No wasted words, front-loaded with the core action.
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?
Given the many sibling CS tools and no output schema visible, the description is adequate but could specify what the total cross section includes (e.g., sum of photo, Compton, Rayleigh) and any other assumptions.
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%, but the description compensates by explaining each parameter: Z atomic number (1-120) and E photon energy in keV. This adds meaningful context beyond the bare schema titles.
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 it calculates the total cross section of an element in cm2/g, with specific verb 'Calculate' and resource 'total cross section'. It distinguishes from siblings like CS_Photo, CS_Compt, etc., which handle partial cross sections.
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 on when to use this tool versus alternative CS tools (e.g., CS_Total_Kissel, CS_Photo). No exclusions or alternatives mentioned, leaving the agent to infer.
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 must disclose behavioral traits. It only states the calculation, without mentioning side effects, permissions, or output format. It implies a read-only computation but does not confirm safety or non-destructiveness.
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 very concise: one line for purpose followed by a clean list of parameters. Every sentence adds value, and the key information is front-loaded.
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 defines the tool's purpose and parameters adequately, but omits the output format (though output schema exists, it is not shown). For a calculation tool, additional context like precision or units of the result would improve completeness.
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 has 0% description coverage, but the description adds meaningful context for each parameter: atomic number Z (1-120), photon energy E in keV, and scattering angle theta in radians. This clarifies units and valid ranges beyond the schema's type definitions.
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 action: 'Calculate the differential Rayleigh scattering cross section' with units (barn/atom/sr). The tool name DCSb_Rayl aligns with this and distinguishes it from similar tools like DCS_Rayl.
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 like DCS_Rayl or DCS_Compt. The description only states what it does, not the context for choosing it.
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 exist, so the description must fully disclose behavior. It states the calculation and parameter constraints but does not mention the return format, side effects, or any restrictions beyond parameter ranges. The existence of an output schema is unused in the description.
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 extremely concise: one sentence explaining the purpose plus a clear parameter list. No redundant information.
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?
Given that an output schema exists (not shown), the description need not detail return values. However, it lacks any context about physical basis (e.g., Klein-Nishina), typical use cases, or how it relates to siblings. Still adequate for a straightforward calculation 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?
Schema description coverage is 0%, but the description adds meaningful context: Z range 1-120, E in keV, theta in radians. This goes beyond the schema's type-only definitions, though more parameter details (e.g., valid ranges for E) could improve clarity.
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 calculates the differential Compton scattering cross section with units (cm2/g/sr), and the name distinguishes it from total Compton (CS_Compt) and other differentials (DCS_Rayl). It uses a specific verb and resource.
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, nor are there any prerequisites or exclusions mentioned. The description only states the calculation without context.
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 exist, so the description carries full burden. It only states the calculation but does not disclose any behavioral traits such as input validation, error handling, performance characteristics, or side effects. The agent cannot predict tool behavior beyond the basic function.
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?
The description is concise: one sentence stating purpose followed by a parameter list. It front-loads the key information. However, the parameter list partially duplicates the schema, though it adds value with units and ranges.
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 essential computational purpose but lacks usage context, limitations, or behavioral details. Given the tool's complexity (4 parameters, many siblings) and absence of annotations, more contextual information would be needed for safe and correct invocation. However, the presence of an output schema partially mitigates the need for return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the parameter list in the description adds crucial semantic details: units (keV, radians), allowed range for Z (1-120), and explicit mapping of Greek letters to parameter names. This compensates fully for the schema's lack of 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 explicitly states the verb 'Calculate' and the resource 'polarized differential Compton scattering cross section' with units. It differentiates this tool from sibling tools like DCS_Compt (non-polarized) and CS_Compt (total cross section) through the term 'polarized'.
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 vs alternatives. With many similar sibling tools (e.g., DCSP_Rayl, DCS_Compt), the agent lacks context for selection. No when-to-use, when-not-to-use, or prerequisites are mentioned.
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 exist, so the description carries full burden. It does not disclose any behavioral traits such as being read-only, required permissions, side effects, or assumptions. It only states what it calculates, not how it behaves.
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 concise: one sentence for purpose followed by a clean list of arguments. Every sentence adds value with no redundancy.
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?
Although output schema exists (so return values may be documented there), the description lacks context about when to use this specific variant (_CP) over siblings, and does not cover edge cases or typical usage patterns. It is adequate for a simple calculation tool but not comprehensive.
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 description adds meaning by specifying units (keV, radians) and format for compound (chemical formula). Schema coverage is 0%, so the description compensates significantly. However, it lacks constraints or ranges for parameters like E, theta, phi.
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 calculates 'polarized differential Rayleigh scattering cross section' with a specific verb 'calculate' and resource, and includes units. It distinguishes from siblings like DCS_Rayl and DCSP_Rayl by specifying polarization and compound.
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 the many sibling tools (e.g., DCS_Rayl, DCSP_Rayl). The description does not mention prerequisites, limitations, or context for invocation.
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 basic function without mentioning error handling, data completeness, or any side effects. The description adds little 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 extremely concise, with one line for the purpose and one for the parameter. It is front-loaded and contains 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?
The tool has an output schema, so return values need not be described. However, the description lacks details on when to use this tool, what data is included, and typical failures. It is minimally adequate.
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 parameter 'name' is described with examples ('Water, Liquid', 'Air, Dry (near sea level)'), which adds meaningful context beyond the schema's type 'string'. Given 0% schema coverage, the description compensates well.
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?
Description states the tool retrieves NIST compound data using a compound name. The action ('Get') and resource ('NIST compound data') are clear, and the method ('by compound name') distinguishes it from sibling tools like GetCompoundDataNISTList and GetCompoundDataNISTByIndex.
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 on when to use this tool versus alternatives such as GetCompoundDataNISTByIndex or GetCompoundDataNISTList. The description does not provide context on prerequisites or preferred use cases.
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, and the description only says 'Calculate,' which implies a read-like operation but does not disclose potential side effects, computational costs, authentication needs, or required data sources. The description fails to clarify behavioral traits.
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 extremely concise: one sentence for purpose and a structured Args list. Every element is necessary and there is no redundancy. It is well-suited for quick scanning by an AI agent.
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?
While the description specifies parameters adequately, it lacks information about output format, typical ranges for inputs, or domain constraints (e.g., valid energy range for the calculation). Given the tool's scientific nature and the presence of an output schema, more context would improve completeness, but it is minimally adequate.
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 lacks descriptions for all three parameters (coverage 0%), but the tool description compensates by providing meaningful explanations for each parameter: 'chemical formula', 'photon energy in keV', 'density in g/cm3'. This adds critical context 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 explicitly states the action 'Calculate' and the resource 'imaginary part of the refractive index of a compound.' The name and description clearly differentiate it from the sibling tool 'Refractive_Index_Re' which computes the real part.
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 no guidance on when to use this tool versus alternatives, no prerequisites (e.g., compound database availability), and no exclusions. It simply states what it does without contextual usage advice.
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 exist, so description must carry full burden. It does not disclose input validation, case sensitivity, error handling, or return value format beyond the basic conversion.
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?
Extremely concise: two sentences with a clear docstring format. Every word adds value, and the structure is efficient.
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 conversion tool, the description is adequate but lacks context about when to use it among many siblings. With an output schema present, the return value is documented elsewhere, but the description could mention the expected output type.
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?
Single parameter 'symbol' is described with examples ('Fe', 'Cu', 'Au'), adding format context beyond the schema's empty description. This helps the agent construct valid 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?
Description explicitly states the purpose: 'Convert an element symbol to its atomic number.' It uses a specific verb and resource, and clearly distinguishes from the sibling tool AtomicNumberToSymbol which does the reverse.
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 on when to use this tool vs alternatives. The description provides examples but no context for selection among many sibling tools.
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 does not mention any assumptions (e.g., free electron at rest), limitations (energy range), or side effects. The minimal description fails to inform the agent about important behavioral context beyond the basic calculation.
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?
The description is concise, with a single sentence for purpose followed by a clear parameter list. It is front-loaded with the main action. However, it could be slightly improved by including the output description, but overall it is efficient and well-structured.
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?
Given the tool's simplicity (two numeric inputs, standard physics calculation), the description provides the essential information for the calculation. However, it lacks the output unit or format, and does not mention physical assumptions. An output schema exists but its content is unknown; the description could complement it with a brief note on the return value.
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 has 0% description coverage, so the description must add meaning. It successfully clarifies that E0 is incident photon energy in keV and theta is scattering angle in radians, which are essential details not present in the schema. The description compensates well for the lack of schema property 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 clearly states the specific calculation: 'Calculate the photon energy after Compton scattering.' The verb 'calculate' and the resource 'photon energy after Compton scattering' are precise, and the tool is distinct from siblings like CS_Compt (cross section) and ComptonProfile.
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 by describing what the tool does, but it provides no explicit guidance on when to use it versus alternative tools (e.g., CS_Compt for cross sections, ComptonProfile for profiles). Given the large number of sibling tools, explicit when-to-use advice would be beneficial.
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 must disclose behavioral traits. It only states the calculation and gives parameter constraints. It does not mention whether the operation is safe (read-only), what the output represents, or any edge cases (e.g., invalid shells).
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 extremely concise, with a clear one-line purpose followed by a terse argument list. Every sentence adds value, and the structure is 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?
Given that an output schema exists (not shown), the description is adequate. It defines all required parameters and their roles. However, it could briefly note how this differs from the full ComptonProfile tool or mention the return value type.
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 description coverage is 0%, so the description compensates well: it explains pz as 'Projection of the electron momentum in atomic units', provides example shell values (e.g., 'K_SHELL', 'L1_SHELL'), and gives the expected range for Z (1-120). This adds meaning beyond the bare 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 the action ('Calculate'), the resource ('partial Compton profile'), and the scope ('for a shell of an element'). It distinguishes from the sibling ComptonProfile tool by specifying 'partial' and 'shell'. This is specific and unambiguous.
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 like ComptonProfile, ComptonEnergy, or other related tools. The description does not mention any prerequisites, limitations, or context for usage.
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 discloses the formula (Kissel), the unit (barn/atom), and the cascade type (nonradiative). However, it does not describe output structure (though an output schema exists) or behavior on invalid inputs (e.g., invalid line name). It 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence plus a structured bullet list. It front-loads the main action. It could be slightly improved with better formatting (e.g., markdown), but it's efficient and easy 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?
Given the abundance of sibling tools and the existence of an output schema, the description covers the basics but lacks context on when to use this specific variant. It does not mention error handling or valid line names beyond examples. It is adequate for a simple tool but not fully comprehensive.
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 Args section adds meaning beyond the raw schema: Z is explained as 'Atomic number (1-120)', line includes examples ('KL3_LINE', 'KA_LINE'), and E is 'Photon energy in keV'. This compensates for the 0% schema description coverage and clarifies constraints and format.
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 'Calculate the fluorescence line cross section with nonradiative cascade using Kissel (barn/atom).' It uses a specific verb ('calculate') and resource ('fluorescence line cross section'), and distinguishes this tool from siblings like CSb_FluorLine_Kissel_Cascade (which includes radiative cascade) and CSb_FluorLine_Kissel_no_Cascade by specifying 'nonradiative cascade'.
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 sibling tools (e.g., when to choose nonradiative cascade over radiative or no cascade). There are no explicit usage conditions 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?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic function. It does not mention side effects, permissions, or any constraints.
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 extremely concise with two sentences: one for purpose and one listing arguments with examples. No wasted words.
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 that an output schema exists, the description does not need to explain return values. It covers the essential inputs and purpose, though it could explicitly state the output unit (cm2/g) again.
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 0%, so the description must compensate. It adds context: 'compound' is a chemical formula with examples, and 'E' is photon energy in keV. This is helpful but minimal.
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 'Calculate the Compton scattering cross section of a compound (cm2/g)', specifying the verb, resource, and units, distinguishing it from sibling tools like CS_Compt (presumably for elements).
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?
Usage context is implied via the 'compound' parameter and the tool name (CP for compound), but there is no explicit guidance on when to use this versus alternatives like CS_Compt or CS_Compt_CP variants.
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 adds that the output is in cm2/g, which is useful. However, with no annotations and no mention of side effects or state changes, it does not fully disclose behavioral traits. Since it is a calculation tool, read-only nature is implied but not explicit.
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?
The description is concise with no redundant phrases. It uses a clear header for the purpose and a list for parameters. The structure is efficient, though the parameter list could be slightly more compact.
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?
Given the large number of sibling tools focusing on fluorescence lines, the description fails to provide context about when this specific tool is appropriate (e.g., which model or database it uses). The existence of an output schema partially mitigates the need for output format description.
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?
Despite 0% schema coverage, the description provides meaningful details for each parameter: Z's integer range (1-120), line with examples ('KL3_LINE', 'KA_LINE', 'LA1_LINE'), and E's unit (keV). This compensates for the schema's lack of 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 clearly states it calculates the fluorescence line cross section in cm2/g, specifying the exact physical quantity and units. It distinctly separates from sibling tools like CS_FluorShell (which is for shells) and CS_FluorLine_Kissel (which uses a different method).
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 on when to use this tool versus the many similar siblings (e.g., CS_FluorLine_Kissel, CSb_FluorLine). The description does not mention any prerequisites, limitations, or compare with alternatives, leaving the agent to guess the appropriate selection.
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 full burden but only states the function and inputs. It does not disclose side effects, prerequisites, output format (though output schema exists), or constraints beyond Z range in Args. Minimal transparency.
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?
Extremely concise: two sentences for the function and clear bullet list for parameters. No wasted words; every sentence serves a purpose.
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?
Though output schema exists, the description omits clarifications about valid line names (only two examples), potential errors, or how this Kissel variant differs from non-Kissel or cascade siblings. Adequate but not comprehensive given sibling complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description compensates well: specifies Z as atomic number, line with examples (e.g., 'KL3_LINE'), and E with unit 'keV'. This adds meaningful context the schema lacks.
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 calculates a fluorescence line cross section using Kissel photoionization, specifying the unit (cm2/g). It distinguishes from siblings by including 'Kissel' and providing the method, making the purpose unambiguous.
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 the many siblings (e.g., CS_FluorLine or cascade variants). The description only lists inputs, leaving the agent to infer usage from context.
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 fully disclose behavioral traits. It only states what the tool does and lists parameters. It does not mention data source, accuracy, expected precision, or any side effects. For a physical calculation tool, this is insufficient transparency.
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 very short and to the point. It first states the purpose in one sentence, then lists parameters. Every sentence is necessary. No wasted words.
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 output schema exists, return values need not be described. The description is fairly complete for a simple calculation tool: it specifies input format and energy unit. However, it could mention that the compound is parsed using CompoundParser (since sibling tools exist) or that valid energies are positive. Still, the core is 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 0% (no descriptions in schema), but the description adds meaning: compound is a chemical formula (examples given), E is in keV. This adds value beyond the schema but does not fully compensate for missing parameter details (e.g., allowed compound formats, value range for E).
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 calculates the Rayleigh scattering cross section of a compound with units (cm2/g). It includes the required parameters and their formats. This distinguishes it from similar tools like CS_Rayl (likely for elements) and CSb_Rayl_CP (coherent scattering).
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 lists the required parameters (compound, E) but does not explain when to use this tool over alternatives like CS_Rayl or CS_Total_CP. There is no guidance on constraints or prerequisites (e.g., valid compound list). Usage context is implied but not explicit.
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 present, and the description merely restates the tool's basic function without detailing return structure, side effects, or safety (though likely read-only).
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 extremely brief (two lines) with no unnecessary information, earning every word's place.
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 one-parameter tool with an output schema, the description is adequate but could hint at the return structure to improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the sole parameter 'index' by explicitly stating it is 0-based and a radionuclide index, which is absent 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 clearly states the tool retrieves radionuclide data by index number, distinguishing it from siblings like GetRadioNuclideDataByName and GetRadioNuclideDataList.
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 when to use index vs. name lookup.
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 provided, so the description must carry the full burden. It only states 'Get', implying a read operation, but does not disclose any behavioral traits like authorization needs, rate limits, or error handling. The minimal description leaves many behavioral aspects unaddressed.
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 extremely concise with two short paragraphs. The main purpose is front-loaded, and the parameter descriptions are succinct and informative, with 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 and the presence of an output schema, the description is fairly complete. It explains the two inputs adequately. The output schema likely covers return format, so the description need not detail it further. The only minor gap is the lack of units or exact return type, but this is acceptable.
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 no descriptions (0% coverage), so the description adds essential meaning. It provides a valid range for Z (1-120) and examples for line (e.g., 'KL3_LINE', 'KA_LINE'), significantly improving usability over the bare 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 'Get the radiative rate for a given fluorescence line', using a specific verb and resource. It distinguishes itself from sibling tools like FluorYield or AugerRate by naming the exact quantity.
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 on when to use RadRate versus alternatives. There is no mention of prerequisites or scenarios where this tool is preferred over similar tools, such as CS_FluorLine or FluorYield.
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 responsibility for behavioral disclosure. It only states the basic function without mentioning read-only nature, error cases, or output format (though output schema exists). The description adds minimal behavioral 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?
Extremely concise: two sentences with clear structure. No superfluous information. The main action is front-loaded in the first line, followed by parameter details.
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 lookup tool with a single parameter and an output schema provided, the description is largely sufficient. It lacks error handling details but covers the core functionality adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by defining Z as atomic number with a valid range (1-120), which is not present in the input schema (only type integer). This adds essential meaning.
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 'Get the atomic weight of an element' with a parameter Z for atomic number. It distinguishes itself from sibling tools like ElementDensity or AtomicNumberToSymbol by focusing solely on atomic weight.
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 on when to use this tool versus alternatives. There is no mention of context, prerequisites, or when not to use it. With many sibling tools, explicit usage guidelines are missing.
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 burden. It lacks behavioral details such as valid energy range, error handling, or limitations. Being a computational tool, it likely has constraints not disclosed.
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 very concise: one sentence for purpose and two lines for parameters. No wasted words, front-loaded with key information.
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?
With an output schema present, description does not need to specify return values. However, it lacks context on energy range, compound format restrictions, or when to use this over similar tools. Adequate but not comprehensive.
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?
With 0% schema coverage, the description adds value by explaining both parameters: compound with example formulas and E with unit 'keV'. This goes beyond the schema's type definitions.
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 calculates total cross section of a compound using Kissel photoionization, with units. It is specific and distinguishes from sibling tools like CS_Total_Kissel (likely for elements) by explicitly mentioning compound.
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 does not provide guidance on when to use this tool versus its many siblings. It implies compound usage but lacks explicit when-to-use or when-not-to-use advice.
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. The description is minimal and does not disclose side effects, performance, or assumptions. However, the tool performs a straightforward calculation, and the output schema likely documents return format. Additional context like units or range limits would improve transparency.
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 plus an argument list, front-loaded with purpose. Every word is informative; no fluff. Highly efficient.
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?
Given no annotations and 0% schema coverage, the description is basic but covers the core functionality. It does not provide examples, range constraints, or mention the output format (though output schema exists). For a simple calculation tool, it is adequate but could be more informative, especially given the many sibling tools.
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 description coverage is 0%, so the description must add meaning. It clearly specifies that E is photon energy in keV and theta is scattering angle in radians, which is essential for correct usage. This compensates for the schema's lack of 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 clearly states the tool calculates momentum transfer for X-ray scattering, using a specific verb ('Calculate') and resource. It lists the two parameters with explicit physical meanings, distinguishing it from sibling tools like cross-section or energy calculators.
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 on when to use this tool vs. alternatives (e.g., ComptonEnergy or DCS_Compt). The description lacks context for tool selection among similar physics calculators.
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?
Without annotations, the description carries full burden. It only states 'Calculate atomic factors' and lists parameters, but does not disclose whether it's read-only, requires network, or what the output format is (though an output schema exists, the description adds no behavioral 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 extremely concise, front-loading the purpose and including parameter descriptions in a single paragraph with no redundant information. 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 covers the main purpose and all inputs, and an output schema exists to explain returns. However, it could benefit from briefly explaining what f0, f', f'' are (e.g., scattering and absorption factors) and typical use cases, but overall it is adequate for a computation 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?
With 0% schema description coverage, the description provides meaningful parameter semantics: atomic number range (1-120), photon energy unit (keV), momentum transfer unit (1/Angstrom), and debye factor. This adds value beyond the schema's type and title, though could include constraints like allowed ranges for E and q.
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 calculates atomic factors f0, f', and f'' for an element, using a specific verb and resource. It distinguishes from siblings by focusing on atomic factors, not other properties like Compton profiles or cross sections.
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 atomic factors are needed, but does not explicitly state when to use this tool versus alternatives like CS_Total or FF_Rayl. It provides context through parameters but lacks explicit selection 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?
Description provides basic behavioral info: inputs (Z, shell, E) and output unit (barn/atom). However, no details on error handling, validation, or edge cases. Since no annotations are provided, the description carries the full burden.
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?
Concise and front-loaded. Every sentence is useful: one-line purpose, then clear argument list. No unnecessary text.
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 presence of an output schema, the description adequately covers inputs and output units. Could note return value structure but output schema handles that. Minor gap: no mention of valid energy range or shell 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?
Parameter descriptions are minimal: Z range (1-120), shell example (K_SHELL), E unit (keV). The input schema has 0% coverage, so description partially compensates but lacks full specification of valid shell names or value constraints.
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?
Description clearly states the tool calculates partial photoionization cross section for a shell, with units barn/atom. It distinguishes from siblings like CS_Photo_Partial (similar name) and other cross-section tools.
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?
No explicit guidance on when to use this tool vs alternatives. Usage is implied from the description, but no when-not-to-use or comparison to similar tools like CSb_Photo.
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 the output unit (cm2/g) and calculation method (Kissel photoionization), but does not mention any constraints, thresholds, or edge cases. Lacks detail on behavior beyond what is stated.
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 concise with two sentences plus argument details, no wasted words. The purpose is front-loaded, and the arg list is clearly 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?
Given the presence of an output schema (not shown but exists), the description provides the essential purpose and parameter definitions. It lacks comparison with siblings and domain-specific context (e.g., valid energy ranges), but is adequate for a straightforward calculation 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?
Schema coverage is 0%, but the description adds meanings: Z is atomic number (1-120), shell is a shell name with examples, E is photon energy in keV. This compensates for the empty schema, though the exact format for shell (e.g., case sensitivity) is not fully specified.
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 calculates fluorescence shell cross section using Kissel photoionization, with specific verb 'Calculate' and resource 'fluorescence shell cross section'. It distinguishes from siblings like CS_FluorShell (non-Kissel) and CS_FluorLine_Kissel (line vs shell).
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 on when to use this tool vs alternatives like CS_FluorShell, CS_FluorShell_Kissel_Cascade, or CSb_FluorShell_Kissel. The agent is left to infer selection from the name alone.
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 states the inputs (Z, E) and output unit, but does not disclose potential restrictions (e.g., valid E range, behavior for out-of-range values, or return structure). For a calculation tool, this is adequate but minimal.
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 extremely concise: one-line purpose plus two lines for parameters. Every sentence is informative, and there is no extraneous text. This is a model of efficiency.
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 existence of an output schema (not shown), the description need not explain return values. It covers the essential input constraints. However, missing details like valid energy range or error handling reduce completeness slightly. For a simple two-param tool, it is mostly complete.
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 description adds value beyond the input schema by providing units for E ('keV') and the range for Z ('1-120'). With 0% schema coverage, this is helpful. However, it does not specify that E must be positive or give precision hints. For two parameters, this is good but not exhaustive.
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 specifies the tool's function: 'Calculate the photoionization cross section of an element (cm2/g)'. It includes the unit and the two required parameters (Z and E). This distinguishes it from sibling tools (e.g., CS_Rayl, CS_Compt) that calculate other cross sections.
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 no guidance on when to use this tool versus alternatives. There are many sibling tools for different cross sections, but no explicit when/when-not or context for choosing CS_Photo. The user must infer usage from the name alone.
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. The description adds minimal behavioral context beyond the scientific calculation (e.g., no mention of side effects, auth, or edge cases). The presence of an output schema partially compensates for missing return value explanation.
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?
Extremely concise: one-line purpose followed by clear parameter definitions. Every sentence adds necessary information without waste.
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 scientific nature and existence of an output schema, the description covers the essential inputs and units. However, it could mention expected output format or error handling for invalid shells.
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?
Despite 0% schema description coverage, the description adds meaningful details: Z range (1-120), shell examples, and E unit (keV), going beyond the schema's bare types.
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 action ('Calculate') and resource ('partial photoionization cross section for a shell') with units (cm2/g), distinguishing it from siblings like CS_Photo and CS_Photo_Total.
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 siblings. With over 80 sibling tools, explicit usage context is missing.
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 provided; description indicates a read operation ('Get'). Lacks disclosure of behavioral traits like performance, errors, or side effects, but the existence of an output schema partly fills the gap.
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?
Description is concise with two sentences plus an Args list, front-loaded with the purpose. No wasted words.
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 lookup tool with two parameters and an output schema, the description provides sufficient context. Could optionally list all valid shell names, but the example suffices.
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 has 0% description coverage. Description adds meaning: Z is atomic number (1-120), shell is a shell name like 'K_SHELL', providing essential context beyond the schema's type definitions.
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?
Description clearly states 'Get the electron configuration for a given shell of an element' with specific parameters Z and shell. This distinguishes it from sibling tools like AtomicNumberToSymbol or EdgeEnergy.
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 explicit guidance on when to use this tool vs alternatives. Given the large sibling list, such guidance would be helpful for an AI agent to select the correct 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?
With no annotations, the description carries the full burden. It indicates a read operation, but lacks details about the output format or any side effects. However, the output schema exists, so the description is minimally adequate.
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, clear sentence with no extraneous content, perfectly 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?
For a simple list retrieval with no parameters and an output schema, the description is mostly complete. It could mention the tool's role in a workflow (e.g., getting names before querying details), but it's sufficient.
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 coverage is 100% trivially. The description does not need to add parameter info, earning a baseline of 4.
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 'Get the list of all available NIST compound names,' which specifies the verb and resource, distinguishing it from sibling tools that operate on individual compounds.
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 siblings like GetCompoundDataNISTByName or GetCompoundDataNISTByIndex, which is a notable omission given the large number of related 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?
No annotations are given, so the description carries the full burden. It implies a read operation via 'Get' but does not explicitly state safety, error cases, or return format. Adequate but not detailed.
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 extremely concise with no unnecessary words. It front-loads the purpose and efficiently lists parameters. 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?
For a simple tool with two parameters and an output schema, the description is complete enough. It explains parameter types and provides examples. The output schema handles return value details, so no further description needed.
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 has 0% description coverage, but the description adds meaning: it explains Z as atomic number (1-120) and provides line examples like 'KL3_LINE'. This compensates well for the schema gap.
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 'Get the energy of an X-ray fluorescence line,' specifying the verb (get) and resource (energy of a line). It distinguishes from sibling tools like EdgeEnergy or FluorYield, which target different properties.
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 ListLineConstants for line constants or other tools. The description only states what it does without usage 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?
Description is minimal ('list all...') but adequate for a simple read-only operation. No annotations are provided, so the description's transparency is average.
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?
Single sentence, no wasted words, efficiently communicates the tool's action.
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 the presence of an output schema, the description is mostly complete. A brief explanation of what constitutes 'shell constants' could improve clarity for agents unfamiliar with the domain.
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?
No parameters exist (0 params, baseline 4). Description adds no parameter info but doesn't 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?
Description uses a specific verb 'List' and resource 'shell constant names', clearly distinguishing it from sibling tools like ListLineConstants, ListTransitionConstants, etc. No ambiguity.
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 on when to use this tool versus alternatives. Given many sibling list tools, explicit usage context would help the agent make the correct selection.
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 full burden. It reveals that the tool performs a calculation (read-only) and specifies input ranges (Z 1-120, E in keV). However, it does not disclose side effects, error handling, or any behavioral traits beyond the basic operation. The presence of an output schema partially compensates for missing return value details.
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 extremely concise, using two short sentences to express purpose and parameter details. It is front-loaded with the main action, and every word earns its place without 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?
Given the tool's low complexity and the existence of an output schema, the description covers core functionality and inputs well. It could mention what happens on invalid input (e.g., out-of-range Z or E), but the explicit parameter ranges already provide basic guardrails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explicitly defines each parameter: Z as atomic number with range 1-120, and E as photon energy in keV. This adds essential meaning beyond the schema's bare types, making the inputs fully understandable.
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 verb 'Calculate' and the specific resource 'mass energy-absorption cross section of an element', with units (cm2/g). Among many sibling cross-section tools (CS_Total, CS_Photo, etc.), this one is uniquely identified by its focus on energy-absorption, making it easy to distinguish.
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 vs. alternatives like CS_Total or CS_Photo. The description only states what it does without contextualizing its speciality or restrictions, forcing the agent to infer usage from the name alone.
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. It describes a straightforward calculation with no side effects, but could mention precision, caching, or range limitations. Adequate but not detailed.
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?
Extremely concise: two lines of purpose and a short Args block. Every sentence is necessary with no 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?
Given the presence of an output schema, the description needn't cover returns. It fully describes purpose and parameters. However, missing usage guidelines slightly reduces completeness for a tool in a large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully: explains Z as atomic number (1-120) and E as photon energy in keV, providing meaning and constraints beyond schema types.
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 calculates the imaginary part of the anomalous scattering factor (delta f''), a specific resource with a precise verb. This distinguishes it from siblings like Fi (real part) and Atomic_Factors.
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 explicit guidance on when to use this tool versus alternatives. While the purpose implies it's for the imaginary component, the description does not mention scenarios, prerequisites, or comparisons with related 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?
No annotations are provided, so the description carries full burden. It states the calculation but does not disclose behavioral traits such as being a pure function, readonly nature, error conditions, or required permissions. The description is adequate but lacks depth.
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 very concise: two sentences with a structured args list. Every sentence adds value, and the format is efficient with no wasted words.
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 complexity and the presence of an output schema, the description covers purpose, parameters, and method adequately. Minor gaps include lack of reference to the Kissel method or any validity constraints, but overall it is complete enough.
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 description coverage is 0%, but the description provides meaningful details: units for E (keV), range for Z (1-120), and examples for line ('KL3_LINE', 'KA_LINE'). This adds value beyond the schema, though accepted line names could be more comprehensive.
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 calculates fluorescence line cross section without cascade using the Kissel method. The verb 'Calculate' and resource 'fluorescence line cross section' are specific, and 'no cascade' differentiates it from siblings with cascade.
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 cross-sections without cascade but does not explicitly say when to use this versus alternatives like CS_FluorLine_Kissel_Cascade. No exclusions or context on prerequisites are provided.
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 burden. It only states the function and argument, omitting behavioral traits such as output unit, read-only nature, or whether it returns density in g/cm³. Minimal 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?
Extremely concise with three lines, front-loaded purpose, and efficient format. Every sentence adds value without 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?
Given the tool's simplicity (one required parameter) and the presence of an output schema, the description is nearly complete. It is missing only a mention of the output unit or format, which would be helpful but not essential.
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 0% coverage (no description for Z), but the description adds critical semantic information: 'Z: Atomic number (1-120)', clarifying the parameter's meaning and valid range beyond the schema's type-only definition.
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 'Get the density of a pure element', specifying the exact resource (density) and action (get). It distinguishes from siblings by being the only tool dedicated to density.
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 indicates when to use (need density of pure element) and provides the valid atomic number range (1-120). It does not explicitly exclude alternatives, but the context of sibling tools implies this is the correct choice for density queries.
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?
Without annotations, the description bears full burden. It states it lists 'all available' names, but does not disclose output format (e.g., list of strings), pagination, or error conditions. Basic disclosure is present but not rich.
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 with no wasted words. Every word 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?
Given the presence of an output schema (not shown), the description need not detail return values. It is moderately complete for a simple list tool but could explicitly mention the output type (list of strings).
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?
No parameters exist and schema coverage is 100%. The description adds meaning by specifying the scope ('all available'), which aligns with the empty schema. Baseline 4 for zero parameters 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 'List all available X-ray fluorescence line constant names' uses a specific verb ('List') and resource ('X-ray fluorescence line constant names'), clearly distinguishing it from sibling tools like ListShellConstants or ListTransitionConstants.
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 needing line constant names but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
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 provided; description simply states the action without disclosing behavioral traits (e.g., whether results are sorted, case sensitivity). Sufficient for a simple listing operation.
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?
Single sentence, front-loaded with verb and object, 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?
Output schema exists, so return value details are covered. For a simple list tool, the description is adequate, though it could hint at the return format.
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?
No parameters; baseline 4 per rubric. Description adds no parameter details but none are needed.
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 specifies the action (list) and the resource (Coster-Kronig transition constant names), distinguishing it from sibling 'List*Constants' tools.
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?
Implied usage from the purpose, but no explicit guidance on when to use this tool versus alternatives like ListLineConstants or ListShellConstants.
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 states the tool 'calculates' a cross-section, implying a read-only computational operation, but does not disclose any side effects, permissions, or rate limits. The behavior is minimal, so a score of 3 is appropriate.
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 extremely concise: one sentence for purpose and a clean bullet list for parameters. No fluff. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 required parameters, no side effects), the description fully covers what it does, its parameters, and output unit. An output schema exists, so return details are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds valuable semantics: defines Z range (1-120), provides shell name examples (K_SHELL, L1_SHELL), and specifies E unit (keV). This significantly aids correct usage.
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 it calculates the fluorescence shell cross section without cascade using Kissel, in barn/atom. The tool name and description distinguish it from sibling variants (with cascade, different methods).
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 shell cross-section without cascade but provides no explicit guidance on when to prefer this over siblings or when not to use it. No alternative or exclusion criteria are mentioned.
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 correctly indicates a read/calculation operation, but discloses no behavioral traits such as energy limits or permissions. With zero annotations, the description is adequate but not enriched.
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 followed by a clear parameter list with examples. Every element is necessary and front-loaded, with no wasted words.
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 covers purpose and inputs, but does not explain output shape, valid energy ranges, or edge cases. Given the existence of many sibling tools for different cross sections, more context (e.g., compound requirements) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description explains that 'compound' is a chemical formula (with examples) and 'E' is photon energy in keV. This adds crucial meaning beyond the raw schema, fully compensating for the lack of schema 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 states 'Calculate the total cross section of a compound (cm2/g).' It specifies the verb, resource, and units, and the name includes 'CP' (likely compound), distinguishing it from other total cross-section tools like CS_Total for elements.
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 lists required arguments with examples, making inputs clear. However, it does not explicitly state when to use this tool over siblings like CS_Total (for elements) or CS_Total_Kissel_CP, leaving implied usage based on tool naming.
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?
No annotations are present, so the description carries full burden. It discloses the output unit (cm2/g) and the method (Kissel), providing essential behavioral context for a computation tool. However, it does not mention potential errors or limitations.
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 extremely concise: one clear sentence followed by a well-structured argument list. Every part earns its place with 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 complexity of the sibling family and the existence of an output schema, the description adequately covers the tool's purpose and parameters. It could be improved by briefly explaining what 'nonradiative cascade' means, but overall it is sufficient for a specialized calculation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds substantial value: it provides valid Z range (1-120), examples for shell ('K_SHELL', 'L1_SHELL'), and units for E (keV). This fully compensates for the schema's lack of property 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 clearly states the tool calculates a fluorescence shell cross section with nonradiative cascade using the Kissel method, expressed in cm2/g. This is a specific verb-resource combination that distinguishes it from sibling tools with different cascade types or line-focused variants.
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 nonradiative cascade calculations but does not explicitly guide when to use this tool versus siblings with radiative or no cascade. Given the large number of similar tools, explicit guidance would help but the naming convention partially compensates.
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?
No annotations are provided, so the description carries full burden. It clearly states the tool returns a list of names, which is a safe, non-destructive read operation. While it doesn't mention sorting or pagination, the simplicity of the tool's output (list of names) makes this acceptable. The description does not contradict any annotations.
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, concise sentence that effectively conveys the tool's purpose with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, straightforward list retrieval) and the presence of an output schema, the description is complete. It adequately informs the agent of the tool's functionality.
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 already documents this with 100% coverage. The description adds no parameter information, but none is needed. Baseline 4 is appropriate for no-parameter tools.
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: 'Get the list of all available radionuclide names.' It specifies the verb 'Get' and the resource 'list of all available radionuclide names,' distinguishing it from siblings like GetRadioNuclideDataByName that retrieve data for specific nuclides.
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 all radionuclide names before using more specific tools, but it does not explicitly state when to use this tool versus alternatives. No exclusions or context for when not to use it are 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 provided, the description carries the full burden. It discloses parameter constraints (Z range 1-120, q unit 1/Angstrom) and implies a read-only calculation with no side effects. However, it does not specify the return format or any potential edge cases.
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 extremely concise: two brief sentences plus an arg list. Every word is essential, with no redundancy or fluff.
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 that an output schema exists (context signal true), the description does not need to explain return values. For a simple two-parameter calculation, the description provides sufficient context including parameter constraints and units.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain both parameters. It clearly defines Z as atomic number (1-120) and q as momentum transfer in 1/Angstrom, adding meaning beyond the schema's type-only definitions.
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 explicitly states 'Calculate the Compton incoherent scattering function', providing a clear verb and resource. The tool name SF_Compt matches this purpose, and it is distinct from sibling tools that compute related quantities like cross sections (CS_Compt) or form factors (FF_Rayl).
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 does not provide explicit guidance on when to use this tool versus alternatives, such as CS_Compt for cross sections or ComptonProfile. While the purpose is clear, there is no context about prerequisites or exclusions, limiting the agent's ability to select among similar 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?
No annotations are provided, so the description carries the full burden. It states that the tool lists names, implying a string list output. For a parameterless tool, this is sufficient behavioral disclosure; no side effects or special behavior is expected.
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?
Single sentence with no wasted words. Perfectly concise and front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with an output schema (presumably defining return type), the description is complete. It tells what the tool does and what it returns (names). No additional context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the input schema is fully covered. The description adds value by specifying what is listed, which is not evident from the empty 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 the action ('List') and the resource ('all available Auger transition constant names'). It distinguishes from sibling tools like ListLineConstants and ListShellConstants, which cover other constant types.
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?
No explicit guidance on when to use this tool versus alternatives. However, the naming convention and sibling context imply it's for Auger constants specifically. No when-not-to-use or alternative references.
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:

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

Score Badge

Copy to your README.md:

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

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/tschoonj/xraylib-mcp-server'

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