Skip to main content
Glama

superposition_view

Idempotent

Superpose two loaded protein structures and color the mobile one by per-residue shift, revealing where conformational changes occur rather than only overall RMSD.

Instructions

Superposes two structures and colors the mobile one by per-residue shift.

An RMSD alone tells you that something moved, not where. This superposes mobile onto target, measures how far each residue's CA ended up from its counterpart, and colors the mobile structure blue (unchanged) through white to red (most shifted). The target is left as a grey reference cartoon.

Best on two states of the same protein — apo vs holo, open vs closed, a mutant against wild type. Residues are paired by chain and residue number, falling back to residue number alone when the two use different chain IDs.

Both structures have to be loaded first, and fetch_structure clears the session by default — so fetch the second one with replace=False or it will replace the first. If either entry is a multimer, compare single chains (create one object per chain): superposing one dimer onto another fits the assembly rather than the fold, which inflates the RMSD dramatically. 4AKE against 1AKE gives 18.5 A as deposited dimers and 2.1 A chain-to-chain.

Input Schema

NameRequiredDescriptionDefault
methodNo"super" (default) is sequence-independent and handles low identity or different folds; "align" uses a sequence alignment first and is better for near-identical sequences.super
mobileYesObject to move and color (e.g. "1ake").
targetYesObject to superpose onto and leave in place (e.g. "4ake").
max_deviationNoAngstrom value mapped to full red. Defaults to the largest observed shift, which maximises contrast; set it explicitly to compare two different pairs on one scale.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations mark this as non-read-only but non-destructive, and the description discloses exactly what changes: the mobile object is moved and colored while the target stays as a grey reference. It adds important prerequisites and session-clearing behavior that annotations do not cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, followed by practical caveats in a logical order. Despite being moderately long, every sentence contributes functional guidance or a concrete pitfall.

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?

Given that an output schema exists and the input schema covers all parameters, the description is complete for correct invocation. It covers prerequisites, side effects, multimer caveats, and the chain-pairing behavior that an agent needs to use the tool correctly.

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?

Schema coverage is 100%, so method, mobile, target, and max_deviation are already documented in the input schema. The description still adds useful meaning by explaining how mobile and target residues are paired, including the chain/residue fallback when chain IDs differ.

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: superposes two structures and colors the mobile one by per-residue shift. It also explains the value relative to RMSD alone, letting an agent understand what this tool does beyond a plain alignment.

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 explicit when-to-use guidance for comparing two states of the same protein, including apo/holo and mutant/wild-type examples. It also warns about multimers and says to create one object per chain, and explains the fetch_structure replace=False prerequisite.

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