Skip to main content
Glama
Sign In
MCPymol

MCPymol

by chemrich
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

render

DestructiveIdempotent

Generates a ray-traced image of the current PyMOL scene and returns it for visual inspection and iteration, replacing separate ray and PNG calls that leave only a filename.

Instructions

Renders the current scene and returns the image, so you can see it.

Use this instead of calling ray and png separately — those leave you holding a filename you cannot look at. Call this after setting up a view to check what it actually looks like, and iterate.

Every render is ray-traced, which takes seconds to minutes on a large assembly. ray_trace=False is accepted but ignored: PyMOL's fast unshaded frame grab needs its GUI thread, which this plugin does not run on, so that path wrote blank images. Render smaller to render faster.

Input Schema

NameRequiredDescriptionDefault
widthNoImage width in pixels. Larger costs render time and context.
heightNoImage height in pixels.
filenameNoOptional path to also keep the PNG at. Without it the render goes to a temporary file that is cleaned up afterwards — except when the image is too large to inline, where the file is kept so you still have the render.
ray_traceNoKept for compatibility and ignored — every render is ray-traced, because PyMOL's unshaded OpenGL capture does not work over this bridge. Use a smaller width/height to render faster.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.1

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that every render is ray-traced and costs seconds to minutes on large assemblies, that ray_trace is accepted but silently ignored and why (GUI thread unavailable, prior path wrote blank images), and that a temp file is deleted unless the image is too large to inline. These are exactly the non-obvious traits that affect invocation choices.

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?

Front-loads the core action in the first sentence, then the alternative, then the latency/ray_trace caveat. Slightly repetitive since the ray_trace no-op is stated in both description and schema, but the redundancy serves as a warning against a trap parameter.

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?

With no output schema, the description still explains the return shape (an inline image, or a retained file when too large to inline) and the latency profile. Nothing an agent needs to call it correctly — cost, side effects, output form — is left unstated.

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?

Schema description coverage is 100%, so each parameter is already documented, including the width/height cost tradeoff and the ray_trace no-op. The description reinforces the perf guidance ("render smaller to render faster") and adds the blank-image rationale, but adds no new syntax, ranges, or constraints beyond the 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?

States a specific verb and resource ("Renders the current scene and returns the image") plus the payoff ("so you can see it"). It also explicitly names the siblings it replaces (ray and png), so an agent can distinguish it without inspecting schemas.

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?

Gives both when-to-use and when-to-use-something-else: use this instead of ray+png because those return a filename you cannot view, and call it after setting up a view to check and iterate. The alternative and the selecting condition are spelled out.

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

Deploy Server

Other Tools