Skip to main content
Glama
Sign In
MCPymol

MCPymol

by chemrich
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

print_ribbon_view

Idempotent

Configures thick β-strand ribbons and a continuous backbone spine for gap-free, watertight 3D printing, then supports exporting the fused solid.

Instructions

Chunky β-arrow ribbons plus a continuous backbone "spine", tuned for rigid, gap-free 3D printing.

Configures the look developed for FDM printing: thick β-strand arrows and a fat helix on the main object with loop cartoon hidden, plus a separate <obj>_spine object showing PyMOL's cartoon tube (which ignores secondary structure) running unbroken through the whole backbone. The spine threads through the strand bodies, so when the two objects are exported together the voxel step fuses them into one watertight solid with no strand→loop discontinuity. The spine also acts as internal rebar, reinforcing the thin junctions for print rigidity.

The style is set on the object and its spine only; other objects and PyMOL's global settings are left alone. The spine is carried through residues with no CA atom, such as GFP's chromophore, without renaming anything.

PyMOL draws a strand √2 times the strand_width and strand_thickness settings, so the defaults (2.8, 2.0) give strands about 4.0 x 2.8 Å, and a β-barrel's wall closes up. To see into a barrel, use strand_width=2.0, strand_thickness=1.0, spine_in_strands=False. Measured on GFP (2b3p): the see-through share of the barrel wall goes from 8% to 29%; thinner strands alone leave 399 ų of spine bulging out of them, which spine_in_strands=False takes to 1 ų; and it still exports as one solid (unbridged at the chromophore, it split 69:31).

After calling this, export the fused solid with::

print_export(obj_name="<obj>",
             groups="<obj>=(<obj> or <obj>_spine)",
             representation="cartoon",
             method="voxel", voxel_pitch=0.2)

Input Schema

NameRequiredDescriptionDefault
obj_nameYesPyMOL object name (e.g. "1abc").
spine_radiusNoRadius (Å) of the continuous backbone tube. Larger values give more internal reinforcement. Default 0.9.
strand_widthNoβ-strand width setting (PyMOL's cartoon_rect_length). PyMOL draws the strand √2 times this wide: the default 2.8 is about 4.0 Å. 2.0 (2.8 Å) opens the gaps in a β-barrel.
strand_overlapNoWith spine_in_strands=False, the residues of spine kept at each end of a strand, where it fuses with the loop. At least 2: with 1, 10 of GFP's 22 strand ends lost their junction.
bridge_modifiedNoCarry the spine through residues that are peptide-linked on both sides but have no CA atom, such as GFP's chromophore (CRO), which otherwise break it. Done on the spine only, with per-atom cartoon_trace_atoms and PyMOL's no_smooth flag on the Cα either side; no atom is renamed or renumbered. Default true.
spine_in_strandsNoTrue (default) runs the spine through the strands as well, where it shows as bumps along thin ones. False takes it out of each strand's interior, keeping strand_overlap residues at each end so the loops still fuse to the strands.
strand_thicknessNoβ-strand thickness setting (PyMOL's cartoon_rect_width). PyMOL draws the strand √2 times this thick: the default 2.0 is about 2.8 Å, 1.0 about 1.4 Å.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.5.2
    • addedInput schema / properties / bridge_modified
      Added value: +{
+  "default": true,
+  "description": "Carry the spine through residues that are peptide-linked on both sides but have no CA atom, such as GFP's chromophore (CRO), which otherwise break it. Done on the spine only, with per-atom cartoon_trace_atoms and PyMOL's no_smooth flag on the Cα either side; no atom is renamed or renumbered. Default true.",
+  "title": "Bridge Modified",
+  "type": "boolean"
+}
    • addedInput schema / properties / spine_in_strands
      Added value: +{
+  "default": true,
+  "description": "True (default) runs the spine through the strands as well, where it shows as bumps along thin ones. False takes it out of each strand's interior, keeping strand_overlap residues at each end so the loops still fuse to the strands.",
+  "title": "Spine In Strands",
+  "type": "boolean"
+}
    • changedInput schema / properties / spine_radius / description
      Previous value: -"Radius (A) of the continuous backbone tube. Larger values give more internal reinforcement. Default 0.9."New value: +"Radius (Å) of the continuous backbone tube. Larger values give more internal reinforcement. Default 0.9."
    • addedInput schema / properties / strand_overlap
      Added value: +{
+  "default": 2,
+  "description": "With spine_in_strands=False, the residues of spine kept at each end of a strand, where it fuses with the loop. At least 2: with 1, 10 of GFP's 22 strand ends lost their junction.",
+  "title": "Strand Overlap",
+  "type": "integer"
+}
    • addedInput schema / properties / strand_thickness
      Added value: +{
+  "default": 2,
+  "description": "β-strand thickness setting (PyMOL's cartoon_rect_width). PyMOL draws the strand √2 times this thick: the default 2.0 is about 2.8 Å, 1.0 about 1.4 Å.",
+  "title": "Strand Thickness",
+  "type": "number"
+}
    • addedInput schema / properties / strand_width
      Added value: +{
+  "default": 2.8,
+  "description": "β-strand width setting (PyMOL's cartoon_rect_length). PyMOL draws the strand √2 times this wide: the default 2.8 is about 4.0 Å. 2.0 (2.8 Å) opens the gaps in a β-barrel.",
+  "title": "Strand Width",
+  "type": "number"
+}
  2. Changed2 schema fields changedv1.5.1
    • addedInput schema / properties / obj_name / description
      Added value: +"PyMOL object name (e.g. \"1abc\")."
    • addedInput schema / properties / spine_radius / description
      Added value: +"Radius (A) of the continuous backbone tube. Larger values give more internal reinforcement. Default 0.9."
  3. First observedv1.2.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the mutation/idempotency/safety profile; the description adds substantial context beyond that: changes are scoped to the object and its spine, other objects and global settings are untouched, nothing is renamed or renumbered, and the spine is deliberately carried through CA-less residues such as GFP's chromophore. It also discloses the downsteam consequence (two objects must be exported together to voxel-fuse into one watertight solid) and cites measured outcomes (8%→29% see-through, 399 ų→1 ų spine bulge, a 69:31 split when unbridged).

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?

It is front-loaded, starting with what the style is and why, then side effects, then tuning advice, then the required export step — a logical order. It is on the long side and repeats the √2 strand-scaling fact that already appears in the schema's `strand_width` and `strand_thickness` descriptions, which costs a little concision but each paragraph carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool that mutates object state and creates a companion object, the description covers scope of effects, fidelity details (chromophore bridging, junction overlap), a recommended parameter set for a specific goal, and the mandatory follow-up export call. With an output schema present it does not need to describe return values, and nothing essential for correct invocation seems missing.

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?

With 100% schema coverage the schema already documents each parameter, so the baseline is 3. The description still adds real meaning the schema doesn't: it explains the √2 scaling relationship (defaults of 2.8/2.0 yielding roughly 4.0 x 2.8 Å strands), and ties parameter combinations to an observable goal — opening β-barrel walls while still exporting as a single solid.

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 opening line states a concrete verb (configures) and resource (chunky β-arrow ribbons plus a continuous backbone spine) with a stated goal (rigid, gap-free 3D printing). It also explains the mechanics that distinguish it from sibling view tools: it sets style on the target object plus a separate `<obj>_spine` object rather than producing a rendering.

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?

It gives clear invocation context — this is the look for FDM printing, and afterward you must export with a specific `print_export(...)` call spelled out verbatim. It also gives an in-tool alternative configuration (`strand_width=2.0, strand_thickness=1.0, spine_in_strands=False`) for seeing into a barrel, though it never explicitly names when *not* to use it versus on-screen view siblings like cinematic_view or textbook_view.

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