Skip to main content
Glama

orient

Idempotent

Aligns the PyMOL view with the principal axes of a selected structure or all objects, making orientations consistent for analysis and presentation.

Instructions

Orients the view to align with principal axes of the selection

Input Schema

NameRequiredDescriptionDefault
selectionNoWhat to orient on. PyMOL aligns the longest axis of this selection with the screen's x-axis.all

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / selection / description
      Added value: +"What to orient on. PyMOL aligns the longest axis of this selection with the screen's x-axis."
  2. First observedv1.2.1

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare it is non-destructive, idempotent, and a non-read operation, which correctly implies a camera/state change. The description adds no further behavioral context: it does not say that only the view changes (molecular coordinates are untouched), nor whether it depends on the current view or resets it. Nothing contradicts the annotations, but nothing is added either.

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?

A single front-loaded sentence with no filler. It is efficient, though its brevity is close to under-specification for a camera-manipulation tool.

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

Completeness3/5

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

The tool is simple (one optional parameter, output schema present, annotations covering safety), so the description is nearly sufficient. It could be stronger by clarifying that this reorients the camera rather than aligning structures, which matters given sibling tools align and super in the same namespace.

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% and the selection parameter already explains the longest-axis/x-axis behavior in detail. The description repeats that idea at a higher level without adding format, defaults, or edge cases, so baseline 3 applies.

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 description states a specific verb and object ('orients the view') plus the precise criterion ('principal axes of the selection'), which is far clearer than a bare name. It stops short of distinguishing itself from camera siblings like center, zoom, or turn, so an agent must infer the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance is given and no alternative is named. An agent gets no signal about when orientation beats zoom/center or when a freshly centered view already suffices.

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