lammps_generate_input

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 mention the side effect of writing to a file when output_file is set ('write script to this file'), which implies it can also return the script as a string, but it does not elaborate on return behavior, validation, potential errors, or file overwriting. It adds some behavioral context about supported features but lacks depth on side effects and 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.

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

The description is appropriately structured: a one-sentence summary at the top, followed by a parameter list. While the list is long (18 entries), each line is terse and adds necessary meaning given zero schema coverage. The overall length is justified by the tool's complexity, and the summary is front-loaded for quick orientation.

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 main capabilities (potentials, ensembles, optional minimization/shear) and all parameters. An output schema exists, so detailed return-value documentation is not required. However, it does not fully address parameter interdependencies or edge cases (e.g., pressure with non-NPT/NPH ensembles), and there is no mention of required auxiliary files or runtime behavior. Still, it is reasonably complete for a complex generation 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 description coverage is 0%, so the description must compensate, and it does so thoroughly with an Args list covering all 18 parameters. Each parameter has a meaningful description (e.g., 'Lattice constant in Angstroms', 'Target pressure (for NPT/NPH)') that goes well beyond the raw schema, which only provides parameter names and defaults. This fully bridges the schema coverage 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 opens with 'Generate a complete LAMMPS input script for molecular dynamics simulation', which is a specific verb+resource pair. It further distinguishes the tool from siblings by enumerating supported potentials, ensembles, and optional features like minimization and shear deformation, making it clear this is the input-generation tool, not a parser or workflow orchestrator.

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 implies the tool is for creating LAMMPS input files, but it provides no explicit guidance on when to choose this tool over alternatives like lammps_generate_workflow. There are no usage exclusions or comparisons with sibling tools, though the parameter details hint at typical molecular dynamics simulation use cases.

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