gromacs-mcp

by Alierkn

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct GROMACS operation or file management task. Even the multiple write_mdp tools are clearly differentiated by simulation stage (EM, NVT, NPT, production, generic). The catch-all run_gmx is intentionally generic and does not introduce ambiguity.
Naming Consistency3/5
Tool names mix several conventions: single-word native GROMACS commands (check, energy), snake_case descriptors (read_text_file, validate_mdp), and a dedicated mdrun_ prefix for job management. While each group is internally consistent, the overall pattern is not uniform, but still readable.
Tool Count4/5
31 tools cover simulation setup, execution, analysis, and file management. This is slightly above average but justified by the breadth of GROMACS. Some generic file operations (list_files, read_text_file) could be omitted, but the count is still reasonable.
Completeness3/5
Core GROMACS workflows (setup, preprocessing, running, basic analysis) are well covered, but several common analysis tools (e.g., gmx covar, gmx anaeig, gmx distance) and advanced trajectory postprocessing are missing. The surface is functional for typical MD tasks but not exhaustive.
Average 2.9/5 across 31 of 31 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on July 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation but not destructiveness. The description adds little beyond 'write', lacking details on file overwriting, required permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise but under-informative, bordering on omission rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of MDP templates and the existence of sibling tools, the description is too brief. It does not clarify what 'conservative production-MD' means or how this tool fits into a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; the description does not explain any of the 8 parameters. The schema titles are minimal, leaving the agent without semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it writes a MD MDP template, which is a specific action, but uses jargon 'conservative production-MD' without explanation. It fails to distinguish from sibling tools like write_em_mdp, write_npt_mdp, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, exclusions, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present (readOnlyHint=false, openWorldHint=true) but the description adds no behavioral context beyond 'calculate'. It does not mention file outputs, potential side effects, or required permissions, leaving the agent without critical operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified for a tool with 7 parameters. It lacks structure or front-loaded key info, resulting in poor conciseness for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no schema descriptions, output schema exists but not referenced) and zero guidance on return values, the description is severely incomplete. It fails to equip an agent with sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter meaning. Essential parameters like trajectory, tpr, group_a, group_b, extra_args are completely unexplained, forcing the agent to infer from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'calculate' and the resource 'hydrogen bonds', making the primary purpose clear. The tool name 'hbond' also aligns well. However, it does not differentiate from similar analysis tools among siblings, but the specificity of 'hydrogen bonds' 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no prerequisites, exclusions, or context hints for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Calculate RMSD' implying a read operation, but annotations include readOnlyHint=false, which is ambiguous but not contradictory. No additional behavioral details are given, such as whether output files are created, or if the tool modifies any state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one short sentence), but it is under-specification rather than conciseness. It fails to convey necessary information that could fit in a few more sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (3 required), no schema descriptions, and an output schema, the description is grossly incomplete. It does not mention what RMSD calculates, how to interpret output, or any relationship to other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not provide any meaning or context for the 7 parameters, and the schema has 0% description coverage. For example, 'tpr' and 'trajectory' are critical inputs but their roles are not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates RMSD using 'gmx rms', which is a specific verb and resource. However, it does not explicitly distinguish from sibling tools like 'rmsf' (RMSF) or 'run_gmx', which might be considered a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'rmsf' or 'run_gmx'. The description lacks any context about prerequisites, recommended inputs, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, meaning the tool may have side effects, but the description only says 'calculate', which is ambiguous. It does not disclose whether outputs are written, the need for a topology file, or any behavioral traits beyond what annotations provide. The description adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which is too terse for a tool with 7 parameters and no schema descriptions. While it is front-loaded, it lacks necessary detail, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 3 required, 0% schema coverage, and an output schema), the description is completely inadequate. It fails to explain the purpose of parameters, expected inputs/outputs, or how the tool integrates with others, leaving the agent uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description does not mention any parameters or their roles, leaving the agent with no semantic information about required inputs like 'trajectory', 'tpr', or optional ones.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates solvent-accessible surface area using a specific command ('gmx sasa'). It provides a specific verb and resource, making the purpose clear. However, it does not differentiate from sibling tools like 'hbond' or 'gyrate', but the name itself is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives (e.g., other GROMACS analysis tools). There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are provided but are minimal. The description adds 'safe text' but does not explain what 'safe' means (e.g., overwrite behavior, file creation). It lacks details on side effects or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is too vague. It omits critical information, making it inefficient for an agent to understand the tool's usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no enums, and low schema coverage, the description is severely incomplete. It does not explain the return value (output schema exists but is not described), nor does it compensate for missing parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain any parameters. The purpose of 'content', 'filename', or 'workdir' is not clarified, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it writes a safe text MDP/topology-style file, which clarifies the tool's purpose and resource type. However, it does not differentiate from sibling tools like write_em_mdp or write_md_mdp, which could lead to confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its siblings, nor any mention of prerequisites, alternatives, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read-only operation ('Check a GROMACS file'), but the annotation readOnlyHint is false, creating a contradiction. The description does not disclose any other behavioral traits beyond the annotations, which are themselves inconsistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is too brief to convey necessary information. It earns its place but misses significant context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, many siblings, and an output schema, the description is incomplete. It does not explain what the tool returns, how parameters affect behavior, or how it differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaningful information about any of the 3 parameters (workdir, extra_args, input_file). Only the input_file parameter is loosely implied by 'GROMACS file', but no details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Check' and the resource 'GROMACS file', and ties it to the specific command 'gmx check'. It is clear but does not elaborate on the nature of the check (e.g., validation, integrity), and does not differentiate it from sibling tools like gmx_info or read_text_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions. The usage context is only implied from the tool name and command reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'replace solvent molecules' implying modification, but does not disclose behavioral traits such as whether it requires specific permissions, what files are changed, or side effects. Annotations indicate it is not read-only and not destructive, but description adds minimal context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it is too short to convey necessary information. While concise, it sacrifices completeness and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (10), lack of schema descriptions, and absence of output schema details, the description is woefully incomplete. It does not cover parameters, return values, or usage context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 10 parameters and 0% schema description coverage, the description fails to explain any parameter meanings. It only hints at 'solvent' which relates to the 'group' default, but does not clarify the function of parameters like pname, nname, concentration, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool adds counter-ions by replacing solvent molecules, which is a specific verb and resource. However, it does not differentiate from sibling tools like solvate or pdb2gmx that also modify the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or context for usage. It simply states the action without any when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, etc.), so the description carries the burden. It only states 'calculate', which is a read-like operation, but the tool likely writes output (e.g., gyrate.xvg) and may require specific input formats. There is no mention of side effects, file creation, or computational overhead. The description adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence, 8 words). While brevity is valuable, it omits essential information such as parameter roles and output behavior. The structure is front-loaded with the core action, but it sacrifices completeness for shortness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 3 required, output schema exists), the description is insufficient. It does not explain how arguments like trajectory, tpr, or group affect the calculation, nor does it mention the output format or file handling. The presence of an output schema does not excuse the lack of usage context for the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains no explanation of parameters. The schema has 6 parameters (tpr, trajectory, group, output, workdir, extra_args) with 0% description coverage. The description does not clarify what each parameter does, how they relate to the calculation, or defaults. This is a critical gap for correct tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates radius of gyration using the gmx gyrate command. The verb 'calculate' and resource 'radius of gyration' are specific. This distinguishes it from sibling tools like rms or sasa, which compute different properties. A slight improvement could be adding context (e.g., for a trajectory), but it is sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as rms, rmsf, or sasa. It does not mention prerequisites, input requirements, or typical use cases. An agent would have no basis to decide between this and similar GROMACS tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds minimal behavioral context beyond stating the output (topology and coordinates). It does not disclose file creation, overwriting behavior, or required permissions. Given the limited annotation info, the description should provide more detail about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient, but it lacks structure. It does not separate purpose, inputs, outputs, or usage. It is appropriately short but could benefit from a clearer breakdown.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with no schema descriptions and a minimal description, the tool is missing critical context. The existence of an output schema is not leveraged in the description. Essential information about parameter meanings, required format, and typical usage is absent, making the description incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%—the input schema has no descriptions for any of the 8 parameters. The tool description 'Build topology and processed coordinates from a PDB/GRO structure' adds no parameter-level information. An agent must guess the meaning of parameters like 'ignh', 'water', 'forcefield', etc., which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: building topology and processed coordinates from PDB/GRO structures. It uses a specific verb ('build') and identifies the resource (topology and processed coordinates) and input format. However, it does not distinguish this tool from siblings like 'editconf' or 'solvate', so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, required steps, or when not to use it. Usage is only implied by the general purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate limited behavioral traits (not read-only, not destructive). The description adds no additional behavioral context, such as side effects, system changes, or required permissions. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and gets to the point, which is acceptable for a simple tool. However, it could include a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (3 required) and an output schema, the description is severely incomplete. It fails to explain what RMSF is, the meaning of key parameters, or the expected output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about any of the six parameters, despite 0% schema description coverage. It does not explain the role of 'group', 'output', 'extra_args', etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Calculate' and the resource 'residue/atom RMSF' with the underlying command 'gmx rmsf'. However, it does not differentiate from sibling tools like 'rms' or 'energy', which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites, limitations, or when not to use it. The description is purely functional with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only says 'write a template' with no details on file overwriting, permissions, or behavioral traits. Annotations are all false, so the description carries full burden but fails to disclose meaningful behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (8 words) but under-specified. While efficient, it fails to convey necessary information, making it unhelpful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no schema descriptions, no annotations), the description is grossly incomplete. It lacks parameter explanations, usage context, and behavioral details, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameters or their meanings. With 8 parameters, the description adds no value beyond the schema titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'write' and the specific resource 'conservative NPT equilibration MDP template', distinguishing it from sibling tools like write_nvt_mdp and write_em_mdp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or when not to use it. The single sentence provides no contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint=true and idempotentHint=false, but the description adds no behavioral context (e.g., whether it modifies the input file or creates a new one). The description does not explain side effects beyond the minimal definition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but lacks structure such as usage hints or parameter grouping. It is not overly verbose but could be more informative without added length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 2 required, and an existing output schema, the description is incomplete. It does not explain the tool's role in a simulation pipeline or how the box is defined (e.g., distance from solute).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to explain any of the 7 parameters (e.g., center, distance, box_type). It adds no value beyond the plain parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Define a simulation box around a structure' clearly states the verb (Define) and resource (simulation box) but does not differentiate from sibling tools like solvate or genion that also modify structures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as adding a box vs. solvating or adding ions. The description lacks any context cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond what annotations provide. Annotations indicate write operation (not read-only) but no details on overwrite behavior, file handling, or side effects. Description adds no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it could be expanded to include more value without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of schema descriptions and the presence of an output schema, the description fails to provide sufficient context. It omits parameter details, usage prerequisites, and behavioral specifics, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any of the 6 parameters. Parameter meanings (e.g., emtol, emstep) remain unexplained, relying entirely on parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Write' and the resource 'energy-minimisation MDP template'. The term 'conservative' adds nuance. It distinguishes from sibling tools like write_md_mdp, write_npt_mdp, etc., by specifying energy minimisation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like write_md_mdp or write_nvt_mdp. An explicit note about when to choose energy minimization versus other MDP types is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, not idempotent, and not destructive. The description adds that it creates or edits an index file and uses the underlying gmx make_ndx command, but does not elaborate on behavior such as requiring stdin input, output file handling, or side effects. The behavioral disclosure is adequate but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action. It is front-loaded and has no wasted words. However, it could be slightly more informative without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (2 required) and complex behavior involving stdin interaction, the description is too minimal. It does not explain the necessity of stdin input, the default “q ” meaning, or the purpose of extra_args. The description is insufficient for an agent to use the tool effectively without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its 5 parameters, and the tool description does not explain any parameter meanings (e.g., structure, workdir, stdin, output, extra_args). This leaves the agent without guidance on how to set parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or edits a GROMACS index file using gmx make_ndx, specifying the verb-resource pair. While it doesn't explicitly differentiate from sibling tools, the purpose is evident and distinct from other GROMACS utilities like editconf or genion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool compared to alternatives. There is no mention of prerequisites (e.g., requiring a structure file) or context. The agent receives no hints about appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation and potential side effects (readOnlyHint=false, openWorldHint=true). The description adds minimal behavioral context beyond 'update the topology', which is consistent with annotations but does not elaborate on side effects like file creation or system modifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, appropriately concise, but it sacrifices necessary detail for brevity. It is not overly verbose, but under-specification reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, 2 required, and zero schema descriptions, the description fails to cover necessary usage context. The output schema exists but is not referenced in the description, so the agent lacks understanding of return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter meanings. The agent must infer from parameter names alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fill a box with solvent) and the effect on topology. It distinguishes the tool from sibling tools, which are mostly analysis or other preparation steps, not solvation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, prerequisites (e.g., existing topology), or alternatives. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only or destructive. The description adds that it performs PBC treatment, centering, and conversion, which implies file creation/modification. However, it does not disclose side effects like overwriting files or additional data usage beyond openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but omits critical information. It front-loads the purpose but lacks structure or detail, balancing brevity against completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no parameter descriptions, the description is insufficient for correct invocation. The presence of an output schema does not compensate for missing parameter context. Required parameters like trajectory and tpr are not explained in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no parameter details. It does not explain the pbc enum options, center_group, output settings, or extra_args, leaving the agent without necessary semantic guidance for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool post-processes a trajectory for PBC treatment, centering, and conversion. It identifies the resource (trajectory) and the general action, distinguishing it from sibling analysis tools like rms or energy, though it does not specify conversion formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or when to avoid it. Given siblings like editconf or other conversion tools, the lack of context limits correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'extract', implying a read-only operation, but annotations set readOnlyHint=false, which is contradictory. No other behavioral details are provided (e.g., file creation, permissions). The description does not clarify the discrepancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise. However, it could include more useful information without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameter descriptions in the schema, five parameters, and minimal behavioral context, the description is insufficient. It does not cover how to specify the energy term or output file, nor does it explain the tool's role among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description bears full responsibility for parameter meaning. However, it mentions none of the five parameters (output, workdir, selection, extra_args, energy_file), leaving them completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts an energy term from an EDR file using the gmx energy command. It specifies the resource (EDR file) and the operation (extract), which distinguishes it from siblings like rms or rmsf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., which energy terms are available, or when to use other tools). It only states the generic action, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate destructive behavior (destructiveHint=true), the description adds minimal context beyond stating 'remove'. It does not detail what happens to the removed records (e.g., permanent deletion), whether the operation is reversible, or any side effects. For a destructive tool, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core action. No redundant or extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (one optional parameter, output schema exists but not detailed), the description is incomplete. It fails to mention the parameter's effect or the nature of the output. An agent would lack sufficient context to use the tool correctly without inferring from the parameter name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining the 'finished_only' parameter. However, the description ignores parameters entirely, providing no meaning beyond the schema's title and default value. The agent must rely solely on the schema, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('finished job records from the registry'), clearly distinguishing it from sibling tools like mdrun_start, mdrun_list, etc. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as mdrun_forget or mdrun_stop. The description does not mention contexts, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds 'syntax and common safety issues' but doesn't elaborate on error handling or output. It provides some context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded and efficient, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple validation tool, but it lacks details on prerequisites, error behavior, and what constitutes 'safety issues'. The output schema likely covers return values, so completeness is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not mention or clarify any parameters. The parameter names (mdp, workdir) are self-explanatory, but the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: validating a text MDP file for syntax and common safety issues. It uses a specific verb (validate) and resource (MDP file), distinguishing it from siblings like 'check' which may be more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when not to use it or compare to siblings like 'check' or 'editconf'. The usage is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal disclosure beyond annotations. Says 'writes' and 'conservative' but does not mention side effects (e.g., overwriting files) or behavior like default values or validation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks necessary details. Efficient but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain parameter usage or expected output format. Incomplete for a tool with 7 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameter descriptions in schema (0% coverage) and no explanation in the description. Agent must infer meanings from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool writes an NVT equilibration MDP template, with 'conservative' qualifying the content. Distinguishes from sibling tools like write_npt_mdp and write_em_mdp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for NVT equilibration, but no explicit when-to-use or alternatives guidance. Siblings exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations covering readOnly, destructive, and idempotency (all false), the description adds that the tool creates a TPR file. However, it does not explain that it may produce warnings, require existing files, or that openWorldHint=true indicates potential side effects beyond the workdir.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 8-word sentence, which is very concise and front-loaded. However, it omits necessary details; a slightly longer description with bullet points would be more helpful while still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (4 required) and no output schema, the description is too minimal. It fails to explain the tool's role in the MD workflow (e.g., that it must precede mdrun), the validation it performs, or that it requires specific input file formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only mentions three (MDP, structure, topology) out of eight parameters. Missing explanations for index, maxwarn, workdir, extra_args, and output_tpr, including their defaults and purposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Preprocess' and lists inputs (MDP, structure, topology) and output (TPR run input). This distinguishes it from sibling tools like pdb2gmx (which generates structure/topology) and validate_mdp (which only checks inputs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as pdb2gmx, solvate, or mdrun. The description does not mention prerequisites, order of operations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is clear. The description adds the 'output is clipped' behavior, which is valuable. However, it does not explain what 'safe' means (e.g., path traversal restrictions) or how clipping works (controlled by max_chars).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the action and key constraint. No redundant words or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (indicated by context), the description is somewhat adequate. However, it misses explaining the 'safe' restriction and the role of max_chars in clipping. For a tool with 3 parameters and moderate complexity, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. However, the description does not mention any of the three parameters (path, workdir, max_chars), their roles, or defaults. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('read'), the resource ('safe text file from a work directory'), and a key constraint ('output is clipped'). This distinguishes it from sibling tools like list_files (which lists files) and various write tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., list_files for listing, or other file manipulation tools). There is no mention of when not to use it, such as for binary files or files outside the work directory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-idempotent, non-destructive operation, and the description adds key behavioral details: the simulation starts in the background and returns immediately with a job ID. This adequately discloses the async nature. However, it could mention that the job continues after the tool returns, but overall it is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient, but it could be restructured to include key parameter or behavioral notes without becoming verbose. It is front-loaded but lacks substance about parameters and workflow context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown) and sibling tools for lifecycle management, the description fails to connect to the broader workflow (e.g., use mdrun_status to monitor). It does not explain the return value beyond 'job id' or provide any usage hints. For a 6-parameter tool with heavy reliance on parameters, completeness is poor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description provides no explanation for any of the 6 parameters (tpr, ntomp, deffnm, nsteps, workdir, extra_args). It only says 'Start a simulation', which gives no insight into what each parameter means or how to use them. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start a simulation'), the async behavior ('in the background'), and the immediate return value ('with a job id'). It distinguishes well from sibling tools like mdrun_status, mdrun_stop, mdrun_cleanup, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the simulation runs in the background and returns a job ID, but it does not explicitly state when to use this tool versus alternatives (e.g., when to use mdrun_status to check progress). There is no mention of prerequisites or the need to follow up with other mdrun tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by stating 'Read'. The description adds minimal behavioral context beyond annotations (e.g., implies logs are pre-captured), but does not disclose any additional traits such as rate limits or persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the key action and resource. Every word serves a purpose, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown), the description need not detail return values. However, for a tool with 2 parameters and siblings, it could provide more context on when logs are available and how max_lines is used. It is minimally complete but lacks integration hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain parameters. It does not mention job_id or max_lines, leaving the agent with only parameter titles from the schema. The description adds no meaning beyond the schema's property names, failing to compensate for the lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the captured stdout/stderr log for a background simulation. The verb 'Read' and resource 'log' are specific, and it distinguishes from sibling tools like mdrun_status or mdrun_list that serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., mdrun_status for status, read_text_file for generic files). The description does not mention prerequisites such as requiring a completed simulation or that logs are only available after mdrun_start.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'with SIGTERM' beyond the destructiveHint annotation, but does not disclose side effects like process termination or data loss. With annotations already indicating destructiveness, the added value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and method. No wasted words; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required parameter) and the presence of an output schema, the description is mostly adequate but lacks parameter guidance. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, yet the description provides no additional meaning for the job_id parameter. It could mention what the ID refers to or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop'), the resource ('running background simulation'), and the method ('with SIGTERM'), distinguishing it from siblings like mdrun_status or mdrun_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., mdrun_cleanup) or prerequisites (e.g., job must be running). The description lacks context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint=true, destructiveHint=false) but adds no extra behavioral context beyond stating the action. The annotations already convey safety, so the description provides minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of six words with no filler. It is front-loaded with the action and immediately communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the existence of an output schema, the description is minimally adequate. However, it does not clarify whether hidden files are included, recursion behavior, or sorting, leaving some uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter workdir has 0% schema coverage, but the description mentions 'project work directory', implying the parameter is the directory path. This adds some meaning, but lacks details on format, defaults, or scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'List' and the resource 'files in a project work directory', which is specific and distinguishes it from sibling tools that focus on analysis or configuration tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_file or read_text_file. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the tool lists 'all known background simulations' and provides 'current status', which is useful context. Since annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, the description does not need to reiterate safety. It adds some value beyond annotations but does not disclose behavior like pagination or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the verb and key resource. Every word is necessary and informative, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, a output schema (which documents return values), and annotations that fully cover safety and idempotency, the description is complete. It tells the agent exactly what the tool does (list all background simulations and their status), which is sufficient for a simple query operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is effectively 100%. There are no parameters to explain, and the description does not need to add parameter-level details. The description adequately conveys the tool's input structure by implying no arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all known background simulations and their current status. It uses a specific verb ('List') and resource ('all known background simulations'). While it distinguishes itself from siblings like mdrun_status (which likely shows status of a single simulation), it does not explicitly differentiate from other list-like tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as mdrun_status (for checking a specific simulation) or mdrun_logs (for logs). No prerequisites or when-not-to-use scenarios are mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'return progress plus log tail' beyond the annotations, which already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. It is front-loaded and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (1 parameter, output schema exists, annotations present), the description is largely complete for its purpose, though it could elaborate on the meaning of 'progress' and 'log tail'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'job_id' exists, but the description provides no additional meaning beyond the schema. With 0% schema description coverage, the agent must infer from the parameter name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and the resource 'background simulation', and specifies the return value 'progress plus log tail'. This distinguishes it from sibling tools like mdrun_start and mdrun_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool. It is implied that it should be used after starting a simulation, but no alternatives or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveness. Description adds that running jobs require force=True, which is key behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 2-param tool with output schema. Could mention irreversibility but destructiveHint covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameter details beyond schema, but description gives context to 'force' parameter (required for running jobs). Schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Remove' and resource 'job record'. Distinguishes from siblings like mdrun_list and mdrun_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions when force is needed but no explicit guidance on when to use vs alternatives like mdrun_stop or mdrun_cleanup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds 'non-blocking' behavioral info beyond annotations, but does not detail error handling, output capture, or other side effects. Annotations already hint at mutability (readOnlyHint=false) but no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, efficient sentence, front-loaded with essential purpose and scope. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and existence of an output schema, the description is mostly complete. It covers the key constraint (non-blocking, dedicated tools) but could mention that the output is captured and returned as text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explain parameters. However, for a generic command wrapper, parameter names and types (args, stdin, timeout, workdir) are somewhat self-explanatory, though the format of args (e.g., including 'gmx' command) could be clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run' and resource 'non-blocking gmx subcommand not covered by a dedicated tool', distinguishing it from dedicated sibling tools like 'grompp' or 'mdrun_start'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies usage for subcommands without a dedicated tool, implying when not to use (when a dedicated tool exists). Sibling tools serve as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description is not required to repeat safety traits. It adds value by listing the specific data returned, which goes beyond the structured annotations. However, it does not mention potential behavior like error conditions or network requirements, but given the simplicity, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point. Every word is useful, and the key action 'Return' is front-loaded. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, comprehensive annotations, and an output schema (presumably documenting the return structure), the description is complete. It provides a clear summary of what the tool does, which is all that is needed for this simple informational command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100% by default. The description adds meaning beyond the empty schema by specifying what the tool returns (version, build config, binary path, project root). This helps the agent understand the output without needing to inspect the output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns specific GROMACS information: version, build config, binary path, and project root. The verb 'Return' plus explicit fields leaves no ambiguity about the tool's function, and it clearly distinguishes from sibling tools that perform other tasks like editing or running simulations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells what the tool does but does not provide explicit guidance on when to use it or when to avoid it. While the purpose is self-explanatory (get GROMACS info), there is no mention of alternatives or conditions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Alierkn/gromacs-mcp'

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