protein-blender-mcp

add_style

Applies a style layer to a molecule or selected atoms, with optional color and material, to build layered protein visualizations in Blender.

Instructions

Add a style layer to a molecule, optionally limited to a selection.

Layers stack, so "cartoon for the protein plus sticks for the ligand" is two calls. molecule is the object name from get_scene_info (default: the active or most recently loaded one). label names the layer for later removal.

options passes extra settings straight to the Molecular Nodes style node, e.g. cartoon: {"quality": 4, "helix_shape": "Cylinder", "loop_radius": 0.3, "sheet_arrows": "Flat"}; surface: {"quality": 4, "scale": 1.5, "separate_by": "chain_id"}; spheres/sticks: {"scale": 0.8}.

Selections use MDAnalysis selection syntax, for example: "chainID A" one chain (also "segid A") "chainID A B" several chains "protein" / "nucleic" all protein / DNA-RNA atoms "resid 10:50" residue range "resname HEM" a ligand or residue type by name "not protein and not nucleic and not water" ligands and other het groups "protein and around 5 resname ATP" binding pocket within 5 A "backbone" / "name CA" backbone atoms / alpha carbons "resname LYS ARG" / "resname ASP GLU" basic / acidic residues Combine with and / or / not and parentheses.

Color can be a scheme or a single color. Schemes: "element", "chain", "rainbow" (N->C terminus), "secondary_structure", "residue_type", "b_factor", "plddt", "goodsell". Single colors: a name ("red", "skyblue", "gold"...), a hex code ("#ff8800") or an RGB list ([255, 136, 0]).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "style": "<style>"
    },
    "name": "add_style"
  }
}

Input Schema

Name	Required	Description	Default
`color`	No
`label`	No
`style`	Yes
`options`	No
`material`	No
`molecule`	No
`selection`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the burden and mostly does: it discloses that operations are additive/non-destructive (layers stack), that labels exist so a layer can be removed later, and that options are forwarded verbatim to the Molecular Nodes style node. It omits failure behavior (selection matching nothing, invalid molecule name) and whether anything is returned.

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 definition is front-loaded with the core action, then organized into labeled paragraphs for options, selections and colors. The selection example list is long but each line illustrates a distinct syntax form, so most of the bulk earns its place; trimming a few examples would tighten it without losing meaning.

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 7-parameter tool with no annotations and no output schema, the description supplies the call-shape knowledge an agent needs: layering model, molecule resolution default, selection grammar and color grammar. The remaining gaps are the undocumented material parameter and no statement about errors or side effects on the scene.

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 0%, so the description must compensate. It does well for molecule (object name from get_scene_info, default active/most recent), label (used for later removal), options (per-style example payloads), selection (extensive MDAnalysis syntax examples) and color (schemes, names, hex, RGB list). However, the material parameter (default/ambient_occlusion/flat/squishy/transparent) is never mentioned, and ribbon and ball_and_stick receive no options examples.

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 first sentence states a specific verb and resource ("Add a style layer to a molecule") plus a scope modifier ("optionally limited to a selection"). The stacking note ("cartoon for the protein plus sticks for the ligand is two calls") makes clear how this differs from remove_style and clear_styles in the sibling set.

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 real usage context: layers stack so combining styles requires multiple calls, and molecule defaults to the active or most recently loaded object. It does not explicitly state when to prefer remove_style or clear_styles, nor any prerequisites (e.g. a loaded structure or the Molecular Nodes addon), so it stops short of full alternative guidance.

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

Deploy Server