MCPymol

by chemrich

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.5.1
Disambiguation3/5
The tool set is large but mostly distinct; however, pairs like align/super, bfactor_view/putty_view, and delete/remove have overlapping purposes that could confuse an agent. The detailed descriptions help differentiate them, but the sheer number of view presets and command wrappers creates potential misselection.
Naming Consistency3/5
Tool names predominantly use lowercase with underscores, and there are consistent families like *_view and util_cb*. However, the set mixes short PyMOL command names (as, cd, pwd, ls), abbreviated utilities (util_cbc, util_cbaw), and longer descriptive names, making the naming pattern less uniform and predictable.
Tool Count1/5
With 131 tools, the server exposes far more than an agent can easily navigate; this surpasses the 50+ threshold defined as an extreme mismatch. Many tools are trivial wrappers (cd, pwd, ls, forward, backward) that add clutter without meaningful capability. The set would benefit from consolidation or a curated subset.
Completeness4/5
The tool set covers an impressively wide range of molecular visualization operations, including loading, fetching, editing, measuring, alignment, diverse view presets, session management, and map handling. Minor gaps exist, such as limited object-level manipulation and reliance on execute_pymol_command for some tasks, but the overall domain is well covered.
Average 3.6/5 across 131 of 131 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 43 commits in the last 12 weeks
- Last stable release on August 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no additional description, the tool's behavior is completely opaque. The description fails to disclose whether this is a read-only operation, whether it modifies state, what output it produces, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than concise clarity. It provides a single vague phrase with no useful structure, front-loading, or elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is far too minimal to be useful. It does not explain the context, expected results, relationship to rendering pipelines, or when ray tracing should be invoked instead of other image-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the two optional parameters (width and height) with 100% coverage, so the schema carries the semantic weight. The description itself adds no parameter information, but the baseline of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Performs ray-tracing' essentially restates the tool name and provides no concrete detail about what the tool actually does or produces. It does not distinguish this tool from siblings like render, png, or mpng, which also relate to image generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as render or png. The description is entirely silent on context, prerequisites, or preferred scenarios, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 merely says 'performs' without revealing that the tool relaxes the object, modifies state, or what side effects (e.g., irreversible changes) may occur. This is a serious gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-word sentence is under-specified rather than efficiently concise. It does not provide enough information to be useful, and the brevity undermines its value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, an output schema, and related siblings, this description is severely insufficient. It omits the operation's purpose beyond the name, how iterations are counted, what the state parameter affects, and how it fits into sculpting workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter (obj, state, iterations) having a description, so the baseline is 3. The tool description adds no additional parameter meaning, but the schema adequately explains the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Performs sculpting iterations' essentially restates the tool name without specifying what sculpting iterations actually accomplish. It does not describe the effect on the object or distinguish it from sibling tools like sculpt_activate or sculpt_deactivate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., whether sculpting must be active), and no indication of the intended workflow. The description provides no contextual usage information.
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 disclosure. It reveals that the tool uses OpenGL and is faster but lower quality, but it does not disclose what the tool does, what side effects it has, or what output to expect. This is minimal insight into the actual 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single short sentence with no filler words. It is front-loaded with the key technical detail about the OpenGL renderer and the speed/quality tradeoff. While it is under-specified, that is a completeness issue, not a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is very incomplete for a rendering operation. It does not explain what the tool renders, when to use it, or what the result is. Given the complexity of the domain (molecular visualization) and the need to choose between rendering tools, this description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters ('width' and 'height') with 100% coverage, so the schema already documents their meaning. The description adds nothing about the parameters, and per the baseline for high schema coverage a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Uses OpenGL renderer (faster but lower quality)' without stating what the tool actually does. It does not explicitly say 'draw an image' or 'render the current scene', leaving the purpose vague. The technical detail about OpenGL hints at rendering but does not define the action or output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The phrase 'faster but lower quality' implies a tradeoff with other rendering methods, but no alternative tools are named and no clear usage scenario is stated. This leaves the decision of when to use 'draw' entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral disclosure beyond the bare statement 'Fits all states within an object'. It does not mention that fitting modifies coordinates, whether the operation is reversible, or what side effects occur. Since no annotations are provided, the description carries the full burden and fails to disclose these traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence, which is efficient, but it under-specifies the tool's behavior. It avoids verbosity but lacks crucial details, making it only minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema with one well-described parameter and an output schema, but the description does not explain what the output is, what the tool does to the states, or any side effects. For a fitting operation that modifies state coordinates, this is incomplete without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description contains no parameter information, but the input schema has 100% coverage with a clear description for 'selection' ('Object whose states to fit onto its first state.'). The baseline of 3 applies because the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('fits') and specifies the resource ('all states within an object'). The schema parameter description clarifies that states are fit onto the first state, which distinguishes it from sibling tools like 'intra_rms' (measurement) and 'morph_states' (interpolation). However, it could explicitly mention superposition or alignment for even greater clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as 'align', 'super', or 'intra_rms'. There are no prerequisites (e.g., the object must have multiple states) or exclusions 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic write operation but does not mention overwriting behavior, file format implications, state handling, or whether any side effects occur. This is a significant gap for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified rather than concise. The single sentence omits essential context (formats, usage, differences from siblings), so it fails to earn its place as a helpful guide. This is closer to under-specification than effective brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and many sibling output tools, the description is too thin. Even with an output schema present, it does not explain supported file formats, when to use this tool over save_session or png, or what happens to existing files. The description is inadequate for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have detailed descriptions), so the baseline is 3. The description itself adds no parameter meaning beyond what the schema already provides, which is acceptable since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Saves') and a resource ('a file'), but 'data' is vague and does not identify what kind of data (structure, session, image) is saved. It does not differentiate the tool from siblings like save_session, png, or render, leaving the agent uncertain about the tool's specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description lacks any mention of exclusions, prerequisites, or typical scenarios, making it difficult to choose among the many output-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only says 'manages scenes for later recall'. It does not mention side effects like changing the current view when recalling, deleting scenes irreversibly, or storing state. This is a significant gap for a mutation-capable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff or redundant information. It is front-loaded with the core purpose, though it could be slightly more informative without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has multiple actions (store, recall, clear, etc.) and no annotations, the description is too sparse. It does not cover when to use each action, potential side effects, or how scenes interact with the view, leaving the agent with an incomplete picture. The output schema exists but does not compensate for the lack of behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema provides meaningful descriptions for both 'key' and 'action', including examples and allowed values. The tool description adds no additional parameter semantics, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it manages scenes for later recall, identifying the resource (scenes) and a general purpose, but 'manages' is vague and doesn't specify the range of actions (store, recall, clear, etc.) that the schema reveals. It also doesn't differentiate this tool from the sibling 'scene_order', which also relates to scenes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'scene_order', 'create', or 'delete'. The description only gives a general purpose without any context on conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action without noting that it creates new objects with a prefix, requires a symmetry object, or that it is non-destructive. The lack of side-effect information is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient but under-specified for a tool with 5 parameters. It omits critical behavioral and usage context, so it is not appropriately sized; it is too sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and a dependency on crystal symmetry context, the one-sentence description is inadequate. It fails to explain the interaction between obj_name and selection, the effect of cutoff, or the prefix naming convention.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description (e.g., 'Distance in Angstrom out to which to generate mates'). The description adds no additional parameter semantics, but the schema is sufficient, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'generates' with the resource 'symmetry-related copies', which conveys the core action. It is distinguishable from generic copy tools by the 'symmetry-related' qualifier, though it lacks explicit mention of crystallographic context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use symexp versus alternative tools. There is no mention of prerequisites or contextual instructions, such as needing an existing symmetry object or the relationship between obj_name and selection.
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?
The description does not disclose any behavioral traits beyond the verb 'refreshes'. There are no annotations to rely on, and the description fails to explain side effects, permissions, or what exactly gets refreshed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one sentence, but it could include more meaningful context without losing brevity. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is barely adequate. It lacks enough context for an AI agent to understand the exact effect of 'refresh' compared to similar operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because there are zero parameters, so the baseline score of 3 applies. The description adds no parameter information since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool refreshes the display, which is clear but does not differentiate it from similar sibling tools like 'rebuild' or 'update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'rebuild' or 'reset'. The description lacks usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic effect (pink carbons) but does not mention scope (selection), reversibility, or what happens to existing colors, which is insufficient for a mutation-like visual operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but the parenthetical '(Color By Atom, pinK)' is redundant with the first phrase and adds no value. The structure is not well-organized; it reads more like a fragment than a clear tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with many similar siblings, this description is too minimal. It doesn't explain the color scheme, what 'by atom' means, or how it relates to other utilities like util_cbac or util_chainbow. Even with an output schema, the description lacks essential context for an AI 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'selection' parameter, so the baseline is 3. The description adds no additional meaning about the parameter or its behavior, but it also doesn't need to since the schema already documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Colors by atom, pink carbons' indicates a coloring operation but does not clearly define what 'by atom' means or how it differs from sibling tools like util_color_by_element. The parenthetical '(Color By Atom, pinK)' is cryptic and adds little clarity, making the purpose only partially clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling coloring utilities. The description offers no context, prerequisites, or exclusions, leaving the agent without decision support.
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 must disclose behavioral details, but it only states the basic coloring action. It does not mention that colors are assigned to atoms based on a property, that prior color assignments may be overwritten, or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundant information. It front-loads the core action, though it is grammatically awkward 'in a spectrum' and could be phrased more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the fully documented parameters and existence of an output schema, gives the agent a minimal but usable picture of a spectrum-coloring command. Missing details are the absence of usage context and side-effect disclosure, but the schema covers the parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptive schema text (palette, selection, expression), so the description adds no additional parameter meaning. The schema already explains the palette options, selection syntax, and property to color by, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Colors selection in a spectrum' names a verb and object, indicating the tool colors a selection using a spectrum. However, it does not specify that coloring is driven by an atom property (e.g., B-factor, occupancy) or explain how it differs from sibling commands like 'color' or 'util_rainbow'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternative coloring/spectrum tools. It does not mention prerequisites, exclusions, or fallback tools, leaving the agent to infer appropriate usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears the full burden of behavioral disclosure. It merely says 'Executes a system command' without mentioning potential side effects, security risks, lack of sandboxing, working directory behavior, or error handling. For a tool that can run arbitrary shell commands, this is a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence, front-loaded, with no wasted words. It is appropriately sized for a simple tool with only one parameter, though the lack of crucial safety details reduces the value of its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and no nested objects, the tool's nature as a system command executor makes context critical. The description fails to explain what the command output looks like (stdout/stderr/exit code), whether there are any restrictions, or how errors are handled. Even with a simple schema, this is incomplete for a high-risk operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter 'command' with a description ('Shell command to run on the machine PyMOL is running on.'). The tool description adds no extra meaning beyond this. The baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Executes' and the resource 'a system command', making the tool's basic function obvious. However, it does not differentiate this from the sibling tool 'execute_pymol_command', which may overlap in function. This is a clear purpose but with no sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives. The sibling 'execute_pymol_command' could be confused with this one, but the description gives no criteria for choosing between them. Usage context is completely absent.
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 without revealing side effects, dependencies (e.g., a loaded map object), or the meaning of the 'level' parameter in sigma. This leaves significant gaps for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. However, it is under-specified for a tool with four parameters and a sibling that could be confused with it, resulting in a balance between brevity and adequacy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of a closely related sibling 'isosurface', the description is incomplete. It does not explain what a mesh isosurface is, when to use it over 'isosurface', or any workflow context such as requiring a prior loaded map. The output schema exists but the description fails to provide sufficient context for a new agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description adds no additional meaning beyond the schema, keeping it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Creates' and names the resource 'mesh isosurface', which clarifies the basic purpose. However, it does not differentiate this tool from the sibling 'isosurface' tool, which could be a similar operation, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, such as requiring a loaded map, or when a mesh isosurface is preferable to a regular isosurface. The description provides no context for selection.
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 but only says 'Sets the order of scenes.' It does not disclose whether scene names must already exist, whether the order replaces the current one, or what happens on invalid input. This is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly conveys the purpose. It avoids fluff and is front-loaded. While it is sparse, it is not under-specified to the point of causing confusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and an output schema present, the description is adequately sized. However, it lacks any explanation of behavioral effects or prerequisites, which would improve completeness. The schema and output schema fill some gaps, but the description leaves room for interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the single parameter 'scene_list' is fully covered (100%) and includes an example: 'Space-separated scene names in the order wanted, e.g. "F2 F1 F3".' The tool description itself adds nothing beyond the schema, but since coverage is high, the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Sets the order of scenes.' This is a specific verb and resource, and it distinguishes from sibling tools like 'scene' by focusing on ordering. However, it does not elaborate on how the order is applied, but the parameter schema partially covers that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. There is no mention of prerequisites, exclusions, or alternative tools. It only states what the tool does, leaving the agent without context for selecting it.
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 color scheme (green carbons) but does not reveal whether existing colors are overwritten, how selection affects the outcome, or what happens to other atom types. This is especially problematic for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but the parenthetical '(Color By Atom, Green)' redundantly repeats the meaning of 'Colors by atom, green carbons'. This redundancy is unnecessary, though the overall length is appropriate for a simple utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and the presence of an output schema and 100% schema description coverage, the description could be sufficient, but it omits critical usage context and behavioral details. The agent cannot confidently decide when to call this tool over its many siblings, and the lack of annotation makes the side effects unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the 'selection' parameter described as 'What to recolour. Defaults to everything.' The tool description adds no additional parameter semantics, so the baseline score of 3 applies because the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Colors by atom') and a distinguishing detail ('green carbons'), which separates it from sibling color utilities like util_cbc or util_chainbow. The parenthetical '(Color By Atom, Green)' reinforces the intent, though it doesn't explicitly mention how non-carbon atoms are colored.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling color/utility tools, nor any exclusions or alternatives. The description reads as a label rather than usage instructions, leaving the agent to infer applicability from the tool name.
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 bears full responsibility for disclosing behavior. It states the core recoloring action but does not mention whether existing colors are overridden, how the 'selection' parameter affects scope, or any side effects. The phrase 'Colors by atom' is too vague to convey full behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but the parenthetical '(Color By Atom, Salmon)' is redundant and adds no value. It is not structured to front-load key information effectively, and the brevity borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description is minimally sufficient, but it lacks usage context and behavioral disclaimers. It does not explain the full coloring scheme or how it interacts with selections, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'selection' parameter, including its default and purpose. The description adds no additional parameter semantics, but the baseline of 3 is appropriate when schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Colors by atom, salmon carbons' clearly identifies a coloring operation with a specific resource (atoms) and a specific effect (carbons colored salmon). This distinguishes it from sibling tools that color by chain or residue, though it does not explicitly name 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many other coloring utilities (e.g., util_cbc, util_chainbow, util_color_by_element). The description lacks any context about appropriate scenarios or prerequisites.
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 should disclose behavioral traits like whether existing colors are replaced, how the selection parameter affects coloring, or what state changes occur. It only states the action ('Colors by atom, yellow carbons') without such detail, though it does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but the parenthetical '(Color By Atom, Yellow)' is redundant with the main phrase and wastes words. It is concise but under-specified, balancing brevity with a lack of useful elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with full schema coverage and an output schema, the description is minimally functional but leaves key context unanswered: how selection interacts with coloring, what 'by atom' means in practice, and when to use this variant over siblings. The agent would need to infer or guess to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single 'selection' parameter, including a default and description ('What to recolour. Defaults to everything.'). The tool description adds no further parameter semantics, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific coloring operation ('Colors by atom') with a specific target ('yellow carbons'), which distinguishes it from sibling color utilities like util_cbc. However, it is terse and does not elaborate on the 'by atom' convention beyond the short phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as util_cbc, util_cbag, or other color utilities. No exclusions, prerequisites, or typical use cases are mentioned, making it hard for an agent to choose it confidently.
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 (colors by chain) without explaining the color scheme, reversibility, whether it affects all objects or only the selection, or any side effects. This is minimal and insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but contains redundancy: 'Colors by chain (Color By Chain)' repeats the same information in parentheses. It could be more concise, but it is not overly verbose. A cleaner structure would state the function once without the parenthetical restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for a tool that modifies visual state. It does not explain the color mapping, whether existing colors are overwritten, or how the selection parameter interacts with the coloring. Despite an output schema being present, the description fails to provide enough context for an agent to know the tool's full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for the only parameter 'selection' ('What to recolour. Defaults to everything.'), achieving 100% schema coverage. The tool description adds no parameter information, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Colors by chain' clearly indicates the tool's function: recoloring structures by chain. It uses a specific verb (Colors) and resource (chain), but it does not distinguish itself from sibling color-related tools such as 'util_chainbow' or 'spectrum'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or scenarios where other coloring tools would be more appropriate. This is a clear gap for a tool with many siblings.
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 disclosure. It does not explain what 'recolour' entails, whether existing colors are overwritten, or if the operation is reversible. The parameter description clarifies the selection scope but not the visual or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with no wasted words. It efficiently states the core action, though it could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations), the description is minimally sufficient for understanding the basic function. However, it omits contextual details like whether a structure must be loaded or what color scheme is used, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the only parameter 'selection' has a description: 'What to recolour. Defaults to everything.' The tool description adds no further parameter context, so it relies on the schema. This meets the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Colors by secondary structure' specifies a clear action (colors) and resource (secondary structure), making it easy to infer the tool's purpose. It is terse but sufficient, though it does not explicitly distinguish itself from the similarly named sibling 'util_color_secondary'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 instead of alternatives like 'color', 'spectrum', or 'util_color_secondary'. It lacks any context about typical use cases, requirements, 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 must disclose behavioral details. It only states the core action and does not mention side effects, requirements, or what 'align' does in terms of output or state changes. The description is too terse to provide adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is direct and free of fluff. It is concise but not overly terse to the point of being a tautology. However, it could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and full schema coverage, the description is minimally adequate. An output schema exists, so return values are not required. However, the description does not fully convey the alignment behavior or context, making it average in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are already documented. The description adds no new meaning beyond the schema's own property descriptions. It meets the baseline but does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Aligns one selection to another' – a specific verb and resource. It distinguishes alignment from similar operations like superposition or fitting, though it does not explicitly name alternatives. It is a clear, plain-language statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'super' or 'intra_fit'. The schema hints at usage (e.g., target stays put), but the description itself offers no explicit adoption criteria 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 behavioral disclosure. It merely states that atomic properties are altered but does not explain how the assignment expression is evaluated, whether the operation is reversible, or any side effects on the selection or molecular state. This is insufficient for a mutating 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundancy. It is appropriately sized for the tool's simplicity, conveying the essence without unnecessary words, which earns a high score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema documents both parameters, the description lacks essential context about the expression language, selection behavior, and relationship to sibling tools. An agent would not know when to choose 'alter' over 'alter_state' or 'set', nor understand the impact of the assignment, leaving the description incomplete for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters with clear titles and examples (e.g., ``b=0``, ``chain='B'``), achieving 100% coverage. The description adds no param-specific meaning beyond what the schema provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Alters' and identifies the resource as 'atomic properties in a selection,' clearly conveying the tool's core function. It distinguishes from siblings like 'alter_state' (which likely modifies state-level properties) by indicating the target scope, though it does not explicitly name 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as 'set' or 'alter_state'. The description only states what the tool does without offering context, exclusions, or preferred scenarios, leaving the agent to infer usage.
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 that coordinates are altered, which is the core behavior, but doesn't disclose side effects, reversibility, or any caveats. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy and is appropriately concise. However, it's a bit too sparse to fully explain the tool's capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with three required parameters and no annotations, the description is insufficiently complete. It doesn't explain the expression syntax, effect on the state, or any prerequisites. The minimal text leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with descriptions, so the baseline is 3. The tool description adds no additional parameter information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies atomic coordinates in a state, which is a specific verb+resource. However, it doesn't distinguish it from sibling tools like 'alter' or other modification commands, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states the action with no mention of context, 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, the description carries full responsibility for behavioral disclosure. It only says 'creates a bond' and does not mention atomicity, whether existing bonds are replaced, required atom selection behavior (exactly one atom each), or any side effects on the molecular structure. The schema describes selections, but the description does not state these are required or how they are validated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, extremely concise and front-loaded with the key information. However, it is so brief that it under-delivers on context, but for pure conciseness it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a structural mutation operation with no annotations and only a one-line description. While an output schema exists and parameters are documented, the description fails to provide essential behavioral context such as how the bond creation affects the structure, prerequisites, or relationship to sibling tools. For a simple tool, this is a minimal but incomplete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter (atom1, atom2, order) having its own description in the input schema. The tool description itself adds no additional meaning, so it does not go above the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Creates a bond between two atoms' clearly states the action (creates) and the resource (a bond), and the two-atom target is explicit. While it doesn't explicitly differentiate from siblings such as 'unbond' or 'distance', the primary purpose is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives. For example, there is no mention that 'unbond' is the inverse operation, or that bonds should be created before using distance or angle tools. The description simply states what it does with no contextual usage advice.
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 without mentioning side effects, session-scoped state changes, or error conditions, which is a significant gap for a state-mutating command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is as concise as possible, though it sacrifices useful context, which is acceptable given the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a very simple tool, the description covers the core purpose, and the parameter schema adds necessary detail. However, it lacks usage context and behavioral caveats (e.g., that this changes the working directory for the PyMOL session), making it merely adequate rather than complete. The presence of an output schema reduces the need to explain return values, but the overall context is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single 'path' parameter, which includes a clear description of how PyMOL resolves relative paths from the new directory. The tool description adds no parameter-specific information, but the schema already does the heavy lifting, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes the current directory, which is a specific verb+resource operation. It does not explicitly distinguish from sibling tools like 'pwd', but the purpose is unambiguous and goes beyond a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, prerequisites, or alternatives. The description does not mention that this affects relative path resolution for subsequent PyMOL commands or any exclusions, leaving the agent to infer usage.
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 disclosure. It merely says 'Sets the color' which restates the purpose. It does not disclose whether existing colors are overridden, how it interacts with representations, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no wasted words. It is concise and front-loaded. However, it is extremely terse and lacks any additional context, which slightly reduces effectiveness despite being well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and rich schema, the description is still incomplete. It lacks usage guidance, differentiation from siblings, and any behavioral context. The presence of an output schema does not compensate for the missing information about when and how to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both 'selection' and 'color_name' have descriptions). The tool description adds no parameter information 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Sets the color for a selection.' This is clear and unambiguous. However, it does not differentiate from sibling tools like 'spectrum' or 'util_color_by_element' that also deal with coloring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions. For example, it does not say when to use 'color' instead of 'util_rainbow' or 'spectrum'.
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 is the sole source of behavioral info. It discloses only the basic action and lacks details about reversibility, side effects, or selection defaulting to 'all'. The agent cannot tell if hidden representations are merely toggled off or if there are any lasting consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple tool, though it sacrifices informative detail that would improve other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and fully described parameters, so the description need not cover return values. It adequately states the core function, but the absence of usage context, exclusions, and behavioral detail—compounded by missing annotations—leaves the description minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions, giving 100% schema coverage. The description adds no meaningful parameter semantics beyond the schema; 'given selection' is already captured by the schema's 'PyMOL selection string.' Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Hides a graphical representation for a given selection.' It identifies the resource (graphical representation) and the scoping (selection). It does not explicitly differentiate from sibling tools like delete or remove, but the verb 'hide' conveys a visibility toggle rather than destruction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as show, delete, or remove. The description merely states the action without context, exclusions, or alternative tool recommendations.
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. It states only that it creates an object, but does not disclose whether it modifies existing objects, what happens on naming conflicts, or any computational requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but omits necessary context. It is not as egregiously under-specified as 'Process', but still minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with an output schema and fully described parameters, the description is minimally sufficient but would benefit from stating that a loaded map and level are required, as well as how it differs from isomesh.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides comprehensive descriptions for all four parameters, so the description adds no additional semantic context. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Creates' and specific resource 'solid isosurface', distinguishing it from the sibling 'isomesh' which likely creates a mesh. However, it does not explicitly mention the relationship to map data or contour levels, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use isosurface vs alternatives like isomesh, nor any prerequisites such as requiring a loaded map. This is a gap.
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, and the description merely restates the basic action without adding behavioral details. It does not mention coordinate frame, sign conventions, whether movement is relative or absolute, or what happens when distance is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant information. It is appropriately front-loaded, though it is so terse that it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple camera-move tool with full schema coverage and an output schema, the minimal description is arguably sufficient. However, the lack of behavioral context and usage alternatives leaves it adequate but with clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage, including descriptions for both axis ('x', 'y', 'z') and distance ('Angstrom') with a default value. Since the schema already explains the parameters clearly, the description adds no extra semantic value, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Moves') and resource ('camera along an axis'), making the primary function clear. It does not explicitly distinguish itself from sibling camera tools like turn, orient, or zoom, but the translational nature is implied by 'along an axis'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as turn, orient, zoom, or center. There are no contextual cues, prerequisites, or exclusions, leaving the AI agent to guess based on the name 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, the description carries the full burden, but it only says 'Saves a PNG image'. It does not mention file creation side effects, whether the current view is captured, or any prerequisites (e.g., an existing scene). This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It is concise but not so sparse that it becomes a tautology, unlike 'Process'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter tool with a clear purpose. Given the minimal schema and lack of annotations, the description is minimally adequate but leaves room for improvement (e.g., specifying that it saves the current view or that 'options' can control resolution).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions), so the schema already explains 'filename' and 'options'. The tool description adds no extra parameter meaning, earning the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'saves' and the resource 'PNG image', making the core purpose obvious. However, it does not explicitly distinguish this from sibling tools like 'save' or 'render', which could also produce image files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'mpng' or 'ray'. It simply states what it does without context, leaving the agent to infer usage.
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 must carry the full burden of behavioral disclosure, but it merely states the action without revealing side effects, such as overwriting existing symmetry settings, requiring a molecular object, or triggering recalculation. It does not disclose any constraints or expected outcomes beyond the immediate assignment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous words. It is front-loaded with the verb and object, though it is perhaps too terse given the tool's complexity. Still, it is efficiently written and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 required parameters and no annotations, the description is inadequate for correct invocation. It does not explain what constitutes a valid 'object', how the selection should be formatted, or any context about unit cell conventions. The presence of an output schema does not compensate for the lack of usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (a, b, c, alpha, beta, gamma, selection) already described in the input schema. The description adds no additional parameter-level meaning, so the baseline score of 3 applies without further credit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets symmetry parameters for an object. It uses a specific verb ('sets') and resource ('symmetry parameters'), which is distinct from generic sibling tools like 'set'. However, it does not enumerate the specific parameters (a, b, c, angles), leaving some ambiguity that the schema partially resolves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as needing a selected object or crystal system. Sibling tools like 'set' or 'alter' exist, but no distinctions or exclusions are stated.
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 states the primary coloring action but fails to mention that it recolors the entire structure unless a selection is specified, or that it overrides existing colors. No side effects or limitations are disclosed, leaving the agent unaware of the tool's full impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, efficiently conveying the core action. The parenthetical clarification is helpful, though the wording is slightly awkward. It is appropriately sized for a simple tool with minimal parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description provides a basic understanding of the action but lacks context about selection scope, effect on existing colors, and how it fits into the broader set of color utilities. The output schema exists, so return values need not be described, but the description could be more complete by referencing the selection parameter or the standard color scheme.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'selection' parameter, including its default value and description. The tool description itself adds no additional parameter semantics, but the schema already provides sufficient detail, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool colors atoms with carbons in slate blue, using the phrase 'Colors by atom, slate carbons.' This specifies a verb, resource, and specific color choice, distinguishing it from other color-by-atom siblings that likely use different carbon colors. However, it could be more explicit about the overall scheme (e.g., standard element colors with modified carbon).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool compared to other color tools like 'color', 'util_cbc', or 'util_chainbow'. It does not mention selection behavior or any prerequisites, leaving the agent without context for choosing this over alternatives.
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 disclosure. It states the visual outcome ('purple carbons') but does not explain whether it recolors all atoms by element, whether it overwrites current colors, how it interacts with the 'selection' parameter, or any side effects. The phrase 'Colors by atom' is ambiguous about scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence, front-loaded with the core action. There is no wasted text, though the phrasing is slightly awkward and omits important context that would make it more useful. It earns a 4 for efficiency rather than a 5 due to the terse and incomplete nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one optional parameter and an output schema, but the description is minimal. It does not explain how it differs from the many sibling utilities (e.g., util_cbag, util_cbab) or clarify the exact coloring behavior. It is adequate for a basic utility but leaves gaps for users unfamiliar with PyMOL conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'selection' parameter with its own description ('What to recolour. Defaults to everything.'), so the baseline is 3. The tool description adds no additional meaning about the parameter, but does not need to because the schema already explains it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Colors by atom, purple carbons' clearly states a specific verb (colors) and resource (atoms, specifically carbons in purple). It distinguishes from generic 'color' and other utility tools by naming the purple carbon scheme, though it could be more explicit about coloring all atoms by element with carbons purple.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many similar sibling utilities like util_cbag or util_cbc. The description merely states what it does, leaving the user to infer usage context from the name and existing knowledge.
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 exist, so the description carries the full burden. It only says 'Colors' without disclosing that it modifies existing colors, whether it applies to the selected atoms only or all objects, or any side effects. The behavior is implied but not transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the key verb and target. It has no wasted words, though it could be slightly more structured or complete. It earns a 4 for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (1 optional parameter) and the existence of an output schema, the description provides the minimum viable information. However, it lacks details about what 'by atom' means (e.g., element-based coloring), potential scope, or how it relates to siblings, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'selection' parameter, so the schema already documents it. The description adds the general effect (white carbons) but no additional parameter-specific semantics beyond what the schema provides, which aligns with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Colors') and the target ('atoms'), and specifies a distinguishing detail ('white carbons'). It clearly indicates this is a coloring utility, though the exact meaning of 'by atom' and how it differs from many sibling color tools is not fully explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many alternative coloring utilities (e.g., util_cbc, util_cbag, util_rainbow). The description does not mention any context, 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, the description carries the full burden of behavioral disclosure. It only states the basic action and does not explain what happens to the camera orientation, zoom level, or persistency, nor whether the view is reset or adjusted relative to the current state. This is a significant gap for a view manipulation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words or filler. It is appropriately concise for a simple tool, though it could be slightly expanded to include usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a complete parameter schema and an output schema, the description lacks behavioral transparency and usage guidelines. Given the large set of sibling view-related tools, the absence of contextual differentiators makes the description insufficient for an agent to reliably decide when and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters ('buffer' and 'selection'), covering 100% of the parameter semantics. The description itself adds no additional meaning beyond restating the 'selection' concept, so it does not exceed the baseline provided by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Zooms the view on a selection' clearly states the tool's action (zooming), the resource (view), and the target (selection). It is specific enough to suggest a camera/view adjustment, but it does not explicitly distinguish itself from sibling tools like 'orient' or 'center' which also affect the view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to prefer this tool over alternatives such as 'center', 'orient', or 'reset'. There is no mention of typical use cases, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.
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 full burden. It simply states a toggle but does not disclose whether it starts/stops an animation, if it's instantaneous, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. However, it could be slightly more informative while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and lack of annotations, the description is minimal. It does not explain what 'rocking' means, whether the animation is continuous, or how it interacts with other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%, so baseline is 4. The description does not need to add param info, but it also does not provide additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Toggles' and resource 'rocking animation', clearly indicating what the tool does. However, 'rocking' may be ambiguous without further context, and it does not differentiate from siblings like 'turn' or 'move'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No context about when rocking is appropriate or what it entails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It simply states 'Sets the cartoon type' without mentioning side effects, reversibility, or what happens to existing cartoon settings. The tool's mutating behavior is implied but never elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or extraneous information. Every word contributes to the core purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a rich input schema and an output schema, yet the description lacks any usage context or exclusionary guidance. It is adequate for a minimal tool but does not fully address the broader context of when or how to use it beyond the literal action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already provides detailed descriptions for both parameters (item_type and selection). The tool description adds nothing beyond the schema, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sets the cartoon type for the specified selection' uses a specific verb ('sets') and resource ('cartoon type'), clearly distinguishing it from sibling tools like 'show', 'set', or 'as'. The target 'selection' is also specific, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use cartoon versus alternative representations or how it relates to other tools. The description is purely declarative and offers no exclusions, prerequisites, or comparisons to siblings, leaving the agent without usage 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 must disclose behavioral traits. It only states the primary function but does not reveal whether the operation modifies the selection, preserves zoom, is reversible, or has any side effects. For a view operation, these details matter for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action and target, with no redundant information. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter view tool, the description plus schema covers the basic function, but the lack of annotations and absence of guidance on when to use it relative to similar sibling tools leaves gaps. The output schema exists, so return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage with a clear description for the 'selection' parameter. The tool description adds no additional parameter information beyond what is in 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'centers' and resource 'view' on a 'selection', clearly stating the tool's function. It does not explicitly differentiate from sibling view tools like 'orient' or 'zoom', but the action is distinct enough to infer purpose. This is clear but lacks explicit sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'orient' or 'zoom'. The description only states what it does, leaving the agent to infer usage context without any exclusions or comparisons.
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 only states 'Adjusts the clipping planes' without disclosing that this changes visibility/rendering, how distance interacts with modes, or any side effects. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and target, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with full schema coverage and an output schema present, the description is minimally viable. However, it lacks usage context and is too terse to fully guide an agent in all situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with mode and distance clearly explained in the input schema. The description itself adds no extra parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Adjusts' and a clear resource 'clipping planes,' making the tool's function evident. It is distinct from sibling tools like zoom or orient, which affect the view but not the clip planes directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as viewport, zoom, or orient. There is no mention of exclusions, prerequisites, or specific scenarios.
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 must disclose behavioral traits, but it only states the basic action. It does not mention that the operation copies atoms and leaves the original intact, nor does it disclose potential side effects. The schema's selection parameter description notes 'The original is left in place', but this is not carried into the main description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action. It is not verbose, but given the tool's need for contextual behavior, the brevity borders on under-specification. Still, the sentence is well-structured and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a schema with full parameter descriptions and an output schema, the description fails to provide essential context that distinguishes this tool from similar ones like 'extract' (which removes from the original) or 'select'. The presence of numerous sibling tools and no annotations makes this a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (name, selection, source_state), achieving 100% coverage. The description itself adds no additional parameter information, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'creates' and specifies the resource 'a new object from a selection', clearly indicating the action. This distinguishes it from tools like 'extract' or 'delete' which also manipulate objects but with different semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'extract' (which removes atoms from the original) or 'select'. The description only states what the tool does, leaving the agent without decision criteria.
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?
Annotations are absent, so the description carries the full burden. It states the destructive action ('Deletes') but does not disclose irreversibility, side effects on dependent objects, or the fact that wildcards and 'all' can mass-delete. The name and schema hint at these behaviors, but the description itself adds little beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, appropriately sized sentence: 'Deletes objects or selections.' It is front-loaded with the verb and object, contains no filler, and is suitably concise for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with a rich schema and an output schema, the description provides the basic invocation context. However, as a destructive tool with no annotations, it would benefit from clarifying permanence and differentiating from sibling tools like 'remove', so the description is minimally complete but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the 'name' parameter is fully described with wildcard examples and the special 'all' value. The description adds no extra parameter context, but the schema already provides the necessary details, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Deletes') and identifies the resource ('objects or selections'), making the core purpose clear. It does not explicitly distinguish itself from similar sibling tools like 'remove' or 'deselect', but the meaning is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as 'remove', 'deselect', or 'hide'. There are no exclusions, prerequisites, or preference hints, leaving the agent without context for tool selection.
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. The description simply says 'Extracts a selection to a new object' without explicitly stating that the selection is removed from the original object; this critical side effect is only clarified in the parameter description. The word 'extracts' hints at removal but is not explicit enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. It is appropriately sized and front-loaded with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple two-parameter schema with full documentation and an output schema, so the basic usage is clear. However, the description lacks explicit disclosure of the removal side effect and offers no usage guidance, which is a gap given the lack of annotations. The schema compensates partially, but the description itself is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters with 100% coverage, so the baseline is 3. The main description adds no additional parameter semantics beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Extracts a selection to a new object' clearly identifies the action (extract) and the resource (selection to a new object). It is specific enough to distinguish from siblings like 'create' because 'extract' implies removal, though it does not explicitly contrast with 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as 'create' or 'select'. The parameter description for 'selection' mentions 'Unlike create' but that is in the structured schema, not the main description, so the description itself lacks usage 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Loads a molecular fragment' without indicating side effects, object creation, or the outcome of the load. This is insufficient for the agent to understand the tool's 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant information. It is appropriately sized for a simple tool with one well-documented parameter, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of a rich output schema, the description is minimally viable. However, it lacks context about what happens after loading (e.g., object creation, display) and how it relates to sibling operations, leaving a clear gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'name' is fully described in the schema with a clear definition and examples ('benzene', 'ala', 'formamide'), giving 100% schema description coverage. The description adds no extra parameter meaning beyond what the schema already provides, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('loads') and resource ('molecular fragment'), giving a specific verb+resource. However, it does not explicitly differentiate from sibling tools like load_structure or fetch_structure, which also load molecular entities, so it lacks sibling 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/5
Does 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. There is no mention of when to choose 'fragment' over load_structure or fetch_structure, leaving the agent without context for tool selection.
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, and the description only states the action itself. It does not disclose side effects, whether existing hydrogens are replaced, or any state changes, leaving behavioral characteristics largely hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundancy. It is highly concise and front-loaded, putting the action and target first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter interface and presence of an output schema, the description is minimally sufficient. However, it lacks usage context, alternative tool differentiation, and behavioral disclosures, creating a slight gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the selection parameter with its default 'all' and description 'Where to add hydrogens.' The tool description adds nothing 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Adds') and resource ('hydrogens') plus target ('to a selection'), clearly conveying the operation. It doesn't distinguish from the sibling h_fill, but the core purpose is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use h_add versus alternatives like h_fill, or any context about preparation steps or prerequisites. The description simply states the action without usage scenarios.
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 says 'saves a series of PNG images', omitting important traits such as whether this overwrites existing files, requires a loaded movie, or creates multiple files on disk. The schema does add context about zero-padded frame numbers, but the description itself is too sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core function without any filler. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, output schema exists), but the description leaves gaps: no usage guidance, no behavioral details beyond the bare action, and no mention of prerequisites (e.g., a loaded movie). It is minimally viable but not fully complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains the 'prefix' parameter with the zero-padded frame number behavior. The description adds no additional parameter semantics, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('saves') and resource ('series of PNG images for movie frames'), clearly distinguishing from the sibling 'png' tool by emphasizing 'series' and 'movie frames'. However, it could more explicitly contrast with 'png' or 'render' for full 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'png' (single frame) or 'save'. The intended use case is only implied by the words 'movie frames', with no explicit when-to-use 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, the description must fully disclose behavioral traits. It states 'resets the view' but does not clarify what 'reset' means (e.g., revert to default camera, restore home view) or what exactly happens to an object's matrix (e.g., set to identity). It also does not disclose any side effects, reversibility, or errors. This leaves the agent uncertain about the tool's 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that directly states the action and optional scope. It contains no filler, redundancy, or unnecessary detail, making it highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter, no annotations, and an output schema that may explain return values. The description covers the core action but lacks details on exact behavior (e.g., what 'reset' means precisely) and does not position it relative to sibling view tools. For such a simple tool, this is minimally complete but not rich enough for a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the 'obj' parameter already has a clear description ('Object whose matrix to reset. Omit to reset only the camera.'). The tool description adds no further parameter semantics beyond what the schema provides, but the schema itself is sufficient, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Resets' and identifies both the primary resource ('the view') and an optional secondary target ('an object's matrix'). This clearly distinguishes it from other view-adjustment tools like 'center', 'orient', or 'zoom', which adjust rather than reset. However, it does not explicitly name any sibling tools, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for resetting the view or an object's matrix but provides no when-to-use or when-not-to-use guidance. It does not mention alternatives or conditions like 'use this when you need to revert to the default view', nor does it warn against using it when other view adjustments are intended. This is minimal guidance.
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 does not mention side effects, reversibility, or what enabling sculpting mode actually entails. The only extra hint ('real-space sculpting') appears in the parameter description, not the main description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and structured effectively for a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description is minimally adequate. However, it omits behavioral context such as prerequisites, effects, and reversibility, and with no annotations this creates a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the single parameter 'obj' ('Object to enable real-space sculpting on'). The main description adds no further meaning, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Activates') and the resource ('sculpting mode for an object'). It is distinguishable from siblings like sculpt_deactivate and sculpt_iterate by the activation verb, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as sculpt_deactivate or sculpt_iterate. There are no prerequisites, exclusions, or context describing the appropriate workflow.
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 disclosure. It only states 'Sets a PyMOL setting' but does not disclose that settings can be scoped to a selection, that values are strings, or that changes may affect rendering/session state. The side effects and scope of the operation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no redundancy or filler. It is front-loaded and immediately conveys the tool's essence, which is ideal for a simple setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a basic setter, the description is minimally adequate: it covers the action and the object, and the schema covers parameters. However, it omits nuances like global-vs-selection scoping, case sensitivity of setting names, and whether the operation returns a confirmation. As an output schema exists, full return value description is not required, but some contextual guidance would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all three parameters ('setting', 'value', 'selection') with clear descriptions and examples. The description adds no additional parameter-level meaning, so the baseline of 3 applies because the schema already documents everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sets') and the resource ('a PyMOL setting to a specified value'), which makes the core purpose understandable. However, it does not differentiate from siblings like 'execute_pymol_command' which could also be used to set settings, and it lacks examples of typical settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention that this is the preferred way to modify individual settings, nor does it point to 'execute_pymol_command' for arbitrary PyMOL commands or 'show'/'hide' for common visual toggles.
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, but it only restates the operation. It does not disclose whether the command modifies coordinates, whether the operation is reversible, or what side effects may occur, which is important for a structural alignment 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence front-loaded with the action verb and no filler. It is concise and effective, though it borders on being too terse for the complex domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage and an output schema present, the description plus schema provides a minimally viable understanding of the tool's behavior. However, given the complex structural biology context and the many sibling tools, it lacks alternative differentiation and important behavioral context such as side effects or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with meaningful descriptions, so the baseline is 3. The tool description itself adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('superimposes') and identifies the resource ('one selection onto another'), making the core function immediately clear. However, it does not differentiate this tool from sibling tools like 'align' or 'intra_fit', which also involve structural superposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternative alignment/superposition tools in the sibling list. The schema's parameter descriptions ('Selection to move', 'this one stays put') clarify parameter roles but do not provide usage context or exclusion criteria.
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 disclosing behavioral traits. It mentions the coloring outcome but does not state whether existing colors are replaced, whether non-carbon atoms are also recolored, or how the selection parameter affects the operation. This is minimal and leaves key behaviors unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no unnecessary words, front-loading the action and color. The parenthetical is a brief clarification that adds value without bloat, making it highly efficient for the agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one well-documented parameter and an output schema, the description conveys the core functionality. However, it lacks usage context relative to the many sibling color utilities and does not fully clarify the exact effect on all atoms (e.g., whether non-carbon atoms get recolored), leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter 'selection' is clearly described ('What to recolour. Defaults to everything.'). The tool description adds no additional semantic detail beyond what the schema already provides, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Colors by atom') and the specific resource ('orange carbons'), which distinguishes it from sibling color utilities by color. The parenthetical '(Color By Atom, Orange)' reinforces the intent, though it could be more explicit that it colors all atoms by element with an orange carbon override.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as util_cbc or util_cbag. The description simply states what it does without mentioning contexts, prerequisites, or exclusions, leaving the agent to infer usage from the 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, the description must carry the full burden, but 'Sets' only implies a mutation. It does not disclose side effects, rendering triggers, or any behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is appropriately small for a simple setter, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial setter, the description covers the basic action and parameters, but it lacks context about what the viewport is and when to use the tool. The presence of an output schema does not compensate for missing usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (width and height explicitly described as pixels), so the baseline is 3. The tool description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sets the viewport size' uses a clear verb and resource, indicating the tool's function. However, it does not differentiate this from view-related siblings like zoom or orient, so sibling distinction is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction for selection.
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 'starts playing', omitting details like whether playback loops, if prior setup is required, or what happens if no movie is loaded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema (though not provided), the description is minimal but functional. It lacks context about the tool's role within movie playback (e.g., relation to mset, mstop) and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so baseline is 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Starts playing the movie' clearly identifies the tool's action as initiating playback, distinguishing it from siblings like mset (set movie parameters) and mstop (stop movie). However, it lacks context about what 'the movie' refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as mset or mstop. The description does not mention prerequisites or common usage scenarios.
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 present, so the description must disclose behavioral traits. It only states 'Stops the movie' without detailing side effects, such as whether ongoing animations are interrupted or if the movie resets. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, with no unnecessary content. The purpose is front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description is adequate but minimal. It does not explain the context of movie playback or how this tool fits with siblings like mplay.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the input schema is complete. The description adds no parameter information, but none is needed. The baseline is high due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stops the movie' clearly states the verb and resource, effectively conveying the tool's purpose. However, it lacks differentiation from sibling tools like mplay or mset, which are also movie-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not include context about prerequisites, typical use cases, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning side effects, prerequisites, relative/absolute rotation, or undoability. The schema adds angle details, but the description itself contributes no behavioral context beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, though slightly under-specified for a tool with many siblings, so it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the schema's coverage of parameters, the description is minimally adequate. However, it lacks usage differentiation and behavioral context, which are important given the large sibling set. The presence of an output schema offsets the need to explain return values, keeping the score at a passing but not strong 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both axis and angle clearly documented in the input schema. The description adds no additional parameter meaning, but the baseline of 3 is appropriate because the schema already provides sufficient semantics for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("Rotates") with a clear resource ("camera") and a distinguishing detail ("around an axis"). It clearly differentiates from sibling tools like move (translation), zoom, or rock, making the tool's 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/5
Does 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. With many sibling tools (e.g., move, orient, turntable), there is no clarification of specific scenarios or exclusions. The agent must infer usage solely from the name and schema.
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 disclosure. It only says 'Colors secondary structure elements' without explaining whether existing colors are overwritten, if it is reversible, or what specific color scheme is applied. This is significant under-specification for a mutation-like 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly conveys the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a simple schema and output schema, the description lacks essential context about the tool's behavior and place among many sibling color utilities. It provides no information on output, side effects, or typical scenarios, which is inadequate for an agent to confidently select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the only parameter (`selection`) with a default and explanation ('What to recolour. Defaults to everything.'). The tool description adds no additional parameter semantics, so the baseline of 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Colors secondary structure elements' clearly states the action (colors) and the target (secondary structure elements), distinguishing it from sibling color utilities like `color` or `util_rainbow`. It is specific and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as `color`, `spectrum`, or other `util_color_*` functions. The description does not mention any exclusions, prerequisites, or recommended use cases.
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 basic action without any details on side effects, prerequisites, or what happens to the selection state beyond clearing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero waste, front-loading the clear purpose. It is appropriately sized for a tool with no parameters and a straightforward action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (0 parameters, simple action) and the presence of an output schema, the description is adequate. It clearly states the tool's purpose, though it could potentially add context about the effect on the selection state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%. Since there is nothing to describe, the baseline is 4, and the description does not add any unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'clears' and specifies the resource 'current selection', clearly indicating the tool's function. It distinguishes itself from the sibling tool 'select' which does the opposite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'select' or other selection-related tools. There is no mention of usage context 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, the description carries full burden for disclosing behavioral traits. It only states that it creates a peptide chain, but does not mention what the tool actually does in terms of the molecular structure (e.g., backbone, termini, defaults), whether it affects the current session, or what errors might occur. This is a significant transparency gap for a mutation-like 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. Every word adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (two simple parameters, no nested objects) and the presence of an output schema, a minimal description is adequate. However, the lack of behavioral disclosure (e.g., whether it modifies an existing object or creates a new one) leaves some contextual gaps, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'sequence' and 'options' have descriptive text, with an example for 'options'. The tool description adds no additional parameter semantics, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'creates' and the resource 'peptide chain' with its source ('from a sequence'). It is specific and distinguishes this tool from generic 'create' and other visualization/structure manipulation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, side effects, or scenarios where 'fab' is preferred. The description only states what it does, not when to use it.
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 must carry the full burden of behavioral disclosure. The description only states the dual set/query behavior but omits important details such as what happens when querying before any frame is set, whether setting affects the animation state, or any error conditions. This is extremely thin for a tool with no safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and resource. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, clear schema, output schema present), the description is minimally viable but still leaves gaps. It does not mention that setting/queries apply to a movie frame, prerequisites, or the format of the query result. The description is adequate for a trivial tool but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description explicitly explains that omitting 'frame_number' queries the current frame, while providing it jumps to that frame. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Sets or queries') and resource ('current frame'). It distinguishes itself from sibling navigation tools like 'forward' and 'backward' by indicating that this tool sets/gets an arbitrary frame rather than stepping through frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., a movie must be loaded) or when choosing this over sibling commands like 'mplay' or 'forward' is appropriate. The schema is the only source of usage context, not the 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?
No annotations are provided, so the description carries the full behavioral burden. It only states that the tool 'defines a sequence of states' without disclosing side effects, whether it overwrites existing settings, or how the sequence is applied. This is minimal disclosure for a command that mutates playback state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise, though the verb 'defines' is slightly vague and no additional structure (such as usage context) is included; still, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter, the schema fully describes it with examples, and an output schema exists, so the simple one-sentence description is largely adequate. It lacks behavioral detail and sibling differentiation, but given the low complexity, it covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the specification parameter already includes examples ('1 x30' to hold, '1 -30' to sweep). The tool description adds no extra parameter-level semantics, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource ('Defines a sequence of states for movie playback'), which conveys the tool's core function. It is specific enough to distinguish from playback control siblings like mplay, mstop, frame, forward, and backward, though 'defines' is somewhat generic and doesn't explicitly name the movie-state artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for movie playback' implies the context of setting up movie states, but there is no explicit guidance on when to prefer this tool over related siblings such as morph_states, frame, or mplay. No exclusions or alternatives 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?
With no annotations provided, the description carries the full burden. It only states the core action without disclosing side effects, reversibility, prerequisites, or error conditions. It does not contradict annotations (none exist), but it is minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no extraneous wording. It is front-loaded with the verb and resource, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the basic purpose. However, with no annotations and no mention of behavior when sculpting is inactive, output expectations, or relation to other sculpt commands, it is not fully complete. The output schema existence is noted but its content is unknown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'obj' is fully described in the input schema ('Object to stop sculpting'), so the description need not add more. The description itself does not mention parameters, but schema coverage is complete, earning the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deactivates') and resource ('sculpting mode for an object'), which distinguishes it from siblings like sculpt_activate and sculpt_iterate. It is specific and unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, its context, or alternatives. It lacks any mention of prerequisites, typical workflows, or relationships to sculpt_activate/sculpt_iterate.
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 says 'Shows a graphical representation' but does not explain whether the representation is added to or replaces existing ones, or disclose any side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that gets straight to the point without any redundant or irrelevant information. It is as concise as possible while still conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema's rich parameter descriptions, the description itself is minimal and does not clarify the tool's behavior relative to similar commands (e.g., 'as' or 'hide') or its effect on the current state. Given the tool's relative simplicity, this is adequate but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter definitions (e.g., selection string syntax, representation options). The description adds no parameter-specific meaning beyond that, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Shows a graphical representation for a given selection.' It identifies the resource (graphical representation) and scope (given selection), distinguishing it from sibling commands like 'hide' or 'delete'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as 'as' (which sets representation) or 'hide'. There is no mention of context, 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, the description carries the full burden of behavioral disclosure. It only states the general visual effect and does not disclose side effects like whether it replaces existing representations, applies state changes, or how it handles invalid object names. The schema's note about object resolution helps, but the tool description itself remains 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and contains no wasted words. It is appropriately sized for a simple display command.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description alone lacks context about how the display state is modified and when to prefer this tool over siblings. The rich parameter schema covers object resolution behavior, but tool-level usage context is missing, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so per rubric the baseline is 3. The tool description adds no parameter semantics, but the schema's parameter description already explains the object-name requirement and error behavior, making the baseline appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Displays atoms as smooth spheres' uses a specific verb and resource, clearly distinguishing this tool from siblings like show, hide, and cartoon. It conveys exactly what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'show' or 'cartoon'. It neither states explicit use cases nor excludes situations where other representation tools would be more appropriate.
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?
There are no annotations, so the description must carry the behavioral disclosure burden. It states the coloring action but does not mention that existing colors are overwritten, whether the optional selection restricts scope, or whether standard element-color assignments are used. These are material behavioral details missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly states the core function with no redundant words. It is front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter utility, the description plus schema cover the basic functionality and selection default. However, lack of usage guidance and behavioral details (e.g., overriding existing colors) leaves it minimally complete. Output schema presence reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'selection' parameter is fully described in the schema ('What to recolour. Defaults to everything.'), so the schema already covers parameter semantics. The tool description adds no parameter-specific information beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Colors') and resource ('atoms') with a clear method ('by their element'), distinguishing it from generic sibling tools like 'color' or 'util_color_secondary'. It directly explains the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'color', 'spectrum', or 'util_color_secondary'. There is no mention of selection scoping or prerequisites. The description simply states the action without contextual direction.
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 the full burden of behavioral disclosure. It only states the basic action without mentioning side effects such as whether labels persist, how they interact with other states, or any potential toggling requirements. This lacks transparency for a tool that modifies the display.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It states the core purpose efficiently, though it omits optional contextual details. It is concise without being under-specified to the point of confusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the presence of a full input schema and output schema, the description is adequate but thin. It could mention how labels are removed or whether the operation affects the rendered scene globally. The schema covers parameters and output, so the description's minimalism is partially compensated, but additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description itself adds no parameter-specific meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (adds labels) and the resource (atoms in the selection). It is distinct from sibling tools like 'show' or 'color', which pertain to representations or coloring rather than text labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to label atoms), but does not explicitly mention alternatives or when not to use it. There is no guidance on how this relates to other display or annotation tools, so the usage context is clear but exclusions are absent.
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 responsibility. It discloses the core behavior (coloring by atom with cyan carbons) but does not mention whether it overrides existing colors, affects only selected atoms, or has other side effects. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the key information. However, the parenthetical '(Color By Atom, Cyan)' redundantly restates the preceding phrase, which slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema, but the description does not differentiate among the many similar util_cb* siblings. Agents may struggle to choose this tool over alternatives without additional context. The description is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a complete description for the single 'selection' parameter ('What to recolour. Defaults to everything.'). The tool description adds no additional parameter semantics, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: coloring by atom with cyan carbons. It distinguishes itself from sibling color tools by explicitly naming the cyan carbon scheme, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With many sibling color utilities (e.g., util_cbc, util_cbaw, color), the description fails to explain selection criteria or scenarios where this specific tool is preferred.
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 must disclose behavioral traits, but it only states the coloring action. It does not mention whether this is a non-destructive view change, whether it affects only the selection or all objects, or whether it overrides existing colors. This is a significant gap for a tool that modifies the visual state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded, but the parenthetical '(Color By Atom, Magenta)' repeats the same information in the first half, which is redundant. It still earns its place by being short and readable, but the redundancy slightly reduces the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and the existence of an output schema, the description is minimally adequate. However, it does not explain the effect on the scene, whether the selection is atom-based or object-based, or how this compares to other coloring utilities. For a tool with many siblings, more context could help selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the only parameter (selection) with 'What to recolour. Defaults to everything.' at 100% coverage. The description adds no extra parameter details 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Colors by atom') and the specific detail ('magenta carbons'), which distinguishes it from sibling tools like util_cbc (likely cyan) or util_cbag (green). It is a specific verb+resource statement that leaves no doubt about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for coloring atoms magenta, but provides no explicit when-to-use vs alternatives. There is no mention of exclusions or other color-by-atom variants, so the guidance is only implicit from the 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, the description carries the full burden of behavioral disclosure, but it only states the effect. It does not mention whether existing colors are overwritten, how the selection parameter affects the outcome, or what 'rainbow gradient' means in practice (e.g., per-chain coloring). This leaves significant behavioral ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the essential action. The parenthetical '(CHAINs in rainBOW)' is a stylistic pun that adds no factual information, slightly reducing efficiency, but overall the description remains appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter with full schema coverage and an output schema), the description is minimally viable. However, it lacks behavioral context (e.g., how selection is applied, whether it affects all chains or only current selection) and does not differentiate from similar sibling tools, making it complete only at a basic level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'selection' parameter, which is already documented as 'What to recolour. Defaults to everything.' The tool description adds no additional parameter semantics, so it meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Colors chains in rainbow gradient' uses a specific verb ('colors'), resource ('chains'), and effect ('rainbow gradient'), clearly distinguishing it from general coloring tools like 'color' and 'spectrum' by targeting chains specifically. The parenthetical pun reinforces the tool name without adding ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('colors chains') but provides no explicit guidance on when to use this tool versus alternatives such as 'spectrum' or 'util_rainbow'. There is no mention of prerequisites, exclusions, or conditions, so it relies on the reader inferring context from the 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 full responsibility for behavioral disclosure. It only states that RMSD is calculated, but does not mention whether the tool modifies the object, requires specific state setup, or produces an output in a particular format. The existence of an output schema reduces the need to describe return values, but other behavioral aspects remain undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose. It is appropriately sized for a simple tool with one parameter, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so the description covers the essential function. However, it lacks context about when to use this tool versus siblings and does not clarify behavioral traits like non-destructiveness or state requirements. It is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single parameter 'selection' with description 'Object whose states to compare.' Tool description adds little beyond the schema phrase 'within an object'. With 100% schema coverage, baseline is 3, and no additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Calculates RMSD between states within an object'. It specifies a concrete verb ('Calculates') and resource ('RMSD between states within an object'), distinguishing it from siblings like 'rms_cur' (likely inter-object RMSD) and 'intra_fit' (fitting rather than calculating).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context by saying 'between states within an object', contrasting with cross-object comparisons. However, it does not explicitly state when to use this tool over alternatives like 'rms_cur' or 'intra_fit', nor does it provide any exclusions or prerequisites.
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 full behavioral burden. It mentions the BFS multimer heuristic but fails to disclose that the default behavior (replace=true) clears the session before loading, which is a significant side effect. It also omits the option to add structures without clearing (replace=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's core function and unique heuristic. Every word earns its place, and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists and the input schema is rich, the description lacks guidance on important contextual nuances such as the replace parameter's effect on the session and how to intentionally load multiple structures. It is adequate for a simple load operation but leaves some context to be inferred from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level detail beyond what the schema already provides, so it earns the baseline score without further compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Loads a structure') and a resource ('from a local file path'), and adds a distinguishing detail ('applies the BFS multimer heuristic'). This separates it from siblings like fetch_structure (remote) and load_session (session file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'local file path' implies when to use this tool, but there is no explicit comparison to alternatives like fetch_structure or load_session, nor any 'when not to use' guidance. The usage context is implied rather than explicitly stated.
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 carries full responsibility. It simply states 'Removes a bond' without disclosing side effects (e.g., whether this modifies the molecular structure permanently, if it affects display, or behavior when the bond does not exist). This lack of behavioral context makes it inadequate for a mutation-like 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains zero waste. It effectively communicates the essential action without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage, an output schema, and a simple 2-parameter operation, the description is minimally sufficient. However, it omits any usage context or edge-case behavior, leaving the agent to infer when and how to apply the tool. It is adequate but not enriched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly described. The description adds no extra meaning beyond the schema, but since the schema fully explains 'atom1' and 'atom2', the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Removes') and names the resource ('a bond between two atoms'), clearly distinguishing it from sibling tool 'bond' which presumably creates bonds. This is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for removing bonds but does not explicitly state when to choose this tool over alternatives (e.g., 'bond' for adding). No context, prerequisites, or exclusions are provided, so it meets the 'implied usage' criterion but lacks 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 burden. It discloses a key side effect (draws a named angle object) and the return unit (degrees), but does not mention prerequisites, failure modes, or scene mutation details beyond the drawn object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and an additional side effect. Every word adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple measurement tool with full schema coverage and an output schema, the description adequately covers purpose and the significant drawing side effect. It could be improved by noting the vertex order semantics, but the schema already provides this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal param meaning beyond 'three selections' and 'named object', which the schema already covers with field descriptions like 'Second selection (the vertex)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool measures the angle between three selections and returns it in degrees. It also mentions it draws the measurement as a named angle object, which distinguishes it from sibling tools like distance or dihedral.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as dihedral or distance. The description implies usage by the domain (measure angle) but does not state exclusions or alternative conditions.
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 does well: it discloses the return unit (Angstrom), the side effect of creating a named distance object in the viewport, and the averaging behavior for multi-atom selections. This goes beyond the tool name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the purpose upfront, followed by the side effect and an edge case. Each sentence adds distinct value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple measurement tool with three parameters and an output schema, the description covers the core functionality, return unit, side effect, and multi-atom behavior. It lacks only minor details like selection syntax or behavior when no pairs are found, but these are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context about the name being used for the drawn object and multi-atom selection behavior, but it does not substantially enrich parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool measures distance between two selections and returns it in Angstrom, which is a specific verb+resource. It also mentions the side effect of drawing the measurement, distinguishing it from measurement tools like angle or dihedral, but does not explicitly name 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for measuring distances but provides no explicit guidance on when to use this tool versus siblings like angle, dihedral, or sasa. There are no exclusions or alternative tool mentions, leaving the agent to infer 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 must carry the behavioral transparency burden. It only states 'Shows help for a command' without disclosing details such as output format, side effects (if any), or state dependence. For a help tool, it is likely read-only, but the description gives no explicit behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning: 'Shows help for a command.' It is appropriately sized for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no annotations, but an output schema exists), the description is mostly complete. It clearly states the tool's purpose, and the parameter description covers the optional command. It could perhaps mention what kind of help is shown (e.g., usage, options), but the minimal context is sufficient for a help command. The output schema likely defines the return format, so the description need not explain it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the parameter 'command' is described as 'PyMOL command to describe. Omit for general help.' This fully clarifies the parameter's meaning and default. The tool description itself adds no additional parameter semantics, but the schema already covers it, so a 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Shows help for a command' uses a specific verb ('shows') and a clear resource ('help for a command'). It clearly distinguishes this tool from sibling tools like 'execute_pymol_command' or specific display commands, as it is the designated help facility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this when you need help on a PyMOL command. However, the description itself does not explicitly state when to use it or mention alternatives, though the parameter description adds 'Omit for general help.' This provides context but not explicit guidance on alternatives or exclusions.
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 must disclose behavioral traits. It states the core effect (aligning the view to principal axes) but does not mention side effects, such as whether the center/zoom is preserved, or that it only changes the view and not the structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It conveys the essential behavior efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple view-orientation tool with one optional parameter and a rich sibling set, the description is nearly complete. It lacks an explicit note on relation to other view commands (e.g., reset or center) but covers the core behavior well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional selection parameter, and the schema description already explains that PyMOL aligns the longest axis with the screen's x-axis. The description adds no parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('orients') and resource ('view') with a clear scope ('principal axes of the selection'). This distinguishes it from sibling view tools like center or reset, which do not mention aligning to principal axes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use orient versus alternatives such as center, zoom, reset, or turn. There are no explicit when/when-not conditions or alternative tool mentions.
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 disclosing behavior. It does state the 'or replaces' aspect, indicating a potential destructive overwrite, and implies persistence. However, it omits other traits like error conditions 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It efficiently communicates the core operation without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and the existence of an output schema, the description sufficiently covers the tool's purpose. It could provide more context about when to use it, but for a basic selection assignment, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both 'name' and 'selection'. The tool description adds no additional parameter meaning, so the schema is doing the heavy lifting, resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates (or replaces)') and names the resource ('a named selection') with a clear purpose ('for later reuse'). It distinguishes itself from siblings like 'create' or 'extract' by focusing on selections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent without context for choosing this over similar selection-related operations.
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 core behavior (rainbow coloring by sequence position) but does not mention side effects like overwriting existing colors, how the selection parameter modifies scope, or whether the change is reversible. It is not misleading but lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part contributes to understanding the tool's action and scheme.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter utility with schema coverage and an output schema, the description is largely sufficient. It lacks usage guidance and alternative differentiation, but is otherwise 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the single 'selection' parameter, and coverage is 100%. The tool description adds no additional parameter-level meaning, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('colors'), resource ('residues'), and method ('rainbow from N to C terminus'), clearly distinguishing it from siblings like util_chainbow or spectrum. It precisely communicates the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative coloring utilities. There is no mention of alternatives, exclusions, or the context in which this coloring scheme is preferred, leaving the agent to infer usage.
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 provided, so description carries burden. It indicates state change ('toggles') but lacks details like whether it returns current state or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (two words), front-loaded with action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with no parameters and output schema exists, so description is adequate for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4 applies. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (toggles) and target (fullscreen mode). Distinct from sibling tools which are all other commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives, but for a simple toggle tool, it's adequate.
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 behavioral disclosure. It goes beyond the basic return value by explaining that it reports sequence-to-residue-number alignment and chain breaks, with reasoning about PDB numbering and unmodelled loops. This adds meaningful behavioral context. It does not discuss failure modes or side effects, but for a simple read-only retrieval, it is quite transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three sentences. The first sentence is direct and operational. The second sentence adds key behavioral details, and the third provides explanatory context. While the third sentence could be shorter, it earns its place by clarifying the significance of the alignment and gaps. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and the parameter schema is rich, the description doesn't need to explain return types. It adequately covers purpose, prerequisites, and key behavioral nuances. However, it does not explicitly address edge cases like invalid chain names or multiple chains, though these may be handled by the output schema. Overall, it is complete for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (obj_name and chain) already have descriptions in the schema. The tool description does not add parameter-level detail beyond the schema; it only mentions 'loaded structure' and 'residue numbers' in general terms. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the amino-acid sequence in FASTA format with a specific verb and resource ('Returns the amino-acid sequence of a loaded structure'). It also mentions additional reporting of sequence alignment and chain breaks, making the purpose specific. However, it does not explicitly distinguish itself from sibling tools, though its function is unique among them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need the sequence of a loaded structure) and mentions a prerequisite ('loaded structure'), but it does not explicitly state alternatives or contrast with other tools. The 'Both matter' paragraph explains why the alignment and gaps are important, which helps contextualize usage, but there is no direct guidance on when to choose this over a sibling.
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 for behavioral transparency. It states the primary behavior (regenerates displayed geometry) and the parameter description gives a trigger condition, but it does not disclose potential side effects, performance implications, or what precisely gets rebuilt beyond the selection parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence ('Regenerates all displayed geometry') that communicates the core purpose without any wasted words. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter, an output schema, and no annotations, making the description adequately informative for basic use. However, the phrase 'all displayed geometry' could mislead users into thinking selection is ignored; while the schema clarifies this, a more complete description would explicitly mention the selection override. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single 'selection' parameter, with a clear explanation ('What to regenerate. Needed after altering coordinates or B-factors...'). The main description does not add additional parameter details, so the baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('regenerates') and the target ('all displayed geometry'), making the tool's purpose understandable. However, it does not explicitly differentiate from sibling tools like 'refresh' or 'redraw', and the term 'all' might obscure the optional selection parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parameter description provides clear context: 'Needed after altering coordinates or B-factors for the change to show.' This signals when the tool is appropriate, but the description does not mention alternatives or exclusions, so it does not fully meet the 'explicit when/when-not' standard.
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 disclose behavioral details. It fails to mention important behaviors like whether hidden files are included, what happens with invalid paths, or how results are presented, passing the burden entirely to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is optimally concise for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the existence of an output schema, the description is mostly sufficient. However, it could benefit from a note about globbing or error behavior, which would round out the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides comprehensive documentation for the single 'path' parameter (description and default). The description adds no extra meaning beyond restating 'current directory', so it earns the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists files in the current directory' uses a specific verb ('lists') and resource ('files'), clearly distinguishing it from sibling tools like 'cd' or 'pwd'. It unambiguously conveys what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is clear from the description: use it to list files in the current directory. While it doesn't explicitly mention alternatives, no sibling tool serves this purpose, so the context is sufficient.
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 addresses it well: it discloses that the continuous surface is replaced by dots, the backbone is hidden, and ligands appear as yellow spheres. It does not mention reversibility or prerequisites, but the core visual behavior is clearly specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and immediately states the primary purpose, followed by relevant visual details. Every sentence contributes value, with no filler or repetition, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter rendering tool, the description covers the essential visual behavior and outcome. It does not discuss when to use it versus alternatives, but given the output schema exists and the parameter is clearly documented, the description is sufficiently 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage for the single parameter 'obj_name' with a clear description and example. The tool description adds no further parameter-specific information, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Renders the structure as an artistic, abstract pointillist/starfield cloud,' with a specific verb and resource. It distinguishes itself from sibling view tools by detailing the unique visual style (dots, hidden backbone, yellow ligand spheres), 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description implies an artistic or abstract visualization but does not state use cases, exclusions, or compare to sibling tools like 'cartoon' or 'surface.' An agent would have to infer appropriateness without clear direction.
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 full burden. It discloses the visual output details (tube radius, B-factor coloring, 70% transparent surface, ligand representation, black background) but does not mention side effects like scene modification, prerequisites such as a loaded object, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each providing distinct visual detail without redundancy. The main purpose is front-loaded in the first sentence, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter view tool, the description thoroughly covers the visual output, and an output schema exists for return values. The only minor gap is the lack of explicit guidance on prerequisites (e.g., object must be loaded) or side effects on the scene.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full documentation for the single parameter obj_name, including a descriptive string and an example. The description adds no additional parameter semantics beyond what the schema specifies, which is acceptable given the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Visualizes protein flexibility using a putty (tube-width) representation', clearly stating the verb and resource. It further specifies the B-factor scaling, colors, surface, and ligand representation, distinguishing it from sibling tools like bfactor_view or plddt_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for protein flexibility visualization, but it does not explicitly state when to use it instead of alternatives like bfactor_view or plddt_view. No when-not scenarios or alternative tool references are provided.
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?
The description explains what the tool displays (all altloc groups with distinct colors and occupancy labels) and why that matters, but does not disclose that it modifies the current PyMOL display state (colors/labels) or any potential side effects such as overwriting existing visual settings. With no annotations, the description carries the full burden and only partially discloses 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is front-loaded with the core function. The subsequent rationale is useful for context but could be slightly more concise; still, every sentence adds value and the length is appropriate for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the purpose, rationale, and core behavior. It lacks explicit mention of side effects or prerequisites (e.g., object must have altloc groups), but the overall context is sufficient. The output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are already fully described in the schema with 100% coverage. The description reiterates the labeling behavior but adds little meaning beyond the schema, such as clarifying the role of obj_name or label. This is baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Show every altloc group at once, one colour per group, occupancies labelled.' This clearly identifies the tool's function and distinguishes it from PyMOL's default single-conformer display, as explained in the following rationale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second paragraph explains when this tool is valuable—when a multiconformer model contains discrete alternatives that PyMOL's default view hides. While it does not name alternative tools or explicit exclusions, it gives clear context about the problem it solves.
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 states the action but does not disclose any side effects, prerequisites, or limitations. For a simple tool, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words) and front-loaded with the essential verb and object. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the minimal description is sufficient for such a simple tool. The context from sibling tools implies it operates in a molecular viewer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is effectively 100%. The description adds no parameter info but follows the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Advances one frame' clearly states the tool's function with a specific verb and resource, distinguishing it from siblings like 'backward' and 'mplay'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'backward' or 'mplay'. It lacks explicit context or exclusions.
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?
The description discloses the visual behavior ('Alternates at q<1 are visually de-emphasised in proportion') and clarifies the semantic meaning, but with no annotations it carries full burden. It does not mention that the tool overwrites B-factors or that restore_bfactors may be needed, even though the schema hints at this via preserve_bfactors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary action in the first sentence and uses later paragraphs to clarify a common misinterpretation. While the third paragraph is somewhat verbose, each sentence contributes to preventing misuse, and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nuance of the occupancy concept, the description provides strong conceptual completeness and an output schema exists to cover return values. It is adequate for an agent to select and invoke the tool, though it omits the B-factor overwriting side effect that the parameter schema hints at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, and the description does not add meaning beyond what the schema already provides. The parameter descriptions in the schema are sufficient, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb phrase 'Colour and scale a structure by per-atom crystallographic occupancy' and clearly distinguishes the tool's scope from sibling views like altloc_view by explaining what the occupancy means and what it does not mean. The resource and action are 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance by explicitly contrasting crystallographic occupancy with particle occupancy, stating 'this tool never reports the other sense.' It implies when to use the tool (for crystallographic occupancy) without naming specific alternative tools, but the context is strong enough to guide selection.
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 provided, so the description carries the full burden. It thoroughly describes the visual output: pocket surface with color coding by chemical character, sidechain sticks, ligand sticks, H-bond dashes, and cartoon backbone. It also specifies the 5 Å definition, adding meaningful behavioral details beyond the bare name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-sentence but each sentence contributes a specific visual element (surface, sidechains, ligand, H-bonds, cartoon). The purpose is front-loaded in the first sentence, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a visualization tool, the description provides a complete picture of the rendered scene, including color schemes and structural representations. It could mention prerequisites (e.g., object loaded, ligand present) or whether it modifies the existing view, but an output schema exists to cover return values, so the description is sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (resn and obj_name) with examples, and the description does not add parameter-specific details. Since schema coverage is 100%, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Visualizes') and resource ('the binding pocket cavity around a ligand'), and distinguishes itself from sibling tools like ligand_view or hydrophobic_surface_view by specifying the pocket-focused surface with residue sidechains and H-bonds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is strongly implied (visualizing a binding pocket around a ligand with a 5 Å cutoff), but there are no explicit when-to-use or when-not-to-use instructions, nor references to alternative tools for different visualization needs.
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. It discloses the pipeline (PDB2PQR then APBS), coloring range (±20 kT/e), visual representation (white cartoon, semi-transparent surface, yellow ligands), and external dependencies. It does not mention computational cost or prerequisites beyond installation, but covers the key side effects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose, followed by pipeline details and installation commands. It is appropriately sized for a complex tool; no sentences are wasted, though the installation block could arguably be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (external tools, specialized view) and minimal schema, the description covers the pipeline, visual output, and dependencies. It omits edge cases like non-protein objects or error states, but the output schema handles return values, making it largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'obj_name' with a clear description. The tool description does not add parameter-specific meaning, but the schema already provides sufficient information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Colors the molecular surface by true Poisson-Boltzmann electrostatic potential', which is a specific verb+resource+scope. It distinguishes itself from generic electrostatic views by mentioning 'true PB' and the PDB2PQR/APBS pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this when you need accurate PB electrostatics. However, there is no explicit comparison to alternatives like 'electrostatic_view' or any when-not-to-use guidance. The installation prerequisites are helpful but do not substitute for direct usage guidelines.
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?
The description provides a detailed visual breakdown of the effects: sharp black outlines, solid white cartoon/surface, and opaque white sticks with outlines, which goes beyond the bare tool name. However, with no annotations, it does not disclose whether settings are reversible, what exactly is toggled, or side effects on the object's existing representation, leaving some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two compact sentences that front-load the main purpose and then detail the visual style. It is efficient without excessive verbosity, though the second paragraph somewhat restates the style rather than adding new behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter view tool, the description is fairly complete: it explains the visual outcome and mentions ligands are also styled. The presence of an output schema covers return values, so the description does not need to explain them. However, it does not address potential error conditions or whether prerequisites like an loaded object exist, but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter 'obj_name' with a clear description, and the schema coverage is 100%. The description does not add additional semantics for the parameter beyond what the schema already provides, so a 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures PyMOL for a 'textbook illustration' look, with a specific verb ('Configures') and resource (PyMOL style). It distinguishes itself from sibling view tools by describing the cel-shaded, illustrative style and specific visual elements, making its 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions it is 'ideal for presentations or textbook-style diagrams,' providing clear context for when to use this tool. It does not mention alternative tools or exclusions, but the usage context is sufficient for a style-specific view tool.
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 core behavior (one shown, all others hidden) and scoping to a selection, but does not mention side effects like whether this is reversible, affects camera, or applies to all objects. This is acceptable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose. Every word adds value with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two parameters, an output schema, and a clear core purpose. The description is sufficient for an agent to understand the tool's function, though it could benefit from a brief note about when to prefer 'as' over 'show'/'hide'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds no additional semantic detail beyond what the schema provides, hence the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource structure: 'Shows one representation while hiding all others for the specified selection'. This clearly distinguishes it from siblings like 'show' or 'hide' by describing the combined action of isolating a single representation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when you want to display exactly one representation for a selection. However, it does not explicitly mention alternatives or exclusions, though the sibling list includes related tools like 'show' and 'hide' that could serve similar purposes.
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 full burden. It discloses two behaviors: measuring the angle and drawing the measurement as a named object. However, it remains ambiguous whether the angle is returned as a value or only drawn, and it does not mention failure modes or prerequisites. Some behavioral context is provided, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the core measurement function, then adds the side effect and use cases. This is appropriately sized and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters all documented in the schema and an output schema exists, the description covers the essentials: purpose, unit (degrees), side effect (drawing), and example use cases. It does not explain return values (covered by output schema) or state dependence, but for a measurement tool it is substantially complete. A slight gap is the lack of mention about state or structure requirements, so a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself provides detailed parameter descriptions, including examples like 'For a backbone phi angle this is the preceding C.' The description adds no additional semantic meaning beyond what the schema already supplies, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool measures the dihedral (torsion) angle between four selections in degrees, which is a specific verb+resource. It distinguishes itself from sibling tools like angle (three selections) and distance by explicitly mentioning four selections and torsion angle. The added note about drawing a named dihedral object further clarifies its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool: 'Useful for backbone phi/psi angles and ligand torsions.' It does not explicitly state when not to use it or name alternatives, but the provided use cases effectively guide an agent toward appropriate scenarios. Lacks explicit exclusions, so a 4 rather than 5.
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 burden of behavioral disclosure. It adds crucial caveats: the model is colored by pLDDT confidence, pLDDT is stored in the B-factor column, and bfactor_view/putty_view will misrepresent the model. This goes beyond the basic schema by explaining interpretational pitfalls, though it does not cover session behavior or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs, front-loaded with the main purpose, followed by necessary caveats. Every sentence provides value: it explains the prediction nature, the color scheme, and the B-factor column issue, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and a well-detailed input schema, the description covers the conceptual context needed to interpret results correctly, including the expected coloring and view alternatives. It does not dive into operational details like session replacement, but the schema's 'replace' parameter handles that. The description is sufficiently complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with detailed descriptions, so the baseline is 3. The tool description does not add extra parameter semantics beyond mentioning UniProt accession, but the schema already handles this. No additional insight is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a predicted structure from AlphaFold DB by UniProt accession, which is a specific verb+resource+scope. It implicitly distinguishes itself from the sibling fetch_structure by focusing on AlphaFold predictions, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using plddt_view instead of bfactor_view or putty_view for viewing, which is useful context. However, it does not explicitly state when to use this tool versus alternatives like fetch_structure or load_structure, nor does it provide exclusions or when-not-to-use guidance.
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 of disclosure. It thoroughly describes the visual outcome: exact colors for amino acid categories, a white cartoon beneath a semi-transparent surface, and ligand rendering with yellow carbons. It does not mention reversibility or interaction with existing display styles, but the main behavioral effect is well specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the core purpose and then listing color mappings in a clear, scannable format. Every sentence adds specific visual information without unnecessary padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter visualization tool, the description covers the key visual outcomes and distinguishes the tool from numerous sibling views. It does not mention prerequisites like a loaded structure, but that is implied by the obj_name parameter. An output schema exists, so return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, obj_name, is already fully described in the schema with an example, providing 100% schema coverage. The description adds no extra parameter information, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Colors the molecular surface by amino acid hydrophobicity.' It clearly defines the tool's function and the detailed color mapping distinguishes it from other view tools such as electrostatic_view or bfactor_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a hydrophobicity-colored surface is desired) but provides no explicit guidance on alternatives or exclusions. It does not mention other view tools or state when not to use this visualization.
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 of behavioral disclosure. It thoroughly describes the visual output: color-coded atoms, H-bond dashes, residue sidechains, pocket surface, and backbone cartoon. However, it does not mention potential side effects (e.g., overriding existing representations) or prerequisites like a loaded protein structure, which would provide fuller transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose in the first sentence. It then systematically details the color legend and additional visual elements. Every sentence contributes meaningful information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is remarkably detailed for a visualization tool, covering all visual elements comprehensively. It implies interaction with a protein-ligand complex but does not explicitly state prerequisites or limitations (e.g., requirement for a protein chain). Given the output schema is likely trivial (success/failure), the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (resn, obj_name) are already documented in the input schema. The description adds no additional parameter-specific context beyond the schema, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Colors a ligand by pharmacophore feature type.' It provides a specific verb, resource, and distinct visualization details (color mappings, H-bonds, sidechains, pocket surface) that differentiate it from sibling view tools like ligand_view or bfactor_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for visualizing pharmacophore features but provides no explicit when-to-use guidance or comparison to alternative view tools. It does not name specific alternatives or state exclusions, leaving usage inference to the reader.
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 full burden. It clearly states the operation ('prints') and the resource ('current directory'), accurately reflecting the simple read-only behavior without hidden side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, succinct sentence that front-loads the core purpose. Every word is necessary; no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, expected output defined via output schema), the description is sufficiently complete. However, it does not mention output format (e.g., absolute path), but the existence of an output schema mitigates this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% trivially. The description adds no parameter info but is not required; baseline of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Prints the current directory' clearly states the tool's action and output, distinguishing it from related sibling tools like 'cd' (change directory) and 'ls' (list files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any context or prerequisites. For a simple utility, usage is implicit but the dimension explicitly requires 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?
With no annotations provided, the description carries the full transparency burden. It discloses several behavioral traits: no network/map/computation, reads published numbers, and warns about pre-2023 validation reports lacking Q-scores and Q-scores going negative. However, it does not mention that the tool overwrites B-factors, which is implied by the preserve_bfactors parameter and is a meaningful side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, leading with the primary purpose and then adding useful caveats in a clear list. Every sentence contributes meaningful information without fluff or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides substantial context for a tool with full schema coverage and an output schema. It explains data expectations and edge cases (older entries lacking Q-scores, negative values) that a user would need to interpret results correctly. The main gap is the unmentioned B-factor overwrite behavior, but overall the description plus schema gives an agent enough to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description does not add parameter-level meaning beyond the schema; it only repeats that the validation report is parsed. This meets the baseline for a fully documented schema but provides no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Colour a model by per-residue Q-score parsed from its wwPDB validation report.' It clearly distinguishes this from sibling visualization tools by emphasizing that Q-scores are read from a validation report, not computed or fetched from the network.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: 'No network, no map, and no computation — Q-scores are already published, and this reads the numbers rather than re-deriving them.' It implies when this is appropriate, though it does not explicitly name sibling alternatives or state when-not-to-use conditions.
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 must stand alone. It states the action but does not disclose boundary behavior (e.g., if on the first frame) or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, single action), the description fully covers what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so baseline is 4. The description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'goes back' and resource 'one frame', clearly stating the action and distinguishing it from sibling tools like 'forward' and 'frame'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for navigating backward in a frame-based context but provides no explicit guidance on when to use it versus alternatives or any exclusions.
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 disclosing behavior. It states that it counts and warns about empty counts, but does not explicitly say whether the operation is side-effect-free (e.g., it doesn't modify the scene). The read-only nature is implied but not stated, leaving a mild gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: three sentences total, with the first stating core functionality and the second/third providing a valuable use case. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and full parameter schema coverage, the description fully covers the practical usage scenario. The extra note about empty counts as a debugging hint makes it contextually complete for an AI agent deciding when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'selection' parameter as a 'PyMOL selection string to count' with 100% coverage. The description reinforces this by referencing selection expressions but does not add meaningful detail 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Counts') and resource ('atoms matching a selection'), clearly distinguishing it from sibling tools like select or remove. The additional explanation about checking selection expressions makes the purpose even clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly recommends using this tool to validate a selection expression before building a scene, providing clear context for when it is useful. It does not explicitly contrast with alternatives or state when not to use it, but the guidance is specific and actionable.
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 transparency. It discloses detailed visual behavior: thin grey cartoon, yellow sticks for cysteines, yellow dashes for disulfides, orange spheres for metals, dashed lines for coordination, and black background. This goes well beyond a basic summary, though it does not mention side effects or scene reset 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for a visualization tool, with the main purpose stated first and subsequent sentences providing specific visual details. Each sentence contributes useful information, though some minor redundancy exists (e.g., 'drawn as' repeated). Overall, it is well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description comprehensively covers the visual output, including colors, styles, and labeling. It does not mention potential side effects (e.g., whether it resets existing styles) or prerequisites, but the simplicity of the tool keeps those gaps minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a complete description for the single parameter obj_name ('PyMOL object name (e.g. 1abc)'), so schema coverage is 100%. The description does not add extra meaning about the parameter itself; it only elaborates on what will be visualized. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool highlights structural cross-links (disulfide bonds, metals, and their coordination), which is a specific verb+resource (highlights + cross-links). This distinguishes it from sibling view tools like interface_view or bfactor_view, making its 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool to visualize structural cross-links. While it does not explicitly name alternatives or exclusions, the purpose statement makes the usage obvious. This aligns with 'clear context, no exclusions' rather than merely implied usage.
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 of disclosing side effects. It explicitly mentions 'deep shadows, fog, depth-cueing', a 'dark background', and that 'Protein uses standard coloring but with altered material properties.' It does not describe reversibility or effects on other settings, but the main behavioral changes are transparently listed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences in two short paragraphs. The first sentence front-loads the primary purpose, while the next two add illustrative detail and material specifics. Every sentence earns its place with no repetition or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter configuration tool, the description covers the visual outcome, gives a concrete use case, and notes the change to material properties. It omits prerequisites (e.g., object must be loaded) or how to reset, but these are minor given the simple scope and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter 'obj_name' has a clear description ('PyMOL object name (e.g. "1abc")'). The tool description does not add any parameter-specific details 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Configures PyMOL for a depth-cued, cinematic look with dramatic lighting' — a specific verb, resource, and particular style. It distinguishes itself from sibling view tools by describing a unique aesthetic (shadows, fog, dark background), so there is no ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it 'emphasizes volume and scale' and is suited for 'massive complexes (like ribosomes or viral capsids)' to look dramatic. It does not explicitly name alternatives or state when not to use it, but the use case is well implied.
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. It discloses visual behaviors (B-factor spectrum, semi-transparent surface, cartoon beneath, sticks with yellow carbons) and the approximate nature of the electrostatics. It doesn't mention whether the coloring permanently alters the session or any prerequisites, but overall it provides substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a front-loaded purpose and only three short paragraphs. Each sentence adds value: the main function, the visual rendering details, and an alternative tool. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, visual output, and alternative, which is sufficient for a 2-parameter tool with a schema. It lacks explicit statements about state changes or limitations, but the behavioral details compensate for the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both mode and obj_name described in the input schema. The description does not add parameter-specific details beyond what the schema already provides, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Colors the molecular surface') with a defined method ('approximate residue-based electrostatics') and resource ('molecular surface'). It also differentiates from the sibling tool poisson_boltzmann_view by noting it is more accurate and requires additional software.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names poisson_boltzmann_view as a more accurate alternative, providing a clear when-not scenario. However, it does not address relationships to other view tools such as bfactor_view or hydrophobic_surface_view, so guidance is partial.
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 disclosure burden. It reveals important default behaviors: fetching the first biological assembly, removing unrelated chains/states, and applying pLDDT coloring for AlphaFold models. This goes beyond schema and helps the agent anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences. The first states the core purpose, the second explains the default multimer behavior, and the third covers AlphaFold routing with a pointer. No word is wasted, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the four parameters and an output schema, the description adequately covers purpose, default behavior, and routing. The main gap is the lack of explicit differentiation from load_structure, which is present in the sibling list and could lead to uncertainty about when to use each.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context by explaining how pdb_code routing works, but this largely mirrors the schema's field description. It does not add new semantic details for multimer_cutoff or the other parameters 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetches') and names clear resources (PDB and AlphaFold DB), with precise routing rules by identifier type. It effectively distinguishes itself from the AlphaFold-specific sibling by pointing to fetch_alphafold, and its scope is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: PDB codes fetch from PDB, while UniProt/AF- identifiers route to AlphaFold DB. It references fetch_alphafold as an alternative. However, it does not explicitly contrast with load_structure, which is a close sibling, so exclusion guidance is incomplete.
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 behavioral disclosure. It provides rich visual details (colors, surface patch, sticks, H-bonds within 4Å) that let the agent predict the output. It does not mention potential side effects like modifying existing representations or creating objects, but for a visualization tool this is a minor gap, and the description is otherwise transparent about what the user will see.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: a clear main purpose followed by two compact sentences of visual specifics. It is front-loaded and every sentence adds useful information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count and high schema coverage, the description is sufficiently complete. It explains both the purpose and the visual result, and the output schema presumably provides return details. It could mention prerequisites (e.g., both chains must exist in the same object), but this is not a significant gap for a simple view tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so baseline is 3. The description adds meaning beyond the schema by specifying that chain_a appears in marine blue, chain_b in salmon, and that interface residues are within 4Å of the partner chain. This helps the agent understand how the chain parameters are used in the visual output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Highlights the protein-protein binding interface between two chains,' which is a specific verb+resource statement. It clearly distinguishes this from sibling view tools like ligand_view, pocket_view, and bfactor_view by focusing specifically on the protein-protein interface between two chains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the purpose statement (use when you want to visualize an interface), but there is no explicit guidance on when to prefer this over alternatives like interface_report or contact_report. The description doesn't provide when-not-to-use or alternative suggestions, leaving the agent to infer context.
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 for behavioral disclosure. 'Lists' clearly signals a read-only operation, and the qualifier 'small-molecule (organic)' adds a meaningful constraint (excluding metals/ions). It doesn't describe return format or side effects, but the output schema covers return values, making this adequate for a simple list 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the purpose, the second gives usage guidance. Every sentence earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers purpose, usage context, and parameter semantics. The output schema exists to document return values, so the description doesn't need to explain them. It doesn't address edge cases like an object with no ligands, but those are not critical for this tool's basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter obj_name is already clearly described as 'Object to inspect for organic ligands.' The tool description adds no additional parameter-specific meaning, so it sits at the baseline score for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Lists' and targets a clear resource: 'small-molecule (organic) ligand residue names in an object.' It explicitly differentiates from sibling listing tools like list_objects and list_chains by focusing on ligands, and it even names the downstream view functions it supports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'Call this before ligand_view, pocket_view, or pharmacophore_view when you don't already know the ligand's 3-letter residue name.' This gives a clear usage context, though it doesn't discuss when not to use it or mention alternatives, so it doesn't earn a 5.
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 behavioral disclosure. It discloses the color scheme (blue/white/red), the display mode (cartoon), and background (black), which are the key behavioral traits. It does not mention potential side effects like overwriting existing colors, but the view-tool nature and description are sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: it states the purpose, explains the color legend, gives use cases, and notes the display style. It is front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter visualization tool with an output schema present, the description is complete. It covers purpose, visual interpretation, applications, and rendering details, which is all the agent needs to decide on 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the sole parameter obj_name is already well-documented in the schema. The description adds no additional information about the parameter, so it does not exceed the baseline of relying on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Colors') and resource ('the structure by crystallographic B-factor'), immediately distinguishing it from sibling view tools like plddt_view or conservation_view. The naming and details about color mapping remove ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('identifying dynamic loops, disordered termini, and rigid structural cores'), giving the agent context for when to invoke this tool. It does not explicitly mention when-not-to-use or name alternative tools, but the specificity of B-factor makes the intended scenario 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?
No annotations are provided, so the description carries the full burden. It transparently describes a read-only operation ('Lists') with no side effects, and clarifies scope ('in an object (or in all objects)'). While it doesn't disclose error handling or output format, the tool's simplicity limits the need for more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core function, and the second adds a practical use case. It is concise, front-loaded, and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter list tool with an output schema, the description fully covers purpose, parameter semantics, and usage context. It even hints at the default behavior, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since obj_name already includes 'Object to inspect. Defaults to every loaded object.' The tool description adds no new semantic detail beyond reiterating the default behavior ('or in all objects'), so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Lists the chain IDs present in an object (or in all objects).' The verb 'Lists' and resource 'chain IDs' make the purpose explicit, and it distinguishes itself from sibling tools like list_objects or list_ligands by focusing on chain IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Useful before calling interface_view, conservation_view or any tool that needs a specific chain ID.' This provides clear usage context, though it does not mention alternatives or 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it discloses failure behavior ('header is parsed before PyMOL is touched... malformed file fails without leaving a half-loaded object'), the 'load is confirmed rather than assumed' behavior, and the provenance default of 'unknown' with no inference. This is rich, specific behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, but the second paragraph on provenance is somewhat verbose and philosophical. Each sentence adds value, though a more compact explanation could achieve the same effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a modest 3-parameter schema and an output schema, so little return-value documentation is needed. The description covers error handling, provenance semantics, and reporting behavior, making it fully adequate for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with 100% coverage, including descriptions for path, name, and provenance. The description adds rationale for the provenance default but no new parameter-level semantics, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Load a volume into PyMOL, recording where it came from and reporting its geometry,' which names a specific verb, resource, and distinct purpose. It clearly differentiates from sibling tools like load_structure by focusing on volume maps rather than atomic structures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes the tool is for loading volumes into PyMOL, and the provenance discussion explains how callers should think about declaring provenance. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It details that a separate `<obj>_spine` object is created, loop cartoon is hidden, the spine threads through strand bodies, and the two objects fuse into one watertight solid for export. It also explains the spine acts as internal rebar. This is rich, non-obvious behavior that goes well beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but structured: opening summary, mechanism explanation, and a code block for the next step. Each sentence contributes useful context about the 3D-printing design. It is not overly verbose, and the structure aids comprehension. The code block is a helpful formatting choice for the follow-up step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (per context signals), the description covers the complete workflow: what the tool does, why it is needed, how the objects fuse, and the exact export command. It is self-contained and leaves no critical gaps for a user intending to prepare a printable PDB visualization.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds contextual background (e.g., the spine acts as rebar) but does not add new parameter syntax or meaning beyond the schema. The schema already explains the radius and its default; the description's extra detail is tangential rather than directly illuminating parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: "Chunky β-arrow ribbons plus a continuous backbone 'spine', tuned for rigid, gap-free 3D printing." It clearly distinguishes this from sibling view tools by focusing on 3D printing preparation, and it explicitly names the companion tool (print_export) needed to complete the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: it configures the look for FDM printing and then instructs to export with print_export. It implies when to use it (before print_export) but does not explicitly state exclusions or alternatives. The workflow statement "After calling this, export the fused solid with: print_export(...)" gives practical guidance, but lacks a direct 'use this instead of X' comparison.
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. It discloses that the tool mutates the object's B-factor column and explains the mechanism: originals are stashed first and then restored in one pass. It stops short of detailing edge cases like what happens if no stash exists, but the disclosure of the mutation and stash mechanism is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary action front-loaded in the first. The second sentence earns its place by naming the three relevant sibling tools and explaining the stash mechanism, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter utility that has an output schema, the description covers the core functionality, the triggering conditions, and the mechanism. It could mention the no-stash edge case, but given the straightforward nature of the tool and strong context, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single obj_name parameter, so the baseline is 3. The schema's description already specifies 'PyMOL object whose original B-factors should be put back.' The tool description adds no additional parameter-level details, but given the full schema coverage, this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Restore the B-factors a Wiggles view overwrote,' which clearly identifies the action (restore), the resource (B-factors), and the context (overwritten by a view). It then names the three specific sibling tools (occupancy_view, ensemble_spread_view, qscore_view) that cause the overwrite, making it unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: after any of the three named views have pushed their values into the B-factor column. It also implies the alternative (use the views to visualize, use this to restore the original data), so there is no ambiguity about the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It thoroughly explains the computation (per-residue RMS deviation), the effect (B-factor column overwritten, blue-to-red spectrum coloring, tube thickness), and the interpretive caveat. This goes well beyond minimal 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loaded with the main action followed by technical detail and a caveat. Every sentence earns its place: the action, the computation, and the crucial interpretation warning. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity, and the description covers the computation, visual output, and scientific interpretation. It also includes a necessary caution about the metric's meaning. While it does not mention restoring B-factors, it provides enough context 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters. The description adds context about the overall behavior but does not elaborate on parameter syntax or semantics 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Colour and thicken a multi-state object by how much its states disagree.' This clearly identifies the tool's action and target, and distinguishes it from siblings like conservation_view or bfactor_view by focusing on inter-state disagreement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for multi-state objects and explicitly states what the spread is NOT (calibrated uncertainty/error bar), providing a when-not-to-use caution. However, it does not name alternative tools or explicitly explain when to choose this over a sibling, 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.
Behavior4/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 useful context about the PyMOL 'cmd.do' mini-language and explicitly says 'not Python', preventing misuse. It also hints at lower-level behavior via 'raw' and 'better defaults'. However, it does not explicitly mention potential side effects or error behavior, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by usage guidance and a technical note. Every sentence serves a purpose with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter raw execution tool, the description is exceptionally complete: it states the operation, gives conditional guidance with examples, and clarifies language syntax. The output schema exists, so return-value details are not needed. It fully covers how an agent should decide to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already describes the parameter with an example and the Python exclusion. The tool description adds multi-statement script mention as a usage hint, but it does not materially extend parameter semantics beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction ('Executes a raw PyMOL command string') and is clear about the tool's role as a fallback, distinguishing it from the dedicated sibling tools (show, color, select, etc.) with explicit examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to 'PREFER the dedicated tools' and provides concrete when-to-use and when-not-to-use scenarios, including examples like `set ray_shadow, 0` and multi-statement scripts. It clearly excludes common cases and names alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 thoroughly discloses the visual behavior: protein cartoon, pocket residue stick style and coloring, ligand thick sticks, H-bond yellow dashes, residue labels, and auto-zoom. This is comprehensive for a read-only view 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, immediately states the main purpose, and then provides compact, information-dense details about the visualization. No filler or redundancy; every detail serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters and an output schema, the description fully covers what the tool does and what the visual result will be. It explains the rendering, labeling, and zoom behavior, giving the agent complete expectations for the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are already fully described in the input schema (100% coverage). The description does not add new syntax or format details for obj_name or ligand_resn, but does reinforce that ligand_resn identifies the ligand and that pocket residues are selected by 5Å proximity. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Shows a binding-site view focused on a ligand' with a specific verb ('Shows'), resource ('binding-site view'), and scope ('focused on a ligand'). It clearly distinguishes from sibling view tools by emphasizing the ligand-centric visualization and providing detailed rendering specifics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for visualizing a ligand binding site, including pocket residues and H-bonds. However, it does not explicitly mention alternatives or state when not to use it, so it falls short of a full 5.
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 provided. Description states read-only behavior implicitly ('lists'). No side effects disclosed, but no hidden actions either. Simple and accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Purpose first, then usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and existence of output schema, description fully covers purpose and usage. No missing context for agent decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema covers everything. Baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'lists all loaded PyMOL objects'. Distinct from sibling tools like list_chains and list_ligands which list subcomponents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call (when you don't know session contents) and provides example usage before other tools. Lacks explicit when-not, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the header-only behavior, the voxel-size derivation trap (cella/m vs cella/n), the ±5–15% accuracy caveat, and that anisotropy, cropping, and axis permutation are flagged. This is rich, honest behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose. The subsequent sentences about safety and the derivation trap are all substantive and earn their place, making the length justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the core purpose, the safety model, a critical derivation trap, and the flags returned. There is no indication of missing needed context, and the output schema presumably covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, path, and the schema already describes it fully (file extensions and gzip support). The description adds no new parameter-level information, so the baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Report an MRC/CCP4 map's geometry, above all its voxel size' — a specific verb and resource. It clearly differentiates this tool from siblings like load_map or density_view by focusing on extracting header-derived geometry without touching the map data or PyMOL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Reads only the 1024-byte header... PyMOL is never touched, and nothing goes over the network,' which provides clear context about when to use this lightweight reporting tool. It does not explicitly name alternatives or exclusions, but the usage context is strongly implied.
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 provided, so the description carries the full burden of behavioral disclosure. It does an excellent job of stating exactly what will be rendered: magenta sticks for mutated residues, grey sticks for nearby residues, grey cartoon for backbone, and yellow sticks for ligands. It also documents the mutation format and side-chain representation. However, it does not explicitly state whether this command mutates existing view state or creates a new object, nor does it mention error handling for invalid mutation strings, which prevents a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. The first sentence states the core purpose, followed by a compact but complete paragraph detailing visual styling, and a separate 'Mutation format' section for syntax. There is no redundant prose; every sentence contributes necessary operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a visualization tool with a rich output schema (indicated by context signals) and full schema parameter coverage, the description is remarkably complete. It specifies input format, examples, rendering rules for mutated and nearby residues, ligand highlighting, and structural context. Nothing critical is missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters ('obj_name' and 'mutations'), so schema coverage is 100%. The description adds substantial semantic value by detailing the mutation notation ('<wildtype_aa><resi><mutant_aa>'), giving concrete examples, explaining the optional chain prefix format ('A:A123G'), and describing how the mutations parameter maps to the visual output. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource statement: 'Highlights mutated residues on the protein structure.' It then enumerates the specific visual representation (magenta sticks, labels, nearby residue context, cartoon backbone, ligand rendering), which fully distinguishes it from sibling view tools like conservation_view or bfactor_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the primary usage context obvious: it is for visualizing a specified list of mutations on a protein structure. It provides detailed input format examples ('A123G,V45L,T200S') and optional chain prefixes, giving clear practical guidance. However, it does not explicitly discuss when not to use this tool or mention alternatives such as conservation_view or mutation-specific analysis tools, 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.
Behavior4/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 color palette thresholds, the storage of pLDDT in the B-factor column, and the interpretive caution for regions below 70. It does not mention side effects beyond coloring, but this is likely a single-purpose visualization 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence front-loads the purpose; subsequent sentences provide essential details (palette, threshold interpretation, and comparison to alternatives). Every sentence adds unique value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter coloring tool, the description covers what it does, the exact color thresholds, and when it should replace competing tools. The presence of an output schema means return values need not be described. It is complete for the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with obj_name described as 'PyMOL object name (e.g. "AF_P69905").' The description adds no new parameter-specific details beyond reinforcing the AlphaFold context, so the baseline of 3 for full schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Colors an AlphaFold model by pLDDT confidence, using the official palette.' It clearly distinguishes from siblings by explicitly naming bfactor_view and putty_view as tools that handle these models incorrectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this instead for predicted models.' It also explains why alternatives fail ('they assume low = rigid, whereas low pLDDT = low confidence'), establishing clear exclusion criteria.
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 provided, so the description carries the full burden. It distinctly states that the operation is permanent and not merely a visual hide, which is a crucial destructive behavior. It doesn't mention other possible side effects, but the core irreversibility is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and each sentence adds value. No redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter deletion tool, the description covers the essential behavior, the contrast with hide, and the irreversible nature. Together with the schema and 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a full description of the selection parameter ('Atoms to delete permanently. To hide them instead, use hide.'), and the tool description adds no new parameter-level details. With 100% schema coverage, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool permanently removes atoms matching a selection, using a specific verb and resource. It explicitly contrasts with hide, which helps distinguish it from a key sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear alternative: use hide if you don't want permanent deletion. It also implies when to use: when atoms should be permanently removed rather than hidden.
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 transparency burden. It states that the session captures every object, selection, representation, color, scene, and camera, and preserves the full visual state. It doesn't mention whether an existing file is overwritten or what the return value is, but the core behavioral scope is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences: the first states the action, the second explains why and when to use it, and the third contrasts with 'save.' Every sentence contributes value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a well-described schema and an output schema, the description is complete: it explains the full scope of the session capture, gives practical use cases, and explicitly distinguishes the tool from the related 'save' command. No important behavioral or usage details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the only parameter fully, including that a .pse extension is added if missing. The tool description reinforces that the output is a .pse file but adds no additional parameter-level meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Saves the entire PyMOL session to a .pse file.' It clearly differentiates from the sibling tool 'save' by noting that save writes bare coordinates while this preserves the whole visual state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use before experimenting with a scene you might not want to rebuild, and to hand a finished figure to a colleague. It also names 'save' as the alternative for bare coordinates, giving clear when-to-use versus when-not-to-use context.
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 provided, so the description carries the full burden. It discloses that metadata lookup is 'best-effort' and 'skipped silently' when the object is not named after a PDB entry or the API is unreachable. This is a meaningful behavioral trait beyond what the name implies. It also clarifies that it combines PyMOL state with RCSB metadata, which sets expectations for output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary, a paragraph detailing what it answers and combines, and a final paragraph on limitations. Every sentence adds useful information, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool does, what input it expects, and how it handles edge cases (unreachable API, non-PDB-named objects). With an output schema present, the lack of explicit return-value documentation is acceptable. This is complete for a summary tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds value by explaining the purpose of pdb_id as a fallback when the object name no longer matches the PDB entry, and provides an example for obj_name ('1hsg'). This extra context helps select and fill parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Summarises what a loaded structure actually is, in one call.' This is a specific verb ('summarises') plus a specific resource ('loaded structure') and scope ('in one call'). It distinguishes itself from sibling tools that perform more targeted queries (e.g., list_chains, atom_properties) by offering a holistic summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Answers the question you ask before any analysis.' This implies it should be used as an initial inspection step. It does not explicitly name alternatives or exclusions, but the one-call summary framing effectively contrasts with more focused sibling tools.
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 provided, so the description carries the full behavioral burden. It discloses that properties are evaluated by PyMOL per atom and accepts iterate expressions, which is useful operational context. It also hints at a technical limitation ('returns an object that cannot cross the bridge'). However, it does not mention potential cost (e.g., slow for large selections) or details about the result format, though the output schema likely covers the latter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence, a differentiation paragraph, usage examples, and a technical note. It is a bit longer than strictly necessary—some repetition of the 'cannot reach/other route' idea—but every paragraph serves a purpose and the content is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity, an output schema exists, and no annotations, the description is exceptionally complete. It covers purpose, alternative tools, concrete use cases, and parameter semantics. The only minor gaps are performance/return details, but those are either in the schema or not critical for a read operation. This matches the high end of the calibration examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that the 'properties' parameter is a PyMOL iterate expression and provides a list of common properties. It also gives guidance on narrowing the 'selection'. This goes beyond the schema's short field descriptions, especially for 'properties', which could otherwise be ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Reads per-atom properties.' It immediately distinguishes itself from siblings by stating 'nothing else in the tool set can reach' and contrasts with object-level and per-residue tools. This makes the 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names alternatives: 'Object-level facts come back through structure_info and list_chains, and per-residue values through get_sequence or the view presets.' It then provides concrete use cases ('partial occupancy...', 'per-atom pLDDT...', 'formal charge...'). This clearly tells the agent when to choose this tool and when other routes are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals that PyMOL levels are in sigma, that absolute levels are converted before reaching PyMOL, that EMDB depositions get a pointer with units named, and that the level is always reported in both units. This rich detail goes well beyond a basic 'draws a mesh' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the main action, the problem it solves, and the operational requirement. It is dense but not bloated, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description doesn't need to detail return values. It covers the core behavior, unit conversion, and the load_map prerequisite. Minor gaps include explicit error handling if the map is not loaded correctly, but overall it is sufficiently complete for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics for 'level' and 'units' by explaining the sigma/absolute distinction, conversion, and what happens when 'level' is omitted (1.5 sigma generic). This adds value beyond the schema's simple parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Draw an isomesh around a selection, stating the contour level in both units,' which is a specific verb+resource statement. It also uniquely highlights the dual-unit reporting, distinguishing it from sibling tools like isomesh and isosurface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the prerequisite: 'Requires the map to have been loaded through load_map' and explains why. It also provides context about the sigma vs absolute discrepancy with EMDB, but it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It explains the computation technique (comparing solvent-accessible area free and bound), the ranking by buried surface, and the chemistry breakdown. It also communicates interpretive caveats ('These are guides... not a verdict'), which is useful behavioral context beyond basic read-only implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear lead sentence, a method paragraph, interpretation guidance, and a pointer to a sibling tool. It is somewhat longer than minimal but every sentence contributes value: measurement definition, output details, thresholds, caveat, and alternative. Front-loaded with the main purpose, so it is effective without being wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description is complete. It explains what is measured, how (SASA comparison), what is reported (buried surface area, residue ranking, chemistry), and how to interpret the numbers. It also directs users to contact_report for specific interaction details, covering the necessary context for correct invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds context about the overall method (SASA comparison) but does not add meaning beyond the schema for individual parameters like chain_a, chain_b, or max_residues. It does not repeat or enrich parameter details, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Measures how large a protein-protein interface is, and which residues form it.' It clearly distinguishes itself from the sibling tool contact_report by explicitly directing users there for hydrogen bonds and salt bridges. The method (buried surface area comparison) and outputs (residue ranking, chemistry breakdown) are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: it gives numerical interpretation thresholds (under ~400 A^2 suggests crystal packing, over ~1000 A^2 suggests a specific association) and states that for interaction pairs (hydrogen bonds, salt bridges) one should 'use contact_report on the same two chains.' This offers an alternative and helps decide when to use this tool versus a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 proactively reveals two hidden complexities: grid mismatches are checked and reported, and Ångström breakpoints are converted to sigma relative to the resolution map's header. It also cautions that local-resolution estimates are inherently uncertain, giving the agent crucial expectations about reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a concise one-sentence summary followed by necessary technical caveats. It is somewhat verbose, especially the illustrative analogy about a rigid core versus flexible periphery, but the added details are substantive and not mere padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no annotations) and the presence of an output schema, the description covers the essential non-obvious failure modes: voxel-grid compatibility, sigma conversion, and the uncertainty of local-resolution estimates. It leaves return-value documentation to the output schema, which is appropriate, and gives an agent enough context to use the tool safely and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 11 parameters, so the baseline is 3. The description adds valuable semantic context beyond the schema by explaining the relationship between `map_obj` and `res_obj` grid requirements, and by clarifying how `level`, `units`, and `breaks` relate to sigma scales in the two maps. This helps an agent reason about parameter interactions without repeating every field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a precise action and target: 'Colour a map's isosurface by a local-resolution volume instead of by chain.' This clearly identifies the tool's function and differentiates it from generic isosurface or chain-based coloring, making the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong contextual guidance by explaining why a global resolution number is misleading and when local-resolution coloring is valuable. It does not explicitly name alternative tools or list 'when not to use' exclusions, but the intended use case is clear enough for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses that the tool refuses ill-posed interpolations, runs a topology check even when interpolation is unavailable, and supports validate-only mode. This is rich, honest behavioral context that goes beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise purpose statement, a rationale paragraph, and an important availability note. It is slightly verbose (~100 words) but each sentence contributes meaningful context, earning a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is remarkably complete despite lacking annotations. It explains purpose, valid use cases, limitations, and even open-source behavior. An output schema exists to handle return-value details, so no essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds high-level context about topology and refusal, which indirectly relates to obj_name and validate_only, but does not explicitly detail parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Interpolate between states, refusing when interpolation is ill-posed' clearly states the action and resource. It distinguishes itself from native PyMOL morphing by emphasizing the topology-check refusal, setting it apart from sibling tools like align or intra_fit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when morphing is valid (shared topology, e.g., deformation-model ensembles) and when it is not (independently modelled volumes). It also mentions the Incentive-only limitation and the behavior on open-source PyMOL, providing clear guidance on constraints and expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses the external MMseqs2 API call, potential 30-second-to-minutes latency, in-memory caching by sequence, the effect on B-factor and spectrum coloring, and the color-mapping semantics. This is far beyond minimal and gives the agent a realistic expectation of side effects and performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is paragraph-structured but each sentence earns its place: purpose, pipeline, caching, color mapping, and a latency note. It is front-loaded with the primary function, remains readable, and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (external API, caching, B-factor modification) and the existence of an output schema, the description covers all critical aspects: the full pipeline, the color interpretation, performance expectations, and caching behavior. It leaves no major operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, providing a baseline of 3. The description adds value by explaining that changing the scale does not trigger a new API call and that re-runs are cached, which directly informs understanding of 'scale', 'force_refresh', and 'server_url'. This extra context justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource statement: 'Colors the structure by evolutionary conservation using Shannon entropy.' This explicitly distinguishes it from sibling view tools like bfactor_view or plddt_view, and the detailed pipeline further clarifies its unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (for evolutionary conservation coloring) and includes practical usage guidance about the first-call latency and caching. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full exclusion guidance.
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. It discloses that the default action replaces the current session, merge adds objects, and warns about collisions. It doesn't mention error handling or file existence checks, but the key behavioral traits are clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: an opening sentence states the core purpose, followed by a detailed but efficient explanation of the default and merge behavior. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool, the description covers essential usage, behavioral nuances, and a practical example. An output schema exists, and the description need not explain return values. It is complete for selecting and invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the default false behavior of merge and clarifying the collision risk, which goes beyond the schema's 'Add to the current session rather than replacing it.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool restores a PyMOL session from a .pse file, using a specific verb and resource. It distinguishes itself from sibling tools like load_structure by explicitly mentioning session restoration and .pse files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the default behavior (replace current session) versus merge=True (add objects), including a real-world scenario (two saved scenes side by side). It also warns about name collisions, which is excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: it explains per-colour-group STL isolation, the OBJ exporter's behavior, coordinate-frame alignment, method selection, and missing-library handling. It even clarifies representation-mode differences, providing rich, non-obvious behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds a distinct piece of information: purpose, grouping behavior, underlying exporter rationale, alignment for slicers, and dependency requirement. It is front-loaded with purpose and contains no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 7 parameters and no annotations, the description covers prerequisites, method behavior, representation modes, and output alignment. An output schema exists, so return-value details need not be in the description; this tool is fully contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds value beyond the schema by explaining why groups are isolated, how slicers can align them, and how method choices affect output, supplementing but not replacing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+output: exports a structure as watertight STL files for multi-colour 3D printing. It clearly distinguishes this from generic save/png/render siblings by specifying STL format and the multi-colour printing 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence establishes the specific use case (multi-colour 3D printing) and the optional print extra prerequisite is stated. It doesn't explicitly name sibling alternatives to avoid, but the unique format and workflow make the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the critical behavioral trait that it does not move anything, implying a non-destructive operation. It also explicitly mentions the constraints (matching atom counts) and differentiates from mutation-like tools (align/super), making side effects and scope clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient, starting with the core action and immediately clarifying the non-mutating nature. It then provides usage context and compares with siblings in a compact way. Every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the output schema, and the rich sibling context, the description is complete: it covers purpose, usage conditions, exclusions, and the critical atom-count prerequisite. It fully explains what the tool does without needing to describe return values since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('First selection', 'Second selection, same number of atoms'). The main description adds the context that both selections must have matching atom counts, which slightly supplements the schema, but it does not explain selection syntax or ordering details. This is baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool measures RMSD between two selections without moving anything, which is a specific verb+resource. It distinguishes itself from sibling tools align, super, and superposition_view by emphasizing it does not alter the structure and only reports the current distance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: use when structures are already superposed or to know the current positional difference. It names alternatives (align, super for minimization, superposition_view for visual analysis) and states the requirement of matching atom counts, giving clear when-to-use and when-not-to-use context.
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 burden of disclosing behavior. It reveals that SASA is computed in the context of the parent object, which is not obvious from the schema, and notes accuracy dependence on PyMOL settings dot_solvent and dot_density. Missing explicit statement about read-only nature, but the description provides substantial behavioral context for a measurement 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the core function first, then the key nuance, the alternative, and the accuracy dependencies. Each of the four sentences adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple measurement tool with an output schema and only two well-documented parameters, the description covers the essential aspects: purpose, contextual behavior, alternatives, and dependencies. It is complete for an agent to decide when and how to invoke the tool, and the output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning by explaining that the selection is measured in the context of its parent object, which clarifies the selection parameter's semantics beyond the schema. It does not elaborate on the state parameter further, but the schema already covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool measures solvent-accessible surface area in square Angstroms, with a specific verb and resource. It also distinguishes itself from the sibling tool interface_report by explaining the context-dependence of the measurement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool vs alternatives: for unbound measurements, it advises using create or interface_report. It clearly states the scenario where sasa is appropriate (measuring in context of the object) and when to choose an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 every frame is ray-traced and slow, that the ray_trace option is ignored, and that the unshaded OpenGL renderer silently produced blank frames in this environment. This is thorough and honest about limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise paragraphs: purpose, method, and performance/alternative. Each sentence earns its place, with no redundancy. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, full schema coverage, an output schema, and no annotations, the description is remarkably complete. It covers the output format, performance characteristics, and known issues, leaving no critical gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds some context (e.g., prefix pattern and ffmpeg usage) but does not significantly enhance per-parameter meaning beyond what the schema already provides. The schema descriptions are already detailed, so the description's added value here is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Renders a full 360° rotation as a numbered PNG sequence.' It clearly distinguishes itself from sibling tools like 'turn' or 'rock' by focusing on producing a frame sequence for GIF/MP4 assembly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: to create a rotation sequence for GIF/MP4. Provides an alternative (OpenGL renderer) and why it's not used (does not work over the bridge), plus performance guidance to start with few frames and small dimensions. This is clear usage context.
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 full responsibility for behavioral disclosure. It clearly states the tool operates on the editor pick rather than a selection and explains a common failure mode. However, it does not explicitly describe side effects (e.g., structure modification) or reversibility, though the operation is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. The first sentence provides the core purpose, the second details usage constraints and a pitfall, and the third names the alternative tool. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully explains the tool's unique requirement (editor pick), prerequisite (atom picked in GUI), a common error, and the alternative tool for selection-based additions. Since an output schema exists, return values need not be explained. This is complete for a simple utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is an empty object (100% coverage baseline is 4). The description adds valuable context by stating that it takes no selection and explaining that passing a selection would incorrectly land in the quiet argument and fail. This goes beyond the empty schema, earning a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool fills open valences on the currently picked atom with hydrogens, a specific verb+resource. It also explicitly distinguishes itself from the sibling h_add tool, which adds hydrogens to a selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (requires an atom picked in the GUI, takes no selection) and directs users to h_add for selection-based additions. It also warns about passing a selection causing a specific error, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 openly states the tool relies on heavy-atom distance criteria, elaborates on the lack of hydrogens, and cautions that hydrogen bonds are 'plausible geometry' rather than verified. It also explains the default exclusion of water. This is richly transparent behaviorally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but information-dense, front-loaded with the main action, then distinguishing context, use cases, and technical criteria. Each sentence earns its place, and the structure flows logically from what to when to how. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of a rich output schema, the description covers all necessary aspects: purpose, alternatives, parameter semantics, classification details, and limitations. It is completely adequate for an agent to select and invoke the tool correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how the cutoff relates to the classification thresholds (e.g., '4.0 captures the interactions above') and by explaining why include_water defaults to off. However, most parameter details are already well covered in the schema, so this is a modest enhancement rather than a full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Lists the residues in contact across two selections, with distances and types.' It clearly distinguishes itself from sibling tools by calling itself the 'numeric counterpart to ligand_view and interface_view' and provides concrete use cases. This fully satisfies purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with drawing tools: 'instead of drawing the interactions, it reports them' and names the alternatives. It also gives question-based use cases ('what holds this ligand in the pocket') and explains the classification criteria, which helps the agent decide when this tool is appropriate. This is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility, and it delivers thoroughly. It discloses the coloring gradient (blue-white-red), that the target is left grey, residue pairing logic by chain and number with fallback, and the multimer pitfall with a specific numeric illustration (4AKE vs 1AKE). It also explains the meaning of max_deviation in the workflow. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for its complexity. Each sentence adds necessary information: the core purpose, the rationale versus RMSD, the coloring mechanism, usage scenarios, pairing rules, and crucial caveats. It is well-structured, starting with a clear statement and then expanding into practical details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with visual output and multiple parameters, but the description covers all essential aspects: the operation, coloring logic, pairing behavior, prerequisites, and edge cases. It even gives a concrete example to illustrate the multimer issue. An output schema exists, so return-value documentation is not required. The description is complete enough for an agent to use the tool correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the max_deviation behavior (defaults to largest observed shift, set explicitly to compare pairs) and implying how mobile/target relate via the superposition concept. However, it does not fully elaborate on method choices; still, the schema already provides clear field descriptions, so the added semantic context is a bonus.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource combination: 'Superposes two structures and colors the mobile one by per-residue shift.' It clearly distinguishes this from sibling tools by explaining that it provides per-residue visualization rather than just an RMSD number, and the explicit mention of 'mobile onto target' and coloring scheme establishes a unique identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when the tool is best used: 'Best on two states of the same protein — apo vs holo, open vs closed, a mutant against wild type.' It also provides critical practical guidance: both structures must be loaded, warns about fetch_structure clearing the session, recommends replace=False, and cautions against multimers with a concrete example. This goes beyond simple context to include exclusions and workarounds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses ray_trace=False is ignored and why (GUI thread issue, blank images), describes filename cleanup behavior, and warns about ray-tracing performance. This is rich behavioral context beyond any structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Adequately sized with front-loaded purpose; all three paragraphs contain necessary information—purpose, usage guidance, and behavioral caveats—with no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a complex rendering tool: clarifies purpose, gives usage context, discloses limitations, and addresses parameter semantics. Without an output schema, it still states 'returns the image, so you can see it,' satisfying return-value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant meaning: explains ray_trace is a no-op, clarifies filename behavior (temporary vs kept), and links width/height to render speed via 'Render smaller to render faster.' This exceeds the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Renders the current scene and returns the image.' It explicitly distinguishes from siblings by saying 'Use this instead of calling ray and png separately,' making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use: 'Call this after setting up a view to check what it actually looks like, and iterate.' It names alternatives (ray, png) and explains why this tool is preferable, fulfilling the when-not and alternative guidance.
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:

[![MCPymol MCP server](https://glama.ai/mcp/servers/chemrich/MCPymol/badges/card.svg)](https://glama.ai/mcp/servers/chemrich/MCPymol)

Score Badge

Copy to your README.md:

[![MCPymol MCP server](https://glama.ai/mcp/servers/chemrich/MCPymol/badges/score.svg)](https://glama.ai/mcp/servers/chemrich/MCPymol)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/chemrich/MCPymol'

If you have feedback or need assistance with the MCP directory API, please join our Discord server