Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vmd-mcp Load 1UBQ.pdb, compute RMSD, and render a NewCartoon image at 1200x900."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Drive VMD headlessly from any MCP client.
Analyse structures & trajectories (RMSD, radius of gyration, SASA, atom selections) and ray-trace publication-quality images with no display — all through the Model Context Protocol.
VMD is the standard tool for molecular visualisation and trajectory analysis, but its power
lives behind a GUI and a Tcl console. vmd-mcp runs VMD in text mode, turns the common
analyses and rendering into clean MCP tools, and parses the results back into structured data —
so an LLM agent can measure an RMSD curve or render a labelled cartoon without a display,
without you writing a line of Tcl.
Related MCP server: MCP-GMX-VMD
Headless analysis — molecule summaries, atom-selection counts, RMSD, RMSF, radius of gyration, SASA, selection distances, and contact pairs.
Headless rendering — ray-traces images with VMD's built-in Tachyon and saves PNG, no X11 / display required. Choose explicit render controls or curated presets.
MCP-native guidance — resources expose capabilities, recent outputs, and example recipes; prompts help clients render molecules, analyze trajectories, and debug VMD failures.
Safer local defaults — structure inputs must exist, render outputs stay under
VMD_MCP_ROOT by default, high-risk tool inputs are bounded, and MCP tool annotations mark
read-only, write, and escape-hatch behavior.
Hybrid tool design — typed helpers for common jobs plus a generic run_tcl escape
hatch that runs any VMD Tcl and returns bounded output plus your @@VMDMCP@@-tagged results.
Robust in non-interactive sessions — works around VMD's -eofexit/stdin and
display resize quirks that otherwise break headless runs (see How it works).
Zero-config discovery — finds VMD on PATH or in macOS .app bundles (override with VMD_BIN).
Category | Tool | Purpose |
Introspect |
| VMD version + resolved launcher path |
| Atoms, frames, protein/water/chain/residue counts | |
| Count atoms matching a VMD selection | |
Analyse |
| Per-frame R_gyr + min/max/mean |
| Per-frame RMSD vs a reference frame (optional alignment) | |
| Per-atom RMSF across a trajectory | |
| Per-frame solvent-accessible surface area | |
| Center-to-center distance between two selections | |
| Atom-index contact pairs between selections | |
Render |
| Headless Tachyon ray-trace → PNG |
| Curated render presets for common figures | |
Escape hatch |
| Any VMD Tcl script (with marker parsing) |
Type | Name / URI | Purpose |
Resource |
| Tool categories, allowed render options, presets, safety defaults |
Resource |
| Recent files below |
Resource |
| Compact example workflows |
Prompt |
| Safe render workflow using |
Prompt |
| RMSD/RMSF/R_gyr/SASA trajectory workflow |
Prompt |
| Triage path for path, selection, rendering, and Tcl errors |
VMD installed and runnable (GUI build is fine; it is used in -dispdev text mode).
Python ≥ 3.10.
PNG conversion: macOS sips (built in) or ImageMagick. Without either, renders are
saved as .tga.
An MCP client (e.g. Claude Code or Claude Desktop).
# Run straight from GitHub with uv — no global install needed
uvx --from git+https://github.com/Alierkn/vmd-mcp vmd-mcppipx install git+https://github.com/Alierkn/vmd-mcp
# or
pip install git+https://github.com/Alierkn/vmd-mcp
vmd-mcp # starts the stdio serverclaude mcp add vmd --scope user -- \
uvx --from git+https://github.com/Alierkn/vmd-mcp vmd-mcpCheck: claude mcp list → vmd: … ✔ Connected.
{
"mcpServers": {
"vmd": {
"command": "uvx",
"args": ["--from", "git+https://github.com/Alierkn/vmd-mcp", "vmd-mcp"],
"env": { "VMD_BIN": "/Applications/VMD2b1.app/Contents/MacOS/startup.command" }
}
}
}Env var | Default | Meaning |
| auto ( | Path to the VMD launcher |
|
| Where rendered images / scratch are written |
| unset / | Set to |
"Load
bpti.pdb, tell me how many residues and chains it has, then render a Structure-colored NewCartoon at 1200×900 and save it asbpti.png."
"For
topol.tpr+md.xtc, compute the CA-RMSD over the trajectory aligned to frame 0, and report min / max / mean."
"Using
examples/sample.pdb, run the bundled VMD smoke workflow and rendersample.pngwith theatomistic_linespreset."
Each tool generates a small Tcl script and runs vmd -dispdev text -e script.tcl. Results are
emitted with a @@VMDMCP@@ key=value marker that the server parses into structured data.
Two headless-specific gotchas are handled for you:
-eofexit + non-tty stdin would make VMD exit before a long render finishes — so the
server relies on a trailing quit and stdin=DEVNULL instead.
display resize is unreliable without a real display — so render resolution is set via
the -size W H command-line flag.
Images are ray-traced with render TachyonInternal (built-in, no external renderer needed) and
converted TGA → PNG via macOS sips, ImageMagick magick, or ImageMagick convert when
available. If no converter is present, the .tga is kept.
vmd-mcp is a local automation server, not a remote multi-user service. Typed tools validate
paths, dimensions, timeouts, selections, render methods, and color modes before launching VMD.
render_image writes below VMD_MCP_ROOT unless VMD_MCP_ALLOW_ABSOLUTE_OUTPUTS=1 is set.
The run_tcl tool intentionally remains an escape hatch for advanced VMD workflows. It is marked
as a destructive MCP tool, capped by timeout and output size, and should only be used with Tcl you
trust.
git clone https://github.com/Alierkn/vmd-mcp && cd vmd-mcp
uv sync --extra dev
uv run pytest # VMD-dependent tests auto-skip if VMD is absent
RUN_VMD_INTEGRATION=1 uv run pytest -m integration
uv run python scripts/smoke_vmd.py
uv run ruff check .
uv build
uvx twine check dist/*See CONTRIBUTING.md.
gromacs-mcp — companion MCP server that runs GROMACS simulations. Pair them: simulate with GROMACS, then analyse & visualise with VMD.
MIT © Ali Erkan Ocaklı
Find atom-index contact pairs between two selections at one frame.
cutoff is in Angstrom. The total contact count is always returned; the
explicit pairs list is clipped to max_pairs to keep MCP responses
bounded.
| Name | Required | Description | Default |
|---|---|---|---|
| frame | No | ||
| cutoff | No | ||
| max_pairs | No | ||
| structure | Yes | ||
| selection1 | Yes | ||
| selection2 | No | all | |
| trajectory | No |
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.
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.
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.
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.
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.
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.
Count atoms matching a VMD atom-selection expression
(e.g. "protein and name CA", "resname LIG", "within 5 of protein").
| Name | Required | Description | Default |
|---|---|---|---|
| selection | Yes | ||
| structure | Yes | ||
| trajectory | No |
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.
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.
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.
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.
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.
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.
Distance between the centers of two atom selections.
By default the distance is measured at one frame. Set all_frames=True to
return a per-frame series for a trajectory.
| Name | Required | Description | Default |
|---|---|---|---|
| frame | No | ||
| structure | Yes | ||
| all_frames | No | ||
| selection1 | Yes | ||
| selection2 | Yes | ||
| trajectory | No | ||
| mass_weighted | No |
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.
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.
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.
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.
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.
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.
Load a structure (and optional trajectory) and report a summary: total atoms, number of frames, protein/water/backbone atom counts, and the number of distinct chains and residues.
| Name | Required | Description | Default |
|---|---|---|---|
| structure | Yes | ||
| trajectory | No |
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.
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.
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.
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.
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.
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.
Radius of gyration (nm-scale, in VMD's Angstrom units) of a selection, computed for every frame. Returns a per-frame series plus min/max/mean.
| Name | Required | Description | Default |
|---|---|---|---|
| selection | No | protein | |
| structure | Yes | ||
| trajectory | No | ||
| mass_weighted | No |
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.
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.
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.
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.
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.
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.
Ray-trace a molecular image HEADLESSLY with VMD's built-in Tachyon and save it as PNG (no display needed).
representation is one of the supported VMD draw methods; coloring is
one of the supported VMD color methods. The image is written under
VMD_MCP_ROOT by default. Absolute output paths are rejected unless
VMD_MCP_ALLOW_ABSOLUTE_OUTPUTS=1 is set.
| Name | Required | Description | Default |
|---|---|---|---|
| frame | No | ||
| width | No | ||
| height | No | ||
| output | No | render.png | |
| coloring | No | Structure | |
| selection | No | all | |
| structure | Yes | ||
| background | No | white | |
| trajectory | No | ||
| representation | No | NewCartoon |
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.
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.
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.
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.
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.
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.
Render a molecule using a curated publication-oriented visual preset.
Presets reduce brittle representation/coloring choices while still allowing
a custom atom selection when needed.
| Name | Required | Description | Default |
|---|---|---|---|
| frame | No | ||
| width | No | ||
| height | No | ||
| output | No | render.png | |
| preset | No | publication_cartoon | |
| selection | No | ||
| structure | Yes | ||
| trajectory | No |
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.
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.
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.
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.
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.
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.
RMSD of a selection across a trajectory relative to a reference frame.
With align=True each frame is first least-squares fitted onto the
reference (rigid-body alignment) before measuring RMSD. Returns a per-frame
series plus min/max/mean (Angstrom).
| Name | Required | Description | Default |
|---|---|---|---|
| align | No | ||
| selection | No | protein and name CA | |
| structure | Yes | ||
| trajectory | Yes | ||
| reference_frame | No |
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.
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.
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.
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.
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.
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.
Per-atom root-mean-square fluctuation (RMSF) across a trajectory.
Returns one row per selected atom plus min/max/mean RMSF in Angstrom. Use
selections such as "protein and name CA" for compact per-residue traces.
| Name | Required | Description | Default |
|---|---|---|---|
| selection | No | protein and name CA | |
| structure | Yes | ||
| trajectory | Yes |
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.
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.
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.
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.
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.
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.
Run an ARBITRARY VMD Tcl script headlessly and return its combined
stdout/stderr plus any parsed @@VMDMCP@@ marker lines.
Emit results from your script with: puts "@@VMDMCP@@ key=value ...".
Use this for any analysis not covered by a dedicated tool (measure hbonds,
measure contacts, custom per-residue loops, cluster analysis, ...).
End the script with quit.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | ||
| timeout | No |
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.
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.
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.
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.
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.
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.
Solvent-accessible surface area (Angstrom^2) of a selection, per frame.
srad is the solvent probe radius (1.4 A ~ water).
| Name | Required | Description | Default |
|---|---|---|---|
| srad | No | ||
| selection | No | protein | |
| structure | Yes | ||
| trajectory | No |
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.
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.
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.
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.
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.
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.
Return the VMD version/banner and the resolved launcher path. Use this first to confirm the server can reach a working VMD.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0contactscount_atomsdistancemolecule_inforadius_of_gyrationrender_imagerender_presetrmsdrmsfrun_tclsasavmd_infoEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cloud Blender for AI agents: scenes, assets, renders, MP4, STL, GLB — over hosted remote MCP.
QuLab MCP remote server (Streamable HTTP) for computational science and lab tools.
MCP server for Google Veo AI video generation
Remote MCP server for XDaLa workflow preparation on XGR.Network.
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
