MCPymol

Overview Schema Source Related Servers Discussions Admin

local_resolution_view

Idempotent

Colours a map's isosurface by a local-resolution volume, converting Ångström breakpoints to sigma. Refuses mismatched voxel grids so colour never comes from the wrong place.

Instructions

Colour a map's isosurface by a local-resolution volume instead of by chain.

A single global resolution number misrepresents almost every map: a rigid core at 2.5 Å and a flexible periphery at 5 Å live in the same volume, and one isosurface invites the reader to believe all of it is equally real.

Two things make this harder than it looks, and both are handled. The volumes must share a voxel grid — colouring one map by another samples it at the first map's coordinates, so a mismatch in extent, spacing, origin or axis order draws colour from the wrong place and renders smooth, plausible and wrong. This tool refuses and names what differs. And PyMOL normalises maps on load, so ramp breakpoints given in Ångström must be converted to sigma against the RESOLUTION map's own header — a different sigma scale from the contour level, which comes from the density map's. Every breakpoint is reported in both units.

Local resolution is an estimate. Estimators disagree with each other on the same map, and the value at a voxel depends on the window and the mask as much as on the data.

Input Schema

Name	Required	Description	Default
`name`	No	Surface object name (defaults to "<map_obj>_localres")
`carve`	No	Carve radius in Ångström; ignored without a selection
`level`	No	Contour level for the isosurface. If omitted, 1.5 sigma is used.
`units`	No	Units of `level` only: "sigma" or "absolute". Ramp breakpoints are always in Ångström.	sigma
`breaks`	No	Ascending resolution breakpoints in Ångström. Defaults to the resolution map's own observed range.
`map_obj`	Yes	The density volume to draw, loaded through the load_map tool
`palette`	No	One PyMOL colour per breakpoint. Defaults to blue (best) through red (worst).
`res_obj`	Yes	A local-resolution volume (values in Ångström), loaded through the load_map tool
`ramp_name`	No	Ramp object name (defaults to "<res_obj>_ramp")
`selection`	No	Restrict the surface to a carve around this PyMOL selection
`validate_only`	No	Run the grid check and report, creating nothing

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.5.1Aug 9, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations declare a non-read-only, idempotent, non-destructive write, and the description adds substantive behaviour on top: a hard refusal on voxel-grid mismatch that names the differing attribute, Ångström-to-sigma conversion against the resolution map's header, and reporting of every breakpoint in both units. It does not say what happens if the default surface/ramp object names already exist, which is the main residual ambiguity for a mutating tool.

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 purpose sentence is correctly front-loaded, but the body drifts into essayistic justification (a rigid core and flexible periphery in the same volume) and a closing editorial caveat about estimators disagreeing that no agent needs in order to call the tool. Roughly a third of the text could be cut without losing operational 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?

With 11 parameters, full schema coverage, annotations and an output schema, the description covers the two failure modes an agent could not otherwise anticipate: grid mismatch and unit conversion. What is missing is comparatively minor — object creation/overwrite semantics for the generated surface and ramp.

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 coverage is 100%, so the baseline applies. The description does add real meaning for `breaks` and `level` by explaining that PyMOL normalises maps and that the sigma scales for the contour level and the ramp breakpoints come from two different maps, but it does not touch the other parameters.

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 opening line states a specific verb and resource: colour a map's isosurface by a local-resolution volume. The phrase 'instead of by chain' gestures at sibling colouring tools (spectrum, color, util_chainbow), though it never names a sibling directly, so an agent must infer the boundary from the family of isosurface/isomesh tools.

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?

Usage context is implied rather than stated: the description assumes both volumes were loaded through load_map and that their grids must match, and it describes validate_only as a dry-run. There is no explicit 'use this instead of isosurface/density_view when...' routing and no stated prerequisites beyond the grid match.

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

Deploy Server