pymol-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools are clearly distinct (camera, selection, representation, measurement, loading). A few pairs like load_trajectory/load_trajectory_mda and hbond_network/chill_plus show some overlap, but their descriptions provide enough clarification.
Naming Consistency4/5Tool names predominantly follow a verb_noun pattern (reset_session, render_image, measure_distance). Deviations exist among analysis tools (order_parameter, hbond_network, chill_plus) which use noun-style names, but the overall convention remains consistent and readable.
Tool Count2/5With 32 tools, the server is overstuffed. Several tools could be merged (e.g., measure_distance/angle/dihedral, load_trajectory variants, run_pml/run_python), and the specialized clathrate tools add bulk beyond a general-purpose PyMOL interface.
Completeness3/5Core workflows like loading, selecting, visualizing, measuring, and rendering are covered, but basic operations such as deleting objects, listing selections, or editing structures are missing. The specialized clathrate analysis is thorough, but general PyMOL coverage has notable gaps.
Average 3.7/5 across 32 of 32 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explain what 'hide' does (e.g., makes a representation invisible, whether it's reversible), nor does it mention default behavior (hiding everything for all), which is critical information not conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no superfluous words. It is front-loaded and efficient, earning high marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and two parameters, the description is too terse to fully inform an agent. It lacks explanation of defaults, representation semantics, and relation to sibling tools, making it incomplete for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described ('Selection to hide it for.' and 'Representation to hide (or everything)'). The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Hide') and resource ('a representation') with an implicit scope ('for a selection'). It is understandable, but it does not explicitly distinguish from sibling tools like 'show' or explain when to use it over other representation-modifying commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or exclusions, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It merely states that it colors a selection, without explaining side effects (e.g., modifying the visual state of the session), how the color is applied, or what the output represents. This is nearly tautological.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is front-loaded and every word earns its place, though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a well-documented schema and output schema present, the description is minimally adequate. However, it omits any behavioral context or usage note that would help an agent anticipate the tool's effect within the PyMOL session, leaving the description somewhat incomplete for a non-expert.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear definitions for 'color' and 'selection' already. The description adds no extra meaning beyond what the schema offers, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Color a selection' clearly states a specific verb (color) and resource (selection), but it does not distinguish from sibling tools like 'spectrum' which also modifies colors. It is clear but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool versus alternatives like 'spectrum' or 'set_background', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states the basic save operation and format-from-extension, but does not mention side effects like overwriting files, permissions, or any nuanced behavior related to the selection or state parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the core action. It omits unnecessary words and effectively conveys the essential purpose and format mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a minimal but adequate overview for a fairly simple tool. It leaves some ambiguity about what 'session' means and whether files overwrite, but given the output schema and comprehensive parameter descriptions, it offers enough context to understand the tool's basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds only a minor clarification that the extension determines format, which is also stated in the schema. Thus it meets the baseline but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (save) and the target (a selection/session to a file), and notes that the format is inferred from the extension. While it does not explicitly differentiate from siblings like render_image, the mention of selection/session makes its scope distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives, such as render_image for images or load_structure for reading files. There is no mention of exclusions or specific use cases, leaving the agent to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does reveal that the operation affects the camera rather than the model, which is useful behavioral context. However, it does not clarify whether the rotation is incremental, how it interacts with existing camera state, or if any side effects on the scene occur. The description is truthful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence that delivers the core purpose without clutter. It earns its place and is appropriately sized for a simple two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully documents parameters, but the description lacks contextual information such as when to use it relative to siblings, whether the rotation is relative or absolute, and what state changes occur. For a tool with no annotations, this sparse guidance leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'axis' and 'angle' having clear descriptions and the angle having a default. The tool description adds no new meaning beyond the schema—'about an axis' simply restates the axis parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rotates the camera about an axis, which is a specific verb, resource, and scope. It distinguishes from sibling tools like 'zoom' (scaling) and 'orient' (likely alignment), though it does not explicitly name any alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'orient' or 'zoom'. It does not mention common use cases, prerequisites, or exclusions, leaving the agent to infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('zoom the camera') without mentioning any side effects, whether the view is reset, if the operation is reversible, or any dependencies on previously loaded structures. This lack of detail leaves the agent unaware of potential impacts beyond the immediate camera change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with zero redundant words. It directly conveys the core purpose, making it efficient and well-structured. No fluff or unnecessary detail is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with full parameter documentation in the schema and an output schema provided, mitigating the need for return-value explanation. However, the description lacks context about when to use it among similar camera tools and gives no behavioral nuance. For a minimal tool this is acceptable but still leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'buffer' and 'selection' have descriptive text in the schema. The tool description itself does not mention parameters, so it adds no additional meaning beyond the schema. According to the rubric, the baseline of 3 applies when the schema fully documents parameters, and no extra description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Zoom the camera onto a selection' uses a specific verb ('Zoom') and clearly identifies the resource ('camera') and target ('selection'). This directly distinguishes it from sibling tools like 'orient' or 'turn', which adjust camera orientation rather than zoom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not state when to choose 'zoom' over 'orient', 'turn', or other camera-related tools, nor does it mention any exclusions or prerequisites. The usage is only implied by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It reveals the one-per-cage assignment rule but omits any side effects, requirements (e.g., prior cage detection), or constraints. It does not state whether the tool modifies state or what happens if cages are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the main action and includes the key behavioral detail. Every word contributes value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and well-documented parameters, the description does not place the tool within the broader workflow (e.g., dependence on identify_cages). It lacks edge-case behavior and preconditions, leaving the agent to guess how this tool integrates with siblings. For a specialized analysis tool, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all four parameters with descriptions, providing 100% coverage. The description adds minimal extra meaning about guest assignment but does not explain parameter roles or formats beyond what the schema already offers, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Compute' and resource 'clathrate cage occupancy', clearly distinguishing it from sibling tools like identify_cages (detection) and mark_cages (visualization). It also states the core assignment logic (one guest per cage), making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after cage detection (since it references 'detected cages') but provides no explicit when-to-use or alternatives. There is no mention of prerequisites or when not to use this tool, leaving the workflow integration to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must carry the behavioral disclosure burden. It states only the action without describing side effects, prerequisites, or how 'principal axes' are computed, leaving the agent to infer the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise but could arguably include more detail without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one well-documented parameter and an output schema, the description is adequate but minimal. It does not clarify what 'principal axes' means or what output the tool returns, though the output schema exists to cover the latter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'selection' parameter with full coverage (100%), so the description need not repeat it. However, the description adds no extra semantic context beyond the schema, such as allowed values or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Orient') and specifies the resource ('camera') and the basis of orientation ('principal axes of a selection'), clearly distinguishing it from camera-movement siblings like 'turn' or 'zoom'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'turn' or 'zoom' is provided. The purpose implies usage for aligning the camera to a selection's principal axes, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states that a colored CGO object is drawn, without disclosing side effects (e.g., whether existing objects are overwritten, whether prior CHILL+ analysis is required, or how coloring is determined). This is a significant gap for a visualization tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, target, and output without any wasted words. It is concise and structurally clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and an output schema, but the description is minimal. It does not explain the prerequisite that classification must have been performed, nor does it clarify what 'colored' means in terms of class colors. While the output schema may cover return values, contextual context for a domain-specific visualization tool is lacking, making it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters are already documented in the schema. The description adds no additional parameter context beyond the word 'colored' and the fixed object name, which does not enhance the agent's understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Draw' and clearly identifies the resource ('classified CHILL+ O-O network') and the output (a colored CGO object named 'chill_plus'). This distinguishes it from siblings like chill_plus (computation) or mark_cages (cage marking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (draw after classification), and the description indicates the tool produces a CGO object, but it does not explicitly state when to use it versus alternatives or mention any prerequisites or exclusions. No alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, whether it creates or modifies session objects, or what the exact output shape is. The word 'Build' is ambiguous—it could mean constructing a network object or merely computing statistics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence states the primary purpose, and the second provides an interpretative benchmark (~4 H-bonds per water), which is useful and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a fully detailed input schema and an output schema present, the description is mostly sufficient. It lacks explicit note about water-system requirements or side effects of 'build,' but the core functionality is captured. The clathrate reference adds domain context, making it adequate for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 5 parameters with detailed descriptions (100% coverage), so the baseline is 3. The description adds no parameter-specific information; it does not clarify relationships between parameters, typical ranges, or how they affect results beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Build') and resource ('water hydrogen-bond network'), and specifies that it 'report[s] coordination statistics.' This distinguishes it from siblings like measure_distance or identify_cages, which focus on different structural analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by 'water hydrogen-bond network' and the tetrahedral heuristic, but there is no explicit statement of when to use this tool vs. alternatives, nor any comparison with sibling tools. The description does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency responsibility. It discloses the algorithmic pipeline and includes validation examples (e.g., 'sII -> 128x 5^12 + 64x 5^12 6^4'), which adds useful behavioral context. However, it does not mention side effects, error handling, or what happens on empty selections, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a single paragraph that front-loads the purpose, describes the pipeline, and gives essential validation details. Every sentence earns its place and no unnecessary words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full workflow, output types, and validation results, making it fairly complete for a computational tool. Since an output schema exists, additional return formatting details are unnecessary, though usage guidance gaps slightly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all five parameters with descriptions and defaults (100% coverage), so the baseline is 3. The description does not add extra parameter-level details beyond what the schema already provides, so it neither raises nor lowers the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose with a specific verb and resource: 'Identify clathrate cages'. It also outlines the pipeline ('ring perception -> cage assembly -> face-count typing') and explicitly lists the return outputs (per-type cage counts and sI/sII/sH structure). This distinguishes it from related siblings like cage_occupancy or mark_cages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as cage_occupancy or mark_cages. It implies usage by the phrase 'Identify clathrate cages', but lacks exclusions, prerequisites, or comparative direction, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and does not reveal whether the operation is read-only, has prerequisites, or could modify the session. This lack of transparency is a gap for a tool that the agent must safely invoke.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no redundant words. Every element ('measure angle', 'degrees', 'three single-atom selections') delivers essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with full schema coverage, an output schema, and clear purpose, the description is largely complete. It lacks usage exclusions or prerequisite information, but given the simplicity and existing schema, it is sufficiently informative for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter described as a single-atom selection (atom2 specifically as 'Vertex'). The description adds no further semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Measure') and resource ('angle') with explicit scope ('defined by three single-atom selections'). It clearly distinguishes itself from sibling tools like measure_distance and measure_dihedral, which measure different geometric properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (measure angles when needed) but provides no explicit when/when-not guidance or alternatives. It does not differentiate from siblings beyond the inherent purpose, leaving the agent to infer context from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states 'Measure the dihedral (degrees)' without mentioning potential side effects (e.g., creating a measurement object in the session), ensuring valid selections, or read-only nature. This is insufficient for an AI agent to predict the tool's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear, front-loaded, and contains no extraneous information. Every word earns its place by specifying the action, unit, and selection requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects for a simple measurement tool: what is measured, in what unit, and the parameter requirements. The existence of an output schema presumably documents the return value. However, the lack of any side-effect disclosure or annotation guidance leaves a small gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter description already says 'Single-atom selection,' so the schema handles parameter meaning. The tool description adds minimal extra value by reinforcing that the four parameters define the dihedral, but it does not provide additional syntax or semantic context beyond what the schema already documents. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Measure' with the resource 'dihedral' and specifies 'degrees' and 'four single-atom selections,' clearly distinguishing it from sibling measurement tools like measure_distance and measure_angle. The purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for dihedral measurements via the phrase 'defined by four single-atom selections,' but it does not explicitly state when to use this tool versus alternatives like measure_distance or measure_angle. No exclusions or alternative references are provided, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the exclusive 'only=True' behavior, but this is already fully described in the schema parameter comment. It does not disclose other side effects such as whether existing representations are preserved or removed, session-state impact, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is front-loaded with the main action and includes a useful parenthetical about the only flag, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only 3 parameters, a fully documented schema, and an output schema present, the description plus schema are adequate. It could be more helpful with explicit usage directions or a note about interactions with other representation tools, but it is reasonably complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no extra parameter meaning beyond what the schema already documents; it only mentions 'selection' generically without elaborating on the representation enum or the selection syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Show') and the resource ('a molecular representation') plus the scope ('for a selection'). It distinguishes itself from sibling tools like hide by directly stating the opposite behavior, and the parenthetical about only=True adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for showing representations on selected atoms, but it does not explicitly state when to use this tool versus alternatives like hide or color. There are no explicit exclusions or alternative tool mentions beyond the inline only=True nuance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic action and gives an example expression; it does not mention what happens to existing colors, whether the operation is reversible, or what output is produced. This is a significant gap for a mutating visualization tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant wording. It is front-loaded with the action and includes a helpful example. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple coloring tool with a fully described schema and output schema, the description provides sufficient context. It clarifies the intended use through the per-atom expression example, and the sibling context shows where it fits. It only lacks explicit exclusion guidance, but the overall picture is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds an example expression ('B-factor') but does not elaborate on palette or selection semantics beyond what the schema already provides. It neither compensates nor detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Color') and clearly identifies the resource ('a selection') and the distinguishing mechanism ('along a spectrum of a per-atom expression'). The example 'B-factor' adds context and differentiates this from the sibling 'color' tool, which likely applies a solid color.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for coloring by a continuous property (e.g., B-factor) but provides no explicit when-to-use vs alternatives. It does not name the sibling 'color' tool or state when not to use spectrum, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It fails to mention that the default zoom parameter will modify the view (zoom/orient onto selection) before rendering, which contradicts the phrase 'current scene.' It also does not disclose whether the tool has side effects on the scene state or how rendering is performed (blocking vs async).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler words. Every word contributes directly to understanding the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a tool with five parameters and no annotations or output schema. It does not explain the return format beyond 'inline,' nor does it mention the zoom-orient side effect or when to use this tool relative to save_file for persistent images. It provides enough to get started, but leaves important context untold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed parameter descriptions, so baseline is 3. The tool description adds no additional parameter context; it does not explain the zoom behavior or how selection interacts with rendering beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Ray-trace') and resource ('the current scene to a PNG'), clearly distinguishing it from sibling tools like orient/zoom that manipulate the view without producing an image. It also states the output format and delivery mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need a rendered PNG of the current scene. It does not explicitly exclude alternatives, nor does it mention related tools like save_file for saving images, but the context is unambiguous enough for an agent to select it for rendering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal an important trait: the tool is opt-in and gated behind an environment variable. However, it doesn't warn about the broader implications of arbitrary Python execution—such as potential side effects on the PyMOL session or security risks—which would be valuable for a code-execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that are front-loaded with the opt-in marker and immediately state the action. Every word adds value: the opt-in tag, the execution purpose, the `cmd` scope, and the required environment variable. No wasted language or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is concise but sufficient for invocation: it says what the tool does, the required parameter, and the environment variable gate. It might benefit from a note about arbitrary code execution risks, but the presence of an output schema and detailed parameter description covers return values. Overall, it's reasonably complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the `code` parameter with 100% coverage, including the fact that PyMOL `cmd` is in scope and that setting a `result` variable returns a value. The description adds no extra parameter-specific meaning beyond reiterating 'with PyMOL `cmd` in scope', so it aligns with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute a Python snippet with PyMOL `cmd` in scope.' It uses a specific verb (execute), identifies the resource (PyMOL `cmd`), and distinguishes itself from sibling tools like run_pml (which likely runs PyMOL scripts, not arbitrary Python). The opt-in/requires note further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Requires PYMOL_MCP_ALLOW_CODE_EXEC=1' and marks the tool as '[opt-in]'. However, it doesn't explicitly state when to prefer this tool over alternatives like run_pml, nor does it provide exclusions or comparisons. Usage context is implied rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, but it only states the core action. It does not mention whether the setting persists, affects only future renders, or requires a loaded structure, though the operation is simple and benign.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, containing zero unnecessary words. It is concise and effectively structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with a clear schema, default value, and an output schema, the description is complete enough. It fully conveys the tool's purpose, and the schema handles parameter details without needing additional explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'color' with an example and default value. The tool description adds no additional parameter semantics beyond repeating 'background color', so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and a clear resource ('render background color'), making the tool's function immediately obvious. It also distinguishes itself from sibling tools like 'color' by specifying 'background' rather than general object coloring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to change the render background color) but provides no explicit guidance on when to use this tool versus alternatives. It does not mention sibling tools or give any exclusions, so context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states that the tool 'sequence-aligns and superposes', implying the mobile structure is moved, but it does not disclose side effects, whether the change is permanent, or what the output contains. The presence of an output schema reduces the need to describe return values, but mutation traits are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, extremely concise, and front-loaded with the core action. Every word adds value—the verb, the objects, and the usage hint. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description is largely complete: it tells what it does and the intended use case. It omits any mention of prerequisites (e.g., both structures must be loaded) but these are implicit and low-risk. The output schema covers return value details, so no additional explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents both parameters with clear descriptions ('Object/selection to move' and 'Reference object/selection'), giving 100% coverage. The description merely echoes the parameter names ('mobile onto target') without adding extra semantic detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs sequence alignment and superposition of 'mobile' onto 'target'. The verb+resource structure is specific and distinguishable from sibling tools like 'orient' or 'zoom'. The parenthetical '(use for different structures)' adds valuable context about the intended use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'use for different structures' provides explicit guidance on when to use this tool, setting a clear context. It does not mention when not to use it or name alternatives, but the instruction narrows the scope sufficiently for an agent to make a correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It details the output components (six class counts, per-water classes, fractions, and O-O cutoff network) and specifies ordering ('in water input order'). This gives a clear picture of what the tool returns, though it does not explicitly state whether it mutates state or requires specific session conditions. The output description is strong enough to earn a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the primary action. The second sentence lists result components without fluff. Every word contributes to understanding, and there is no redundant or verbose phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are already documented there. The description provides the higher-level context: it classifies water phases and highlights the unique O-O network. It does not explain prerequisites like needing a water-only selection or a valid box, but those are covered by parameter defaults and the schema. For a scientific tool of this complexity, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters already have descriptions. The tool description adds no parameter-level guidance beyond the schema. Per the baseline rule, when schema coverage exceeds 80% and the description adds little, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Classify water molecules as liquid, ice, or hydrate with CHILL+.' This clearly distinguishes it from sibling analysis tools like order_parameter or hbond_network, which target different properties. It also names the CHILL+ method, giving precise scientific context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for water phase classification but does not explicitly state when to prefer this over alternatives like identify_cages or hbond_network. No exclusions or comparative guidance are provided, leaving the agent to infer from context. Some guidance on when CHILL+ is appropriate would improve this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds the behavioral constraint of requiring network and indicates the loading action, but does not mention error handling, session impacts, or failure modes. Some useful context but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and resource. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, an output schema exists, and the schema covers parameters, the description is complete enough. It mentions the key constraint (network) and the action (fetch and load), which suffices for a basic fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional parameter-level meaning beyond what the schema provides, meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a structure from the RCSB PDB and loads it, using a specific verb and resource. It differentiates from siblings like load_structure by naming the remote source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting that network access is required, which implies when the tool can be used. It does not explicitly exclude alternatives, but the context is sufficient for a straightforward fetch operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the precondition (object must be loaded) and the specific return fields, but it does not explicitly state that the operation is read-only or describe any side effects. The verb 'Return' implies read-only, but this is not stated explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 11 words, front-loaded with the purpose. It contains no filler and communicates the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and a likely straightforward output schema. The description covers the main output content and the precondition for use. It omits potential error behavior (e.g., object not found), but given the existence of an output schema, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'name' with 'Object name to inspect.' The description adds context by specifying 'loaded object,' indicating that the object must already exist and be loaded rather than being fetched on demand. This goes beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and clearly identifies the resource (atom count, state count, and chains for a loaded object). It is distinct from sibling tools like get_selection_info and list_objects, which focus on selections or object listings respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a loaded object' implies the tool is used when inspecting an already-loaded object, but it does not explicitly state when not to use it or mention alternatives like get_selection_info. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output content but does not mention read-only behavior, error cases for invalid selections, or any side effects. The name suggests non-destructive, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with the verb front-loaded. It contains no redundant words and directly states the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers the main purpose and result adequately. It could mention read-only nature or default selection behavior, but these are either implied or in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter. The description adds no extra meaning beyond the schema; it simply restates that the selection is summarized. This meets the baseline for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Summarize' plus the resource 'selection' and details the output (atom count, chains, residue names). This clearly distinguishes it from sibling tools like 'select' or 'get_object_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool to summarize a selection. It does not explicitly list alternatives or when-not-to-use, but the purpose is specific enough that an agent can infer its appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool loads a structure and returns object name/counts, but does not address session side effects, overwrite behavior, or error conditions. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple load operation, the description is complete due to the output schema and full parameter descriptions, but the lack of annotations means it could mention session integration or error handling. Still, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing full parameter descriptions. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Load' and resource 'molecular structure or single-frame coordinate file into PyMOL', clearly distinguishing it from trajectory-loading siblings. It also mentions the return value, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'single-frame' implies this tool is for static structures, distinguishing it from load_trajectory alternatives, but it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses that loading appends frames as states (a session mutation) and warns about the common trjconv pitfall. However, it does not address overwrite behavior or potential side effects on existing objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant filler, main purpose front-loaded. The warning is valuable and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core workflow and a key pitfall, but omits usage guidance relative to load_trajectory_mda and gives no information about object overwrite semantics. Output schema covers returns, so that is not an issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context about atom matching relevant to structure_path and trajectory_path, but does not elaborate on start/stop/interval beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Load a GROMACS/DCD trajectory'), specifies the resource type, and outlines the process ('load the structure, then append frames as states'). It differentiates from the sibling load_trajectory_mda by explicitly naming GROMACS/DCD formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for GROMACS/DCD trajectory files but does not explicitly contrast with load_trajectory_mda or provide when-not guidance. The atom-count warning is a prerequisite, not a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the mechanism (injecting coordinates into states) and the dependency (optional `md` extra), but does not mention side effects such as overwriting existing objects, state count, or performance implications. This is a partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and free of redundant information. Every phrase contributes to understanding the tool's purpose and prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no annotations, the description covers the essential high-level behavior and a critical dependency. The rich schema fills in parameter details, making the overall package sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds general context about trajectory formats but does not describe individual parameters; the schema already handles that. It neither enhances nor detracts from parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads MDAnalysis-readable trajectories (e.g., LAMMPS dump, AMBER NetCDF) and explains the mechanism (injecting coordinates into PyMOL states). This distinguishes it from siblings like load_trajectory, which likely handles native formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by naming non-native trajectory formats and mentioning the required `md` extra. It implies use for formats PyMOL cannot natively read, but does not explicitly name alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It specifies the unit and the single-atom requirement, which are useful constraints, but it does not mention potential side effects (likely none), prerequisites (e.g., loaded structure), or error conditions if selections are invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action, object, unit, and required inputs. It contains no redundant information and is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple measurement tool with a fully described input schema and an output schema, the description provides the core semantics: what is measured, the unit, and the single-atom selection requirement. It is sufficiently complete, though it could benefit from explicit usage boundaries or prerequisities, which are minor for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter described as 'Single-atom selection.' The overall description adds the unit and that the two selections together define the distance, but it does not elaborate on selection syntax or format beyond what the schema already provides. This meets the baseline for schema-heavy parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Measure' with resource 'distance' and includes unit 'Angstroms' and the constraint 'between two single-atom selections'. This clearly distinguishes it from sibling tools like measure_angle and measure_dihedral, which measure different geometric quantities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for distance measurement between two atom selections, providing sufficient context for when to use it. However, it does not explicitly mention alternatives or exclusions, though the name and sibling context make the distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds valuable output interpretation data (thresholds for hydrate, liquid, ice), but it does not mention prerequisites like 'requires a selected water system' or how the box parameter is used beyond schema details. This leaves some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the tool's primary action, the second gives interpretative thresholds. Every word is purposeful, with no repetition or fluff. Structure is front-loaded and immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with several parameters, but the schema is rich and an output schema exists, so the description need not explain return values. The thresholds provide essential context for interpreting results. Slight gap is lack of explicit guidance on when to choose F3 vs F4, but the interpretation values imply this, making the description fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all four parameters, so the schema already explains them. The description does not add further parameter-level meaning; it focuses on output interpretation instead. This matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes 'F3 or F4 water order parameter for a clathrate-hydrate system', specifying the exact operation and object. This distinguishes it from sibling tools that focus on other measurements, as no other tool calculates order parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying the target system (clathrate hydrate) and the meaning of F3/F4 thresholds, which implies when it should be used. However, it does not explicitly state alternative tools or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the critical requirement (env var) and hints at 'raw' execution, but it does not explicitly warn about potential side effects, lack of safety checks, or that commands may modify the session state irreversibly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence plus a requirement note. It front-loads the core purpose and avoids redundancy, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one string parameter) and the presence of an output schema, the description adequately covers the essential opt-in requirement. However, for a raw code-execution tool, it could be more complete by mentioning side effects or typical error behavior, but this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single `command` parameter with a clear description. The tool description adds no additional parameter-level guidance, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute') and the resource ('raw PyMOL command-language statements'). The term 'raw' helps distinguish it from more specific tools like run_python or render_image, and it identifies the input language precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The '[opt-in]' prefix and 'Requires PYMOL_MCP_ALLOW_CODE_EXEC=1' provide clear context on when the tool is available and what prerequisite must be met. However, it does not explicitly mention alternatives or scenarios where this tool should be avoided in favor of higher-level tool-specific commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the primary behavior (creating a selection) and the return value (atom count), but does not mention edge cases such as overwriting an existing selection, behavior on invalid selection expressions, or prerequisite loaded structures. This leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no filler. Every word contributes to understanding the tool's purpose and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, and an output schema exists (though not shown). The description states the return value (atom count), so it does not need to elaborate on return format. It could mention side effects like overwriting, but overall it is reasonably complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are well described in the schema. The description adds no extra parameter semantics beyond restating the purpose, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create'), identifies the resource (named selection), and states the return result (how many atoms matched). This clearly distinguishes it from sibling tools like get_selection_info, which likely reads existing selections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you want to create a named selection and get its atom count. It doesn't explicitly name alternatives or exclusions, but the context is clear enough that an AI agent can infer when to invoke it versus querying selection info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It clearly states the destructive effects by enumerating what is cleared (objects, selections, settings) and uses 'Reinitialize' to indicate a reset to a default state. However, it does not explicitly mention irreversibility or lack of confirmation prompts, which could be valuable for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action and its effects, with no unnecessary words. It is front-loaded and immediately communicates the tool's core function, which is ideal for an agent that needs to quickly parse and understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with a clear destructive action, the description provides all necessary information needed for invocation. The presence of an output schema covers return values, so the description adequately captures the tool's behavior without missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description is not required to explain parameter meanings. The baseline of 4 applies since the tool takes no arguments, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Reinitialize' and identifies the resource (PyMOL) along with the exact scope of its effect (clearing all objects, selections, and settings). This clearly distinguishes it from sibling tools that operate on specific items, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, such as selectively deleting objects or starting fresh in another way. While the purpose implies usage, there is no explicit 'use when' statement or pointer to other tools, leaving the agent without clear decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behaviors: it builds a single CGO object named 'cages', the geometry (cylinders along edges, spheres at vertices), and the coloring by cage type. It does not mention whether the object overwrites an existing one, but the main side effect is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense, front-loaded sentences cover purpose, geometry, coloring, and the output object. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a visualization tool with complete parameter schemas and an output schema, the description is nearly sufficient. It explains the output artifact and how it will be used, but could explicitly state the prerequisite of prior cage detection (identify_cages). The gap is minor and mostly implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the schema. The description adds value by mapping cage types to colors, enriching the cage_types parameter, but does not elaborate on other parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Draw') and resource ('each detected cage as a wireframe polyhedron'), clearly distinguishing it from sibling tools like identify_cages (detection) and cage_occupancy (analysis). It also specifies the visual elements and coloring scheme.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'detected cage' implies a prerequisite of prior cage detection (likely via identify_cages), and 'for render_image' indicates it is a preparation step for rendering. While it does not explicitly name alternatives or exclusions, the context makes the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately conveys that this is a read-only listing operation with no side effects. It does not explicitly state the return format or ordering, but the output schema likely covers that. The description is honest and matches expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is fully front-loaded and does not waste tokens.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, zero parameters, and presence of an output schema, the description is complete enough. It tells the user exactly what to expect without needing to explain return values, which the schema covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The high schema coverage is irrelevant since no params exist. A baseline of 4 is appropriate because no additional meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all loaded object names in the current PyMOL session. The verb 'list' and resource 'loaded object names' make the purpose specific and distinct from sibling tools that operate on individual objects or selections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you need an overview of all loaded objects, but it does not explicitly mention alternatives or when not to use it. For a simple listing tool this is acceptable but could be improved by noting it complements tools like get_object_info for individual objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wjgoarxiv/pymol-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server