vmd-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.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: contacts for atom pairs, count_atoms for counting, distance for center distance, molecule_info for summary, radius_of_gyration for RG, render_image/image renderings, rmsd/rmsf for structural alignment, run_tcl for arbitrary scripts, sasa for surface area, and vmd_info for version. No two tools have overlapping functionality.
Naming Consistency4/5
All names use lowercase underscores. Some are single nouns (contacts, distance, rmsd, rmsf, sasa) while others are verb_noun (count_atoms, render_image, render_preset, run_tcl). This is mildly inconsistent but still readable and predictable.
Tool Count5/5
With 12 tools, the set covers a wide range of common VMD analyses (distance, RMSD, RMSF, SASA, contacts, radius of gyration, rendering) without being overwhelming. The count is appropriate for the domain.
Completeness4/5
The tools cover core analysis tasks (geometry, structural alignment, surface area, rendering, counting, contacts). Missing explicit tools for angles/dihedrals or hydrogen bonds, but the run_tcl fallback allows arbitrary scripts, filling most gaps.
Average 3.6/5 across 12 of 12 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under 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 destructiveHint=true, which is counterintuitive for a rendering tool (likely due to file output). The description does not clarify side effects like file creation or overwriting, nor does it disclose permission requirements or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with the first sentence providing the core purpose and the second adding context about presets. It is front-loaded and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (including a required 'structure'), no schema descriptions, and no output schema, the description is incomplete. It omits essential details about input format, output file behavior, and trajectory handling, leaving critical gaps for proper tool invocation.
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 only mentions 'selection' and 'preset' (implicitly via the concept of presets). It fails to explain critical parameters like 'structure', 'output', 'frame', 'trajectory', or dimensional attributes, leaving the agent with insufficient semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a molecule using curated presets, with a specific focus on publication-oriented visuals. It implies differentiation from a generic render by emphasizing presets, but does not explicitly distinguish from sibling tool 'render_image'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'render_image'. The mention of 'reducing brittle choices' subtly suggests usage for publication-quality renders, but lacks clear when-to-use or when-not-to-use instructions.
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 provide readOnly, idempotent, non-destructive hints. Description adds output format details (per-frame series, min/max/mean) but does not disclose edge cases or limitations. Adequate but not exceptional 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with essential info. No fluff, but could be more structured (e.g., separating purpose from output).
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?
Missing parameter details and usage context. With 4 parameters and no output schema, the description is insufficient for correct invocation. Does not mention optionality or defaults.
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 does not explain any parameters (selection, structure, trajectory, mass_weighted). Only mentions 'selection' vaguely. Fails to compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes radius of gyration per frame for a selection, with units (nm-scale in Angstroms) and output (per-frame series plus min/max/mean). This distinguishes it from sibling tools like rmsd or sasa.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the behavioral trait 'per frame' (iterating over trajectory frames), which is beyond annotations. However, it does not elaborate on other behaviors like error conditions or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no fluff. It front-loads the primary purpose and adds a specific detail about the probe radius parameter. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description should cover return value format and key parameter details. It only addresses 'srad' and the concept of per-frame calculation. Missing details on default selection, required structure, optional trajectory, and expected output shape (e.g., a value per frame or total) make it incomplete for an agent to use confidently.
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 compensate. It explains the meaning of 'srad' (probe radius, default 1.4 A) but fails to describe the other three parameters (selection, structure, trajectory). This leaves significant ambiguity for the agent, as key inputs are undocumented.
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 computes solvent-accessible surface area for a given selection per frame, specifying the unit (Angstrom^2). This is a specific verb+resource that distinguishes it clearly from sibling tools like distance or rmsd, which compute different properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no conditions for use, and no exclusions. It only defines what it does, leaving the agent to infer appropriateness without context on limitations or preferences.
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 idempotentHint, readOnlyHint, and destructiveHint=false. The description adds no further behavioral context beyond stating it counts atoms, which is obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with inline code examples is concise, but could benefit from structured formatting for 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 3 parameters and no output schema, the description fails to explain the return value (expected integer count) and the purpose of 'trajectory' parameter, leaving important gaps.
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 the 'selection' parameter is addressed with examples; the 'structure' and 'trajectory' parameters are left unexplained despite schema coverage being 0%. The description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Count atoms matching a VMD atom-selection expression', using a specific verb and resource. It is distinct from sibling tools like contacts, distance, and rmsd which measure other properties.
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?
Examples of valid selections are provided, which imply usage but there is no explicit guidance on when to use this tool vs alternatives like contacts or rmsd.
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 behavioral details beyond annotations: it explains that cutoff is in Angstrom, total count always returned, and pairs list clipped to max_pairs. These are not present in 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 concise with two sentences and a code block, front-loading the purpose and key behavioral notes. No redundant information.
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, no parameter descriptions in schema, and no output schema, the description is insufficient. It does not explain the frame parameter, selection2, trajectory, or the structure parameter. The return format is also not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains only two parameters (cutoff, max_pairs) indirectly, while there are seven total. Schema description coverage is 0%, so the description should cover more parameters.
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 'Find atom-index contact pairs between two selections at one frame', which is a specific verb+resource. It distinguishes itself from sibling tools like 'distance' by focusing on contacts and clipping behavior.
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 'distance' or 'rmsd'. It does not specify prerequisites or contexts.
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 destructiveHint=true, and the description confirms file writing behavior. It adds the crucial detail about absolute path rejection with an environment variable, which is not in annotations. However, it does not mention whether existing files are overwritten or other 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two paragraphs) and front-loaded with the core purpose. However, the second paragraph could be more succinct, and some information about parameters could be structured for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, no output schema, and destructive behavior, the description is incomplete. It explains output path restrictions but omits return value details, behavior of parameters like frame or trajectory, and potential overwrite warnings.
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 only vaguely mentions that representation and coloring are VMD methods, but does not explain the majority of parameters (frame, width, height, output, selection, background, trajectory, etc.). This leaves the agent with minimal guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it ray-traces a molecular image headlessly using VMD's Tachyon and saves as PNG. It specifies the verb (render), resource (molecular image), and context (headless, no display). This distinguishes it from sibling tools like render_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage constraints (absolute output paths rejected unless VMD_MCP_ALLOW_ABSOLUTE_OUTPUTS=1) and mentions headless operation, but does not explicitly state when to use this tool versus alternatives like render_preset or list any exclusions.
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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so agent knows it's safe. Description adds output behavior: per-atom values plus min/max/mean in Angstrom, and that selection affects granularity. 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?
Two concise sentences, front-loaded with the core purpose. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of required parameters (structure, trajectory) and does not mention computation cost, trajectory format, or limitations. No output schema, so return format is only partially described.
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 description must compensate. It only partially explains the 'selection' parameter with an example, but leaves 'structure' and 'trajectory' (required) unexplained. Agent may not know they are file paths or identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool computes per-atom RMSF across a trajectory and describes output (per atom plus min/max/mean in Angstrom). It distinguishes from sibling rmsd (RMS deviation) by focusing on fluctuation across time.
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?
Provides a concrete example of selection usage ("protein and name CA") for compact per-residue traces, but does not explain when to use RMSF vs. alternatives like contacts, distance, or rmsd. No when-not-to-use or exclusions.
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 read-only and idempotent behavior. The description adds that alignment is done via least-squares fitting, and output includes per-frame series plus min/max/mean in Angstrom, providing useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the main purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description covers key aspects: what it calculates, alignment option, output summary statistics, and units. It could mention the reference_frame parameter briefly, but overall 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?
Schema description coverage is 0%. The description only briefly explains the align parameter and mentions default selection, but does not describe structure, trajectory, or reference_frame parameters, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes RMSD of a selection across a trajectory relative to a reference frame, with optional alignment. This distinguishes it from siblings like rmsf and distance.
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 what the tool does but provides no explicit guidance on when to use it versus alternatives. It only implies usage through its specificity.
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 declare readOnlyHint and idempotentHint true. Description adds that measurement is by default at one frame, supplementing the safety profile with operational detail. 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?
Two sentences front-loaded with purpose and additional behavior, no redundant information. Efficient and to the point.
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?
Description covers core behavior and optional all_frames mode, but omits return format (e.g., distance value, units) and fails to explain key parameters. Without output schema, more context would be beneficial.
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 coverage is 0%, but description only explains 'all_frames' and implicit reference to 'selection1' and 'selection2' as atom selections via the tool's purpose. Parameters like 'structure', 'trajectory', 'mass_weighted', and 'frame' are not described. Insufficient compensation for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool computes distance between centers of two atom selections. It distinguishes itself from siblings like contacts and rmsd by specifying geometric center measurement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains default single-frame measurement and optional per-frame series for trajectories, providing context for when to use each mode. No explicit when-not-to-use but adequate for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds value by specifying exactly what the tool computes (atom counts, frame count, chains, residues) and that it can load an optional trajectory, which goes beyond the annotation metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, immediately stating the main action and listing the computed outputs. No redundant words, and the structure is front-loaded with the tool's primary purpose.
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?
Despite lacking an output schema, the description adequately explains the return value (summary counts). The tool is simple and the description covers all key aspects: input, optional parameter, and output content.
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 only restates parameter names ('structure', 'trajectory') without clarifying their format (e.g., file path or identifier) or constraints. The optionality of trajectory is already captured by the schema default of null.
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 loads a structure and trajectory and reports a summary with specific counts (atoms, frames, protein/water/backbone, chains, residues). This specific verb+resource combination distinguishes it from siblings like count_atoms or rmsd that focus on single metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a broad structural summary is needed (e.g., assessing system composition) but does not explicitly state when to avoid using it or provide alternative tools for specific queries.
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 destructiveHint=true, readOnlyHint=false. The description adds context: it runs headlessly, returns combined stdout/stderr and parsed marker lines, and requires the script to end with 'quit'. This goes beyond annotations by detailing output format and termination requirement.
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 three sentences and front-loads the core action. It is efficient, but the parameter descriptions are missing, which slightly detracts from completeness.
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 12 sibling tools, the description effectively differentiates the tool. It explains output format and basic usage. However, it lacks error handling information and doesn't cover the timeout parameter, leaving some gaps for a flexible tool.
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 coverage is 0%, yet the description only indirectly mentions the 'script' parameter via usage examples. The 'timeout' parameter is not mentioned at all. No parameter descriptions are provided, leaving the agent uncertain about what to pass for each parameter.
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 runs arbitrary VMD Tcl scripts headlessly, specifying the verb 'run' and the resource 'VMD Tcl script'. It distinguishes from sibling dedicated tools by explicitly listing them as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool 'for any analysis not covered by a dedicated tool' and lists examples of dedicated tools (measure hbonds, etc.), providing clear when-to-use guidance. It does not explicitly state when not to use it, but the implication is strong.
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, openWorldHint, idempotentHint, destructiveHint=false. Description adds that it returns version/banner and path for server connectivity validation, which is useful 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?
Two concise sentences with no wasted words. The key purpose and usage guidance are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple info tool with no parameters, the description sufficiently explains what it returns and when to use it. No output schema needed since returns simple strings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, 100% schema coverage). Description doesn't need to add param info; baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns the VMD version/banner and resolved launcher path. The purpose is specific and distinct from siblings, none of which are diagnostic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this first to confirm the server can reach a working VMD', providing clear guidance on when to use. No alternatives needed for a zero-parameter diagnostic tool.
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:

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

Score Badge

Copy to your README.md:

[![vmd-mcp MCP server](https://glama.ai/mcp/servers/Alierkn/vmd-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Alierkn/vmd-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/vmd-mcp'

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