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

With no annotations, the description carries the behavioral disclosure burden. It explains the mathematical definition, unit cancellation, and interpretation of returned values (S_AB > 1, < 1, = 1). It omits edge-case handling but adds meaningful behavioral detail.

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

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

The description is compact and well-organized: purpose, formula, parameter details, and return interpretation. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple calculation tool without an output schema, the description sufficiently covers formula, input sources, and output semantics. It lacks error-handling details and optional-label explanation, but is complete enough for typical invocation.

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

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 explains loading_a/b and feed_fraction_a/b with units and constraints, but does not explain label_a/b. Since labels are optional and self-evident from defaults, this is a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool calculates adsorption selectivity S_AB from mixture GCMC results, supported by the exact formula. This specific verb+resource+scope distinguishes it from sibling parsing/plotting tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives clear context by specifying the input source (parse_raspa_output()['components'] for GCMCMixture) and notes feed fraction constraints. It does not explicitly list alternatives or exclusions, but the intended usage is unambiguous.

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

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 explains exactly what is checked, states that a diagnostic report is returned, and mentions the remediation command for the failure case. It does not explicitly state it performs no modifications, but 'check' and the listed verifications imply 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.

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

The description is well-structured and front-loaded with the main purpose. The numbered list of checks is compact and easy to scan, and every sentence adds useful information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter diagnostic tool, the description is complete. It explains what will be checked, what the output is (a full diagnostic report), and what action to take when the environment is not ready. No output schema exists, but the return type is clearly expressible as a diagnostic report.

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

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

The tool has zero parameters, so the input schema already provides complete parameter information. The baseline of 4 applies, and the description correctly spends no space on parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Check whether RASPA2 is correctly installed and configured on this server.' It then lists the precise verification points (binary on PATH, environment variable, force field/molecule files), which clearly distinguishes it from sibling simulation and parsing tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description clearly states the tool's purpose and includes an actionable next step if the check fails ('run: raspa-mcp-setup'). It does not explicitly list when to use this tool versus alternatives, but the context of checking the environment before simulations is strongly implied.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly states that it creates directories and copies a CIF file, and it details what it does NOT create: 'simulation.input, force_field_mixing_rules.def, pseudo_atoms.def, and molecules/TraPPE/*.def' are left for Claude to write. It also discloses a security restriction: 'work_dir must resolve to a path inside the allowed workspace base, controlled by the RASPA_MCP_WORKSPACE_BASE environment variable.' This is substantial transparency.

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

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

The description is well-organized and front-loaded. It begins with a clear one-sentence summary, then provides a concrete directory tree, followed by Args and Security sections. Every sentence earns its place, and there is no redundant content. The formatting improves readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This tool is a file-system operation with no output schema. The description is complete enough: it specifies the exact structure created, the source CIF copy, the parameter roles, and a critical security constraint. It also clarifies the boundary of what the tool does versus what the model must write, which is essential for the agent's workflow.

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

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

Despite 0% schema description coverage, the description compensates thoroughly with an 'Args:' section that adds meaning beyond the bare schema. For example, it explains that framework_name is the name matching the CIF file (without extension), work_dir is an absolute path to the new simulation directory, and cif_source_path points to the existing CIF file. This is more informative than the schema's simple type/title fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Create a properly structured RASPA2 simulation workspace directory.' It then details the exact directory layout and the CIF copying action, which clearly distinguishes it from sibling tools like preflight_workspace or the generate_* tools. The scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context: 'RASPA2 expects a specific directory layout. This tool creates it and copies the CIF file into the right location.' This implies it is the initial setup step for a simulation workspace. However, it does not explicitly name alternatives or exclusions (e.g., 'use preflight_workspace to validate an existing workspace'), so it stops short of full when/when-not guidance.

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

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 default disk writes, the safe minimal output, and the return_only flag to avoid writing. It also mentions the workspace path constraint. It does not explicitly state whether an existing file is overwritten, but the core behaviors are well covered.

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

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

The description is focused and well-structured: a one-sentence purpose, a helpful warning, and a clear Args list. Every sentence adds value with no fluff, and critical warnings are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with no annotations or output schema, the description covers purpose, safe default usage, parameter meanings, and differentiation from a sibling. Minor gaps like the exact return format when return_only is true remain, but overall it is sufficiently complete.

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

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

Schema descriptions are missing (0% coverage), but the description compensates by explaining work_dir with a workspace constraint, return_only as a no-write flag, and the three optional lists with their entry structure ({line, comment}). This adds meaningful semantics beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Generate') and resource ('force_field.def'), explicitly naming it as the OVERWRITE-rules file. It clearly distinguishes the tool from the sibling generate_force_field_mixing_rules_def by name and purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly warns against confusing this file with force_field_mixing_rules.def and directs users to the sibling tool for LJ parameters. It also explains that with no arguments it produces the safe minimal '3 zeros' form, which is the common use case.

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

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

With no annotations, the description carries the full burden. It explains the effect of 'shifted' and 'truncated' options, mentions that return_only is a dry-run, and describes the atom_types item structure. It does not discuss permissions, overwriting behavior, or error handling, which is a minor gap, but the core behavioral traits are disclosed.

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

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

The description is somewhat long but well-structured, starting with a one-line summary, then detailing the atom_types schema, the truncation choice, and a formal Args list. Every sentence adds value, and the format makes it easy to scan. Slightly verbose but appropriate for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no output schema, and no annotations, the description covers all parameter semantics and key behavioral aspects. It lacks an explicit description of the return value when return_only is true, and it does not provide a concrete example of the output file. However, it is complete enough for an agent to understand and invoke the tool correctly.

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

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 an explicit Args section explaining every parameter, including the nested structure of atom_types, the options for general_mixing_rule, general_truncation, tail_corrections, and return_only. This fully 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb and resource: 'Generate force_field_mixing_rules.def — the LJ epsilon/sigma file.' It clearly distinguishes this tool from siblings like generate_force_field_def and generate_pseudo_atoms_def by specifying the exact file and content. The purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context for parameter choices, including the shifted vs truncated behavior and when to use tail corrections for fluid-phase work. However, it does not explicitly state when to use this tool versus alternatives like generate_force_field_def, so it stops short of full exclusion guidance. The implied usage is strong, but explicit alternatives are not named.

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

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

With no annotations, the description discloses important behaviors such as coordinate origin (centre of mass), units (Å), and file path. However, it omits behavior of key parameters like return_only, rigid, n_groups, and doesn't state overwrite behavior or return value.

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

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

The description is well-structured, with a clear purpose line, representative code blocks for array formats, and a usage note. No redundant sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter tool with no output schema or annotations, the description covers the main file content and path but leaves several parameters undocumented. It provides a good foundation but not enough for fully independent use, especially regarding return_only and thermodynamic parameters.

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

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

Schema has zero description coverage for parameters. The description explains the structure of atoms/bonds/bends/torsions arrays and the path template implicitly covers work_dir, subdirectory, molecule_name. But critical properties, rigid, n_groups, and return_only remain unexplained, so coverage is partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Generate a per-molecule .def file' with a specific path pattern. This distinguishes it from sibling tools like generate_force_field_def and get_molecule_definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides clear context on how to use the generated file ('Set MoleculeDefinition <subdirectory> in simulation.input') and a specific warning against 'MoleculeDefinition local'. However, it doesn't explicitly compare against alternative tools for retrieving or generating molecule definitions.

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

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

With no annotations, the description carries the full burden. It explains the file's purpose and the required/optional keys for each atom entry, which adds behavioral context. However, it does not disclose side effects like file writing behavior, overwriting, or the `return_only` toggle.

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

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

The description is well-structured and front-loaded with the core purpose. Every sentence adds value: the first identifies the output file and role, the second details required and optional atom fields. No redundant or vague phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite explaining the atom item structure, the description omits important operational details: whether the tool writes to disk, how `return_only` changes behavior, what happens if `atoms` is missing required keys, and error conditions. For a generation tool with no output schema, these are significant gaps.

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

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

Schema coverage is 0%, so the description must compensate. It does so for the `atoms` parameter by listing required and optional keys per item, adding substantial meaning beyond the bare schema. However, `work_dir` and `return_only` remain unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: generating `pseudo_atoms.def`, the atom registry. It specifies the resource and the action ('Generate'). While it doesn't explicitly compare to sibling tools like `generate_molecule_def`, the unique role as atom registry is distinct enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage: it is the tool for creating the registry that must include all atom types from various sources. It gives context about coverage requirements but does not explicitly state when to use this over alternatives or provide exclusion criteria.

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

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 clearly indicates a read-only operation ('Return the complete content') but does not disclose any error handling, prerequisites, or side effects. Since it's a simple retriever, some behavioral context is assumed 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.

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

The description is concise and front-loaded with the core purpose. The note about file placement is a single, relevant sentence. The Args section is clearly formatted with examples. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter, no output schema, and a simple retrieval action, the description is nearly complete. It specifies the exact files returned and where they should be used. It could mention the return format (e.g., plain text or dict) but this is not critical for a straightforward read tool.

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

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

Schema coverage is 0%, so the description must compensate. It does so by providing example forcefield names (TraPPE-CO2, TraPPE-N2, TraPPE-CH4), giving meaningful context beyond the schema's bare 'Forcefield Name'. This is sufficient for a single parameter, though it could be improved by listing all valid options or pointing to list_available_forcefields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it returns the complete content of two specific files (pseudo_atoms.def and force_field_mixing_rules.def) for a given force field, using a clear verb ('return') and resource. This clearly distinguishes it from sibling tools like generate_force_field_def, which generate rather than retrieve files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context that the returned files must be placed in the simulation working directory alongside simulation.input, implying the tool is used when setting up a simulation. However, it does not explicitly mention alternatives or when not to use it (e.g., when generating new force fields), which would merit a 5.

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

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

With no annotations, the description carries the transparency burden. It clearly indicates a read operation (returns content) and specifies the file location, but it does not disclose error behavior, return format, or case sensitivity. No contradictions with 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.

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

The description is compact and front-loaded with the purpose. The Args section reinforces examples without unnecessary verbosity, and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool, the description gives the essential purpose and path, but it omits error handling and does not point to the sibling tool list_available_molecules for discovering valid names. This makes it incomplete for an agent that needs to recover from invalid inputs or navigate the available molecule set.

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

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

The schema only defines the parameter name with no description, so the description's examples (CO2, N2, CH4, H2O, helium) add valuable semantics by showing valid values. It also states the molecule must be built-in, providing a constraint not present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the content of a RASPA2 molecule definition file for a built-in molecule, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like list_available_molecules or generate_molecule_def, so it lacks full sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage by showing the file path and example molecule names, giving some context for when to use it. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or references to sibling tools.

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

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

No annotations are provided, so the description carries the burden. The verb 'Return' strongly implies a read-only operation with no side effects, but the description does not explicitly state this, nor does it disclose behavior for invalid parameter names or return format. It is adequate for a trivial lookup tool but lacks richer 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.

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

The description is concise and front-loaded, with the core purpose in the first sentence and an efficient Args section covering the parameter. Every sentence earns its place, and there is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one optional parameter and no output schema, but the description does not specify the return format (e.g., plain text, dictionary, list) or error behavior for invalid parameter names. While it gives enough to invoke the tool, an agent would benefit from knowing the response shape or error handling, especially given the lack of an output schema.

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

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

The parameter 'parameter_name' has no schema description (0% coverage), but the tool description compensates by explaining the parameter explicitly: it can be a specific string (with examples) or None to retrieve all parameters. This adds meaningful semantics beyond the raw schema, making the parameter's purpose and allowed values clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns documentation for RASPA2 simulation.input parameters, with a specific verb ('Return') and resource ('RASPA2 simulation.input parameters'). It distinguishes itself from sibling tools like list_available_forcefields or get_simulation_template by focusing on parameter documentation. The 'Args' section further clarifies the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage via the parameter_name argument: provide a specific name or omit it to get all parameters. However, it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or prerequisites. The context is clear but implicit.

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

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

No annotations are present, so the description carries the full burden. It discloses that the return includes a template with ${PLACEHOLDER} markers and parameter documentation, which are key behavioral details. It does not mention side effects or error handling, but as a read-only getter this is largely sufficient.

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

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

The description is three sentences, with the main purpose front-loaded first, followed by placeholder semantics and documentation details. Every sentence adds value and there is no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter getter with no output schema, the description covers the essential return values (template and docs) and the placeholder aspect. It does not specify the exact return format or error behavior, but given the low complexity this is nearly complete.

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

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

The schema provides an enum for simulation_type but has 0% description coverage. The description does not explain any of the enum values or add parameter-specific meaning; it only says 'for the given simulation type,' which is already implied. This fails to compensate for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Return the canonical simulation.input template for the given simulation type' with a specific verb and object. It distinguishes itself from siblings like list_simulation_types and get_parameter_docs by explicitly mentioning the template and placeholder markers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies the tool is used when you need a template for a simulation type before writing a file. It provides clear context but does not explicitly mention alternatives or exclusions, so it stops short of a 5.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It goes beyond the schema by enumerating accepted scenario values and specifying the behavior when scenario is None (list all). This adds meaningful context about input handling and output scope, though it doesn't detail the exact recipe 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.

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

The description is compact and well-structured: a single sentence states the primary purpose, followed by an Args section that clearly documents the parameter and its options. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one optional parameter, no output schema), and the description adequately covers its core behavior. It explains what the tool returns and how to use the parameter, but could be slightly more complete by specifying the recipe's structure (e.g., whether it includes arguments or tool names only). Overall, it's sufficient for an agent to invoke correctly.

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

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

The schema provides no description for the 'scenario' parameter (0% coverage), so the description fully compensates by enumerating the valid string values and explaining the None default behavior. This is essential semantic meaning that the schema alone does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Return an ordered, tool-by-tool recipe for a common RASPA2 scenario.' It uses a specific verb ('Return'), identifies the resource ('recipe'), and differentiates from siblings like get_simulation_template by emphasizing the sequential, tool-by-tool nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies when to use the tool by listing valid scenarios (custom_mof_gcmc, henry_widom, diffusion_md) and noting that None lists all available scenarios. It provides clear context for usage but stops short of explicitly naming alternatives or exclusions, which would push it to a 5.

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

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

With no annotations, the description carries the full burden. It discloses behavioral details: it flags common pitfalls like no charges, non-neutral cell, and atom overlap. It also lists what it inspects. While it doesn't discuss permissions or output format, for a read-only inspection tool the behavior is well covered.

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

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

The description is two sentences: the first lists what the tool does, the second gives usage guidance. Every word earns its place, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description is nearly complete. It explains the tool's function and when to use it. It could mention the return format, but the lack is not critical for such a straightforward inspection tool.

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

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

Schema coverage is 0%, and the description does not directly explain the parameter, but the parameter name 'cif_path' and title 'Cif Path' make its meaning clear. The description adds no extra semantics beyond mentioning 'CIF file', so it meets the baseline but does not compensate further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool inspects a CIF file and enumerates specific attributes (formula, cell parameters, charge column status, minimum interatomic distance) and flags pitfalls. This is a specific verb+resource that distinguishes it from sibling tools, which focus on simulations, force fields, and output parsing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly states when to use it: 'Use before launching a simulation against an unfamiliar CIF.' This provides clear context. It does not mention when not to use it or alternatives, but no sibling tool serves the same inspection role, so exclusions are unnecessary.

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

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

No annotations are provided, so the description carries the transparency burden. It implies a non-destructive read operation via 'List all' and reveals the output fields, but it does not explicitly state that there are no side effects or dependencies. For a straightforward listing tool, this is acceptable but not overly detailed.

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

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

The description is two sentences, front-loaded with the core action and resource. Every phrase adds meaningful information: the content fields, the purpose ('decide which force field to use'), and no filler. Excellent efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and is a simple listing operation, the description is adequately complete. It covers what the tool returns and why to use it. Including a note about return format would be a minor enhancement, but the description satisfies the core needs.

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

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

The tool takes no parameters, so there is no need for parameter-level explanation. The description adds value by detailing what information is returned, which helps the agent know what to expect. Baseline for zero parameters is 4, and the description does not detract from it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and clearly identifies the resource ('built-in force fields'), along with the kind of information returned ('molecule targets, references, and applicability notes'). This distinguishes it from sibling tools like recommend_forcefield, which actually recommends rather than lists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly states when to use the tool: 'Use this to decide which force field to use.' This gives clear context, though it does not mention alternatives or exclusions. For a simple listing tool, this is adequate and useful.

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

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

With no annotations, the description carries the full burden. It indicates read-only behavior ('List') and adds the scope that it lists only built-in definitions, but it does not describe return format, pagination, or any potential limitations beyond the .def note. This is adequate but not rich 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.

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

The description is two short sentences. The first sentence immediately states the core purpose; the second adds critical operational context. Every word is purposeful with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, parameter-less listing tool without an output schema, the description covers the core behavior and a key limitation (manual .def for missing molecules). It could mention output format, but that's not necessary given the simplicity. The description provides sufficient context for selection and invocation.

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

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

The tool has zero parameters, so the baseline is 4. There is nothing to explain about parameter semantics, and the schema already documents no properties. The description doesn't need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'List all built-in molecule definitions with metadata,' which clearly specifies the verb (list) and resource (built-in molecule definitions). The addition of 'with metadata' provides specific scope, and it distinguishes from siblings like list_available_forcefields and get_molecule_definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The second sentence, 'Molecules not listed here require manual .def file construction,' implies a use case: check if a molecule is built-in and if not, you will need to construct a .def file. While it doesn't explicitly name alternatives, it provides decision-relevant context about when this tool is needed versus manual construction.

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

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

No annotations are present, but the description fully describes the tool's behavior: it lists all simulation types with relevant context. As a read-only listing operation, there are no side effects or hidden behaviors to disclose 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.

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

Two sentences, front-loaded with the action and resource, and includes a usage directive. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only list tool with no output schema, the description fully covers what the tool does, what it returns, and when to call it. It is contextually complete.

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

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

The tool has zero parameters, so the description's job is simply to explain what the listing contains. The description does this by mentioning descriptions and typical use cases, satisfying the baseline for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'List' with the resource 'all RASPA2 simulation types' and notes the output includes descriptions and typical use cases. This clearly differentiates it from siblings like get_simulation_template or list_available_forcefields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly instructs to 'Call this first' to decide which simulation type fits the user's goal, providing clear context for when to use it in the workflow.

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

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 known limitations (2D-only, not 3D), version-specific format variations, and failure status values ('status='no_grid_files' or 'warning''). It also states that it returns 'full grid metadata and ONE 2D slice.' While it doesn't explicitly state side effects (e.g., file system writes), the read-only nature is implied by its parse-and-return function. This is more than minimal disclosure, though not exhaustive.

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

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

The description is well-structured with paragraphs and an Args list, but it runs a bit long due to two 'KNOWN LIMITATION' sections. However, every sentence carries useful information (format prerequisites, return data, version caveats, visualization alternatives). It is front-loaded with the core purpose and then provides supporting details. Slightly verbose but not bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (file parsing, version variations, multiple parameters, no output schema), the description is quite complete. It covers RASPA2 prerequisites, return values (metadata and slice_data), how to visualize, failure modes, and parameter semantics. The only gap is the exact shape/type of the returned slice_data, but this is partially mitigated by the reference to plot_density_slice(). Overall, it provides sufficient context for safe selection and invocation.

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

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

Schema coverage is 0%, so the description compensates excellently with an Args section that explains each parameter: output_dir (path), molecule (optional filter), slice_axis (with 'x'/'a' aliases), and slice_index (with -1 as midpoint). This adds practical meaning beyond the schema titles and defaults, giving the agent the exact semantics needed to select and pass values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Parse RASPA2 3D density grid files and extract a 2D slice (3-4).' It also distinguishes from sibling tools by explicitly noting it returns a 2D slice and referencing plot_density_slice() for visualization, and further clarifies that it does NOT provide full 3D isosurfaces. This makes the tool's purpose specific and non-overlapping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides explicit guidance on when to use this tool and how to proceed: 'Pass the returned slice_data field to plot_density_slice() to save a PNG', 'For true 3D visualization... use external tools such as VESTA, py3Dmol, or ParaView', and 'To explore different planes, call this tool multiple times.' It also specifies the RASPA2 configuration needed to generate the .grid files, which is a clear prerequisite and alternative context.

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

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 method (Einstein relation, linear regime, latter 50% of trajectory), units (A²/ps and m²/s), and typical expected values. It does not mention error handling or missing files, but provides substantial 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.

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

The description is somewhat long but well-structured, starting with purpose, then prerequisites, method, expected output, and args. Every sentence adds value; typical diffusivity ranges are useful for sanity checks. It is appropriately sized but could be slightly trimmed without losing key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain return values. It states 'Result is given in A²/ps and m²/s' and mentions diffusion coefficients, which is sufficient. However, it does not describe the exact return structure (e.g., dictionary, list) or whether it returns values for all molecules or only filtered ones, leaving some ambiguity.

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

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

Schema description coverage is 0%, and the description compensates fully with an 'Args' section that explains output_dir, molecule, and diffusion_type. It clarifies the meaning of 'self' and 'collective' and gives an example molecule filter ('CO2'). This goes beyond the minimal schema information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a specific verb and resource: 'Parse RASPA2 MSD files and compute self- or collective-diffusion coefficients'. It clearly identifies the tool's function, distinguishes it from generic parse tools like parse_raspa_output, and specifies the types of diffusion coefficients.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description states prerequisites: 'Requires a completed NVT-MD or NPT-MD simulation with ComputeMSD yes set.' It also explains the file naming conventions (MSDSelf_<mol>.dat and MSDCollective_<mol>.dat). However, it does not explicitly mention when not to use this tool or name alternative tools, but the context is clear.

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

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 explains that it returns structured JSON, lists the extracted data, and notes a conditional behavior ('builds an isotherm table if multiple pressure points are detected'). It does not explicitly state that the tool is read-only, but this is strongly implied by 'Parse', and the absence of side-effect warnings is acceptable for a parser.

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

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

The description is well-structured and efficient: it opens with a one-sentence summary, then uses a bullet-like list for extracted data, and a clear Args block for the parameter. Every sentence adds value, with no fluff or redundancy. It is appropriately sized for a tool with a single parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema or annotations, the description is quite complete: it states the purpose, the exact data extracted, the return format (JSON), and the parameter semantics. It could have added a bit more detail about expected directory structure or error behavior, but the provided information is sufficient for an agent to select and invoke the tool correctly.

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

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

The input schema has only one parameter (output_dir) with no description, and the schema description coverage is 0%. The description compensates fully by providing a dedicated Args section that explains the parameter's meaning ('Path to the Output directory produced by RASPA2') and gives a concrete example path, making the parameter's semantics clear beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb 'Parse' and a clear resource 'RASPA2 output files', and specifies that it returns structured JSON. It goes on to list the exact extracted quantities (loading, Henry coefficients, void fraction, energies, isotherm table), which clearly differentiates it from sibling parse tools like parse_rdf_output, parse_msd_output, parse_ti_output, and parse_density_grid.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description clearly indicates this tool is for parsing RASPA2 output directories, and the Args section specifies the typical path ('<workdir>/Output/System_0/'). It doesn't explicitly mention when not to use it or name alternatives, but the specificity of 'RASPA2 output files' makes the intended use case unambiguous, and the sibling list includes other parse tools for different data types.

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

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 return values (r(Å), g(r) arrays, first-peak position) and the source file naming convention. It does not explicitly state read-only behavior or failure modes, but 'parse' strongly implies non-modifying behavior. Overall, it gives solid insight into what to expect.

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

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

The description is detailed but not bloated. The first sentence gives the purpose, followed by useful context on file generation and return values, then structured parameter explanations. Every sentence adds value, though it could be slightly more compact without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parser with no output schema, the description covers the essential context: what files are parsed, under what simulation conditions they are generated, what data is returned, and how filters work. It lacks an explicit example of the returned data structure, but the information provided is sufficient for an agent to invoke the tool and interpret the result.

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

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 does so thoroughly with an 'Args' section explaining output_dir as the path to the RASPA2 Output directory and component_a/component_b as optional name filters, including examples and the behavior when left empty.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Parse RASPA2 radial distribution function (RDF) output files' with a specific verb and resource. It clearly distinguishes from sibling tools like parse_raspa_output, parse_msd_output, and parse_ti_output by focusing on RDF data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context on when RASPA2 produces RDF files (ComputeRDF yes in NVT-MC or NVT-MD) and how to use optional filters. It does not explicitly compare to alternatives, but the context strongly implies when this tool is appropriate versus general parse_raspa_output.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It details the expected input directory structure, the need for Lambda/LambdaDefinition settings, the exact line format that may vary by RASPA2 version, the integration method (trapezoidal rule), unit conversion, and accuracy implications of lambda point count. It is exceptionally transparent about limitations and provides troubleshooting steps—far beyond what annotations could convey.

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

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

Although the description is longer than average, it is efficiently structured with clear sections (purpose, expectations, known limitation, method, accuracy, args). Every sentence adds value: the limitation section prevents misinterpretation, the accuracy guide informs lambda sampling choices, and the Args section ties back to the schema. No filler is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers input requirements, method, limitations, and fallback actions, giving a near-complete picture. It mentions the return status 'no_ti_data' but does not explicitly describe the full return object (e.g., deltaA value, status, units). Given the absence of an output schema, a slightly more explicit return contract would make it fully complete. Nonetheless, it is largely adequate for an agent to use and interpret.

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

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

The input schema provides only the parameter name and type (output_dir: string), with zero description coverage. The description compensates fully by explaining 'Root directory containing per-lambda subdirectories' and giving examples of acceptable subdirectory names like 'lambda_0.3/' and '0.3/'. This gives the agent everything it needs to populate the parameter correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Parse RASPA2 Thermodynamic Integration (TI) output and compute ΔA'. This clearly distinguishes it from sibling tools like parse_raspa_output or parse_rdf_output by naming the TI-specific input and the free energy output. The purpose is unambiguous and immediately understandable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context on when to use this tool: it expects completed RASPA2 simulations per lambda value, specific subdirectory naming, and required simulation keywords. It also gives a fallback path (manual extraction and numpy.trapezoid) when the tool returns no_ti_data. However, it does not explicitly mention alternatives among sibling tools, so it stops short of a full when-to-use vs. when-not-to-use guide.

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

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

With no annotations, the description carries the full transparency burden. It explains the input format, optional axis labels/units, and colormap defaults, but omits behavior around output_path (e.g., overwriting), the meaning of the cryptic '(3-4)', or what happens with title/molecule parameters.

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

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

The description is compact and front-loaded with the main purpose, followed by brief parameter clarifications. The '(3-4)' is unclear and the text could be tightened, but there is no wasted verbiage overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a plotting tool with 7 parameters, no annotations, and no output schema, the description covers the core workflow and key parameters but misses important details like how output_path is used and what the return value is. It is adequate but not fully self-contained.

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

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 semantics for slice_data, cell_lengths, axes_labels, and colormap. However, it does not explain output_path (required), title, or molecule, leaving meaningful gaps for an agent to infer.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Render a 2D density slice'), a specific resource ('from parse_density_grid()'), and the output format ('heatmap PNG'). It clearly distinguishes itself from the sibling parse_density_grid and other plotting tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly references parse_density_grid() as the source of slice_data, making the tool's prerequisite clear. It does not name alternative tools or when not to use it, but the context is strong and the intended workflow is implied.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the input format (list of dicts), required fields, units, and return values (success/error), including the output path and point count. It does not mention potential error conditions or edge cases, but provides enough for safe invocation.

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

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

The description is well-structured with a purpose sentence, bullet-pointed parameter explanations, and a return format note. It is appropriately sized for the tool's complexity—not too verbose, but every detail is useful. Could be slightly tighter, but front-loading is effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with no annotations or output schema, the description covers the core inputs and output format comprehensively. It explains the data structure and return schema, and gives a typical usage scenario. Missing documentation of the three optional parameters is acceptable given their simplicity and default values.

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

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 thoroughly explains isotherm_data (list of dicts with pressure/loading fields), pressure_unit (Pa/bar/kPa), loading_key (examples), and output_path (absolute path). It omits molecule, framework, and temperature_K, but those are fairly self-explanatory and have defaults, so the added value is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Generate a single-MOF adsorption isotherm plot (PNG)', which is a specific verb+resource that clearly distinguishes it from the sibling tool plot_isotherm_comparison. The rest of the description reinforces this scope, making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It provides clear context by stating the typical source ('the isotherm list returned by parse_raspa_output()') and the single-MOF scope, which implies when to use it versus a comparison tool. However, it does not explicitly name plot_isotherm_comparison as the alternative for multi-MOF plots, so exclusion is implied rather than stated.

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

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

No annotations are present, so the description bears full responsibility for transparency. It discloses the output format (PNG), the return structure including success and error cases, and that it writes to an absolute path. It does not mention file overwrite behavior or permission requirements, but for a plotting tool the disclosure is reasonable.

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

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

The description is well-structured and concise: a one-sentence summary, a code block for the complex parameter, and terse notes for the remaining parameters and return value. Every sentence contributes meaningful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters and no output schema, the description provides the essential invocation details, return format, and workflow context. It covers the most complex parameter (datasets) and returns status/path/n_series. It leaves out explanation of two optional parameters, but this is acceptable for a plotting utility.

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

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

With 0% schema description coverage, the description compensates by thoroughly explaining the 'datasets' parameter with a concrete example, and notes that pressure_unit/loading_key follow the same semantics as plot_isotherm(). However, it omits explanation of the molecule and temperature_K parameters, and only gives a minimal description for output_path as 'absolute path'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'multi-MOF comparison isotherm plot (PNG)' and 'all MOFs on one figure', clearly identifying the tool's function. It also distinguishes it from the sibling plot_isotherm by emphasizing multi-MOF comparison, and mentions its role in the 'top-N candidates' workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear usage context: 'Designed for the final top-N candidates comparison step' and instructs to pass isotherm_data from parse_raspa_output(). However, it does not explicitly contrast with plot_isotherm (single-MOF) or state when not to use this tool, though the multi-MOF vs single-MOF distinction is implied.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It lists specific validation checks (e.g., CIF existence, force field format) and explicitly returns `ok`, `errors`, `warnings`, and `findings`. While it does not mention side effects, the validation nature implies read-only behavior.

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

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

The description is well-structured with a bulleted list of checks and a clear return format. It front-loads the primary purpose and avoids verbose or redundant text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter validation tool, the description covers the complete behavior: checks performed and the response shape. Although no output schema exists, the explicit return structure and enumerated checks give the agent sufficient context to use the tool correctly.

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

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

The schema provides only `work_dir` with no description, and the description does not directly define this parameter's format or constraints. However, the first line clearly implies `work_dir` is the workspace directory to validate, adding meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Validate a workspace directory before launching simulate.' It uses a specific verb (Validate) and resource (workspace directory), and distinguishes itself from the sibling validate_simulation_input by covering the entire workspace rather than a single input.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description specifies the tool is to be used 'before launching simulate,' providing clear context for when to invoke it. It does not explicitly mention alternatives or exclusions, but the broader validation scope is implicitly contrasted with the narrower validate_simulation_input.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add useful context: the tool uses Semantic Scholar for literature guidance when a molecule is not in the library, and it returns structured guidance in that case. However, it does not disclose whether the tool is read-only, whether it makes network calls that could be slow or rate-limited, or what happens on invalid input. This is acceptable for a recommendation tool but not fully transparent.

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

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

The description is concise and well-structured, with two sentences plus an example list. It front-loads the core purpose, then adds the edge-case behavior, then provides parameter examples. Every sentence earns its place without redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's core function and the fallback behavior, but it does not describe the return format or structure. Since there is no output schema, the agent is left guessing what the recommendation looks like (e.g., force field name, confidence, parameter set). It is adequate for invoking the tool but not for fully interpreting the response, so it falls short of being complete.

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

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

The input schema only specifies 'molecule' as a string with no description. The description compensates by explicitly stating the accepted forms (common name, formula, or IUPAC) and providing concrete examples like 'CO2', 'methane', 'PH3', 'SO2', 'water'. This gives the agent clear guidance on how to populate the parameter, far exceeding the schema's minimal information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: given a molecule name, it recommends the most appropriate built-in force field and provides literature guidance. This distinguishes it from sibling tools like list_available_forcefields (which lists all force fields) and get_forcefield_files (which retrieves files). The verb 'recommend' and resource 'built-in force field' are 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.

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

The description provides clear context for when to use the tool: when you have a molecule name and need force field recommendation. It also differentiates behavior for molecules not in the built-in library, offering a fallback pathway. However, it does not explicitly state when not to use this tool or mention alternatives (e.g., use list_available_forcefields to see all options), so there is no explicit exclusion or comparison with siblings.

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

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 calculation logic (axis length rule and charge-dependent method choice), which is useful. However, it does not mention potential side effects, error handling, or what happens if the CIF has no charges or invalid data, leaving the agent with incomplete behavioral understanding.

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

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

The description is concise and front-loaded with the main action. Two sentences convey the core purpose and additional logic without unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no returned value description. The description states what the tool recommends but not the structure of the output (e.g., a dictionary with supercell and charge_method). It also lacks edge-case behavior, making it incomplete for an agent to invoke and process results confidently.

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

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 does add semantic meaning to both parameters: 'cutoff_A' is tied to the minimum-image rule, and 'cif_path' is implied to be a CIF file used to detect charges. However, it does not explicitly describe the expected format of 'cif_path' or units of 'cutoff_A' beyond the variable name, so it only partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: recommending an integer supercell (nx, ny, nz) with a specific rule (minimum-image 2×cutoff_A) and also recommending a ChargeMethod. It uses a specific verb ('recommend') and resources ('supercell', 'ChargeMethod'), and distinguishes it from sibling recommendation tools like 'recommend_forcefield'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context for when to use the tool: when constructing a supercell for RASPA2 simulations with a minimum-image rule, and when determining a charge method based on CIF charges. However, it does not explicitly mention alternatives or exclusions, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses that it returns blocking errors and advisory warnings, which is useful. However, it does not mention side effects (or lack thereof), return format, or behavior on invalid input, leaving some gaps.

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

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

The description is compact: two purpose sentences, one timing sentence, and a clear Args line. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a validation tool with a single parameter and clear return semantics (errors/warnings), the description is sufficiently complete. It could elaborate on the specific error types or scope, but the core information needed by an agent is present.

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

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

The schema only defines 'content' as a string. The description adds 'Full text content of the simulation.input file', clarifying that it expects the file's entire text, not a path. With 0% schema coverage, this is a meaningful contribution.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'validate' and names the exact resource ('RASPA2 simulation.input file'), clearly distinguishing it from sibling tools that parse output or generate files. The scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly states when to call ('always call this after generating simulation.input and before running simulate') and what it returns (errors vs warnings). Does not explicitly name alternatives, but the context is strong.

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