Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Rosetta MCP Server relax my protein using FastRelax"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Author: Ariel J. Ben-Sasson
A Model Context Protocol (MCP) server that lets Cursor (or any MCP client) work with Rosetta, PyRosetta, and Biotite: run RosettaScripts, validate XML protocols, translate between Rosetta and Biotite, score structures, and query documentation -- all from your AI coding assistant.
rosetta_to_biotite -- Find the Biotite equivalent of any Rosetta function with working example code (21 mappings covering structure I/O, SASA, RMSD, superimposition, secondary structure, contacts, hydrogen bonds, B-factors, angles, and more)
biotite_to_rosetta -- Reverse lookup: find the Rosetta equivalent of a Biotite function
translate_rosetta_script_to_biotite -- Translate entire RosettaScripts XML or PyRosetta code to Biotite Python. Design/optimization operations are flagged as Rosetta-only.
Fuzzy search with keyword aliases ("contacts", "binding energy", "surface area", "align", etc.)
37 element types supported (was 6): 11 movers, 9 filters, 10 selectors, 7 task operations
Full attribute handling: repeats, disable_design, cartesian, tolerance, threshold, distance, and more
Child element support: MoveMap (with Span), Reweight, ScoreFunction
Reports unrecognized elements so you know what needs manual work
get_rosetta_help now accepts any topic: movers by name ("FastRelax"), concepts ("constraints", "docking"), or score functions ("ref2015") -- auto-fetches live docs from rosettacommons.org
search_rosetta_web_docs fallback: when DuckDuckGo is rate-limited, probes direct Rosetta docs URLs
get_cached_docs auto-caches: no need to call cache_cli_docs first
Expanded static help for score_functions, movers, filters, xml, and parameters
pyrosetta_score: new per_residue option returns per-residue energy breakdown
scorefxn parameter now works (was ignored in v1.1.8)
Proper error messages for missing files instead of silent {}
validate_xml: new validate_against_schema option checks element names against the Rosetta XSD schema (catches typos like FastRleax)
tools/call responses now use correct { content: [{ type: "text", text }] } format
Tool errors return isError: true (not JSON-RPC errors)
Standard JSON-RPC error codes (-32601, -32700, -32603)
Removed false resources capability advertisement
User input no longer interpolated into Python code (uses env vars / stdin)
Temp files written to os.tmpdir() (not module directory)
Removed 3 redundant tools: list_functions (merged into get_rosetta_info), search_pyrosetta_wheels, cache_cli_docs (auto-cache in get_cached_docs)
Removed hardcoded personal paths
Fixed shadowed variables, async anti-patterns, dead code
18 tools (was 21), all with improved agent-oriented descriptions
Related MCP server: gget-mcp
This is what makes the MCP server powerful -- an AI agent can answer domain questions by calling the right tools automatically:
User asks in Cursor: "How do I relax my protein and what's the Biotite equivalent?"
The agent calls two MCP tools behind the scenes:
1. get_rosetta_help("FastRelax") returns 6000+ chars of live documentation:
FastRelax performs all-atom relaxation using the FastRelax protocol. Parameters include
scorefxn,repeats,cartesian,disable_design,MoveMapconfiguration...
2. rosetta_to_biotite("FastRelax") returns:
{
"found": true,
"results": [{
"rosetta": { "name": "FastRelax", "example": ["relax = FastRelax()", "relax.set_scorefxn(get_score_function('ref2015'))", "relax.apply(pose)"] },
"biotite": null,
"equivalence": "none_from_biotite",
"notes": "Biotite does NOT perform structure optimization. These are Rosetta-specific capabilities."
}]
}The agent synthesizes: "FastRelax is Rosetta's all-atom relaxation protocol. Here's how to use it... Note: Biotite is analysis-only and has no equivalent -- you need PyRosetta for structure optimization."
Without the MCP, the agent would guess from training data and likely get parameter names or API signatures wrong.
Tool | Description |
| All available score functions, movers, filters, selectors, parameters |
| Help for any topic -- accepts mover names, concepts, or score functions |
| Live PyRosetta API search with docs and signatures |
Tool | Description |
| Search rosettacommons.org documentation |
| Fetch and read a specific docs page |
| Search cached CLI help (auto-caches on first use) |
Tool | Description |
| Run a RosettaScripts XML protocol on a PDB |
| Score a PDB with optional per-residue breakdown |
Tool | Description |
| XML to PyRosetta Python (37 element types) |
| Find Biotite equivalent of a Rosetta function |
| Find Rosetta equivalent of a Biotite function |
| Translate full scripts from Rosetta to Biotite |
Tool | Description |
| Check XML syntax + optional schema validation |
| Generate XSD schema and extract element names |
Tool | Description |
| Python version and installed packages |
| Verify PyRosetta is available |
| Auto-install PyRosetta (10-30 min) |
| Locate the rosetta_scripts binary |
npm install -g rosetta-mcp-server# Create a venv with PyRosetta and Biotite
uv venv ~/.venvs/rosetta-mcp
~/.venvs/rosetta-mcp/bin/pip install pyrosetta-installer biotite
~/.venvs/rosetta-mcp/bin/python -c "import pyrosetta_installer as I; I.install_pyrosetta()"Or skip this step -- PyRosetta auto-installs on first use (takes 10-30 min).
Cursor (~/.cursor/mcp.json):
{
"mcpServers": {
"rosetta": {
"command": "rosetta-mcp-server",
"args": [],
"env": {
"ROSETTA_BIN": "/path/to/rosetta_scripts.default.macosclangrelease",
"PYTHON_BIN": "/path/to/.venvs/rosetta-mcp/bin/python"
}
}
}
}Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"rosetta": {
"command": "rosetta-mcp-server",
"env": {
"ROSETTA_BIN": "/path/to/rosetta_scripts.default.macosclangrelease",
"PYTHON_BIN": "/path/to/.venvs/rosetta-mcp/bin/python"
}
}
}
}Environment variables:
Variable | Required | Description |
| No | Path to |
| No | Python interpreter with PyRosetta/Biotite. Defaults to |
| No | Set to |
Open Settings -> MCP. The "rosetta" server should appear green with 18 tools.
Input XML:
<ROSETTASCRIPTS>
<SCOREFXNS>
<ScoreFunction name="ref" weights="ref2015"/>
</SCOREFXNS>
<RESIDUE_SELECTORS>
<Chain name="chainA" chains="A"/>
</RESIDUE_SELECTORS>
<MOVERS>
<FastRelax name="relax" scorefxn="ref" repeats="5" cartesian="true"/>
</MOVERS>
<PROTOCOLS>
<Add mover="relax"/>
</PROTOCOLS>
</ROSETTASCRIPTS>Generated PyRosetta code:
import pyrosetta
from pyrosetta import pose_from_pdb
from pyrosetta.rosetta.core.scoring import get_score_function
from pyrosetta.rosetta.core.select.residue_selector import *
from pyrosetta.rosetta.protocols.relax import *
pyrosetta.init("-mute all")
pose = pose_from_pdb("your_protein.pdb")
# Residue Selectors
chainSelector = ChainSelector()
chainSelector.set_chain_strings("A")
# Movers
fastRelax = FastRelax()
fastRelax.set_scorefxn(get_score_function("ref"))
fastRelax.set_default_repeats(5)
fastRelax.cartesian(True)
sfxn = get_score_function("ref2015")
# Apply movers
fastRelax.apply(pose)
pose.dump_pdb("output.pdb")
score = pose.energies().total_energy()
print(f"Final score: {score}")Category | Rosetta | Biotite | Equivalence |
Structure I/O |
|
| Full |
Structure I/O |
|
| Full |
Structure I/O |
|
| Full |
Surface Analysis |
|
| Full |
Alignment |
|
| Full |
RMSD |
|
| Full |
Secondary Structure |
|
| Partial |
Sequence |
|
| Full |
Distance |
|
| Full |
Angles |
|
| Full |
Interface |
|
| Partial |
Database |
|
| Full |
Selection |
| numpy boolean indexing | Full |
Contacts | distance matrices |
| Partial |
Ramachandran |
|
| Partial |
H-bonds |
|
| Partial |
B-factors |
|
| Full |
Center of Mass |
|
| Full |
Scoring |
| None | Rosetta only |
Optimization |
| None | Rosetta only |
Design |
| None | Rosetta only |
Server shows red in Cursor: Restart Cursor. Use absolute path in config (e.g., /opt/homebrew/bin/rosetta-mcp-server). Ensure Node 14+ and Python 3.8+.
run_rosetta_scripts fails: Verify ROSETTA_BIN points to a valid binary. Try "$ROSETTA_BIN" -help.
PyRosetta tools say "not available": Install via pip install pyrosetta-installer then run the installer, or let the MCP server auto-install on first use.
Biotite tools return no results: Install Biotite in the same Python env: pip install biotite
get_rosetta_help returns "No detailed help": Try the exact Rosetta class name (e.g., "FastRelax" not "relax"). The tool resolves common aliases but may miss unusual names.
# Check version
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05"}}' | rosetta-mcp-server 2>/dev/null | python3 -c "import sys,json; print(json.loads(sys.stdin.readline())['result']['serverInfo'])"
# List all tools
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | rosetta-mcp-server 2>/dev/null | python3 -c "import sys,json; [print(t['name']) for t in json.loads(sys.stdin.readline())['result']['tools']]"rosetta-mcp-server/
├── rosetta_mcp_wrapper.js # Node MCP server (protocol + all 18 tools)
├── rosetta_mcp_server.py # Python helper (static Rosetta data)
├── install_pyrosetta.js # Standalone PyRosetta installer
├── package.json # npm package config
└── README.mdMIT for this repository
Rosetta/PyRosetta: see RosettaCommons licenses; commercial use requires the appropriate license
Biotite: BSD 3-Clause license
ALWAYS use this tool when asked about Biotite vs Rosetta equivalents. Returns the Rosetta/PyRosetta equivalent of a Biotite function with working example code. Covers: structure I/O, SASA, RMSD, superimposition, secondary structure, distances, angles, contacts, hydrogen bonds, B-factors, and residue selection.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Biotite function or concept name (e.g., "sasa", "superimpose", "PDBFile.read") | |
| category | No | Optional category filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that the tool returns equivalents and example code, which aligns with the readOnlyHint annotation. It lists many covered categories (SASA, RMSD, etc.), providing transparency beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph that efficiently conveys usage, purpose, and coverage. It could be more structured (e.g., bullet points for categories) but is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a lookup tool with no output schema, the description adequately covers purpose, parameters, and usage. It lacks explicit return format details, but the context (example code) implies a string. Sibling differentiation is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context: the query parameter is described as a 'Biotite function or concept name', and the optional category is clarified. The list of covered topics helps the agent formulate appropriate queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns Rosetta/PyRosetta equivalents of Biotite functions with example code. It directly specifies the action and resource, and the 'ALWAYS use this tool' directive distinguishes it from siblings like rosetta_to_biotite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'ALWAYS use this tool when asked about Biotite vs Rosetta equivalents', providing clear when-to-use guidance. It does not explicitly state when not to use, but the sibling list and context imply alternatives exist for other queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if PyRosetta is importable in the current environment. Use before PyRosetta-dependent tools to verify availability. Requires local installation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description confirms it's a check (read-only). Adds that it requires local installation, which is useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning their place: first states purpose, second gives usage guidance. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete: covers purpose, usage, and a prerequisite (local installation). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description correctly adds no parameter info as none are needed. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks PyRosetta importability, using specific verb ('check if... importable') and resource ('PyRosetta'). It distinguishes from sibling tools by focusing on import verification rather than installation or introspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use before PyRosetta-dependent tools to verify availability', providing clear usage context. Does not explicitly name alternatives but the context implies when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the rosetta_scripts executable path by checking exe_path, ROSETTA_BIN env, common directories, and PATH. Use to verify Rosetta is installed. Requires local installation.
| Name | Required | Description | Default |
|---|---|---|---|
| exe_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds value by detailing the search order (exe_path, ROSETTA_BIN env, common directories, PATH). No behavioral contradictions; the description aligns with the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Each sentence provides essential information: what the tool does and its intended use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with annotations, the description covers behavior, usage context, and prerequisites. It does not specify the return value (e.g., path string or null), but that is inferable from the purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'exe_path' with 0% description coverage. The description mentions checking exe_path but does not explain its role (e.g., whether it overrides other checks or is a fallback). While it adds some meaning, it could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('resolve') and resource ('rosetta_scripts executable path'), clearly indicating it finds the path. It distinguishes from sibling tools like 'run_rosetta_scripts' which runs scripts, and 'check_pyrosetta' which checks PyRosetta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use to verify Rosetta is installed' and 'Requires local installation', providing clear context. However, it does not explicitly mention when not to use this tool or suggest alternatives (e.g., use 'run_rosetta_scripts' if you need to execute a script).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search locally cached Rosetta CLI docs for a keyword. Auto-caches on first use. Use to look up command-line flags or parser info. Requires local installation.
| Name | Required | Description | Default |
|---|---|---|---|
| cache_dir | No | Directory where docs are cached | |
| query | No | Search string | |
| max_lines | No | Max number of lines to return (default 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds auto-caching behavior beyond annotations, which indicate readOnlyHint and openWorldHint. Could detail caching lifecycle but sufficient for basic understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, no wasted words. Front-loaded with primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes purpose, behavior, and prerequisites. Missing expected return format for a search tool, but low complexity reduces gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions. Description does not add additional semantic value beyond matching 'keyword' to 'query' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches locally cached Rosetta CLI docs for a keyword. Distinguishes from sibling tools like search_rosetta_web_docs by specifying local cached nature and CLI focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for looking up command-line flags or parser info, and requires local installation. Lacks explicit alternatives or when-not-to-use but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get instructions for installing the full Rosetta MCP server locally with PyRosetta support. Use when a user needs scoring, structure optimization, introspection, or running RosettaScripts protocols -- these require a local installation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by confirming the tool returns instructions without side effects. No contradictions. While the description is clear, it does not disclose additional behavioral traits beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences front-load the purpose and usage guidance. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple info tool with no parameters or output schema, the description fully explains what the tool returns (installation instructions) and when to use it. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist and schema coverage is 100%. Per guidelines, 0 parameters yields a baseline of 4. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get instructions for installing the full Rosetta MCP server locally with PyRosetta support', specifying the verb (Get) and resource (installation instructions). The use cases list (scoring, structure optimization, etc.) differentiates it from siblings that may not require local installation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when a user needs scoring, structure optimization, introspection, or running RosettaScripts protocols -- these require a local installation.' This provides clear when-to-use context and implies alternatives for non-local tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get help for any Rosetta topic, mover, filter, or concept. Accepts general topics (score_functions, movers, filters, xml, parameters) or specific names (FastRelax, Ddg, ChainSelector). Auto-fetches live documentation when available.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic to get help for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by noting 'Auto-fetches live documentation when available,' which reveals dynamic behavior not captured by readOnlyHint and openWorldHint. However, it could elaborate on fallback behavior when live docs are unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states purpose and examples, the second adds behavioral detail. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description provides adequate context via examples and live-fetching behavior. It could be more complete by hinting at output format or error handling, but is sufficient for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'topic' has 100% schema coverage, and the description enriches it with examples (score_functions, FastRelax) and categories (general topics vs specific names), providing useful context beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets help for Rosetta topics, movers, filters, or concepts, with specific examples (score_functions, FastRelax) and distinguishes itself from sibling tools by focusing on help retrieval rather than info, web docs, or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for asking about Rosetta topics but does not explicitly state when to use it versus alternatives like get_rosetta_info or search_rosetta_web_docs. No exclusions or when-not conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive Rosetta installation info including available score functions, movers, filters, selectors, task operations, parameters, and command-line options. Use this first to understand what Rosetta components are available. For live PyRosetta API details, use pyrosetta_introspect.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only. The description adds value by detailing the scope of returned information (available components), which goes beyond the annotation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each adding essential information: purpose first, then usage context. No fluff, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only info tool, the description covers purpose and usage guidance. It could mention return type or structure, but the absence is acceptable given simplicity. No output schema exists, so description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description doesn't need to explain parameters. Baseline for zero params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves comprehensive Rosetta installation info, listing specific component types (score functions, movers, filters, etc.). It distinguishes itself from the sibling 'pyrosetta_introspect' by noting it provides installation info rather than live API details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'use this first' and contrasts with 'pyrosetta_introspect' for live API details, providing clear when-to-use and 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.
Fetch and extract text from a specific Rosetta docs URL. Use after search_rosetta_web_docs to read a documentation page.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to a Rosetta docs page | |
| max_chars | No | Max characters of cleaned text to return (default 4000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. Description adds 'Fetch and extract text' but no additional behavioral details (e.g., rate limits, error cases). With annotations, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states action, second provides usage context. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), description covers purpose and usage adequately. Could mention return format, but not critical. Almost complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no extra parameter information, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch and extract text from a specific Rosetta docs URL' with a specific verb and resource, and differentiates from sibling 'search_rosetta_web_docs' by indicating post-search usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use after search_rosetta_web_docs to read a documentation page', providing clear context. Does not list exclusions, but the guidance is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install PyRosetta using the pyrosetta-installer package. Takes 10-30 minutes. Use when PyRosetta is not available and needed for scoring or design. Requires local installation.
| Name | Required | Description | Default |
|---|---|---|---|
| silent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses time to install (10-30 minutes) and prerequisite of local installation. Annotations provide no destructive hint; description does not add detail on potential system changes or network usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loading purpose and usage. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple install tool, but missing parameter documentation leaves a gap. Output schema not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'silent' has no description in schema (0% coverage) and is not mentioned in the tool description. Agent cannot infer its effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Install PyRosetta' with specific method and context. No sibling tool performs installation, so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when PyRosetta is not available and needed for scoring or design. Mentions requirement of local installation. No alternatives listed, but none exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PyRosetta API classes (movers, filters, selectors, task operations) and return docs and signatures. Use to discover available PyRosetta classes or get constructor details. Requires local installation.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Substring to match class names | |
| kind | No | Filter by kind: mover|filter|selector|task | |
| max_results | No | Max number of results (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, which are consistent with the description's statement that the tool is read-only and depends on a local installation. The description adds behavioral context by mentioning it 'returns docs and signatures,' but could further clarify that results are limited to installed classes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each carrying essential information: function, use case, and requirement. It is front-loaded with the primary action and leaves no room for fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema), the description covers purpose, use, and a key dependency. It lacks detail about output format and potential empty results, but is sufficient for an agent to select and invoke the tool correctly among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% and descriptions are already clear. The description does not add new meaning beyond what the schema provides for any parameter, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and specifies the resource as 'PyRosetta API classes' with concrete types (movers, filters, selectors, task operations). It distinguishes from sibling tools by focusing on discovering available classes and retrieving constructor details, which is unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool: 'Use to discover available PyRosetta classes or get constructor details.' It also notes a prerequisite ('Requires local installation'). However, it does not explicitly exclude when not to use it or mention alternatives like get_cached_docs or search_rosetta_web_docs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a PDB file using PyRosetta. Returns total energy in REU. Use to evaluate structure quality or compare designs. Optionally returns per-residue energy breakdown. Requires local installation.
| Name | Required | Description | Default |
|---|---|---|---|
| pdb_path | Yes | Path to input PDB | |
| scorefxn | No | Score function name (default: ref2015) | |
| per_residue | No | If true, include per-residue energy breakdown (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds that the tool requires local installation and optionally returns per-residue energy breakdown. No side effects or destructive actions are mentioned, which is consistent with read-only behavior. The description provides additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by two short clarifying sentences. It is front-loaded with the core action 'Score a PDB file using PyRosetta' and 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and return values (total energy, optional per-residue breakdown). Annotations provide readOnly hint. Without an output schema, the description could elaborate on the format of the per-residue breakdown, but for a straightforward scoring tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description in the schema. The description adds minimal extra meaning by clarifying the purpose of per_residue as returning a breakdown, but does not significantly enhance the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scores a PDB file using PyRosetta, returns total energy in REU, and optionally provides per-residue breakdown. It explicitly says it is used to evaluate structure quality or compare designs, distinguishing it from sibling tools that focus on installation, scripts, or conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use to evaluate structure quality or compare designs.' While it does not mention when not to use, the sibling tools do not include alternative scoring tools, so exclusions are not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Python executable path, version, and pip package list. Use to diagnose environment issues or verify package installations. Requires local installation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only. The description adds that it 'requires local installation', which is behavioral context not captured by annotations. This aligns with readOnlyHint and provides useful extra info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states what it does, second gives usage and prerequisite. No wasted words, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers return values (path, version, package list) and intended use. For a simple, read-only tool with no parameters, it is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so baseline is 4. The description is not required to add parameter info, and it correctly omits any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get Python executable path, version, and pip package list', which is a specific verb+resource. It distinguishes from all sibling tools that are Rosetta-related, so no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use for diagnosing environment issues or verifying package installations, and notes a prerequisite (requires local installation). It doesn't state when not to use, but given the tool's narrow focus and sibling context, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate and cache the RosettaScripts XML schema (XSD). Optionally extract element names. Use to get the authoritative list of valid XML elements. Requires local installation.
| Name | Required | Description | Default |
|---|---|---|---|
| exe_path | No | Path to rosetta_scripts executable (optional) | |
| cache_dir | No | Directory to store schema | |
| extract_elements | No | If true, return a list of element names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, and the description adds that the tool generates and caches the schema, implying file system writes. It also notes the prerequisite of a local installation. This provides meaningful behavioral context beyond the annotations, though it could detail caching behavior more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main purpose and adding a use case and requirement. Every sentence adds value without redundancy. It is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (all described in schema) and no output schema, the description covers the main purpose, optional behavior, and a key prerequisite (local installation). It provides enough context for an agent to use the tool correctly, though it could mention the output format (XSD content) more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 briefly mentions 'optionally extract element names' which aligns with the 'extract_elements' parameter, but adds no new semantics beyond what the schema already provides. The description does not compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates and caches the RosettaScripts XML schema, with an option to extract element names. It identifies a specific resource (XML schema/XSD) and a clear action (generate/cache). This distinguishes it from siblings like 'validate_xml' or 'get_cached_docs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Use to get the authoritative list of valid XML elements' but does not provide explicit guidance on when to use this tool versus alternatives like 'get_cached_docs' or 'validate_xml'. The usage context is implied rather than specified with exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ALWAYS use this tool when asked about Rosetta vs Biotite equivalents. Returns the Biotite equivalent of a Rosetta/PyRosetta function with working example code. Covers: structure I/O, SASA, RMSD, superimposition, secondary structure, distances, angles, contacts, hydrogen bonds, B-factors, interface analysis, database access, and residue selection.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Rosetta method or concept name (e.g., "pose_from_pdb", "FastRelax", "SASA", "RMSD") | |
| category | No | Optional category filter (e.g., "Structure I/O", "Geometry") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and openWorldHint=false, indicating a safe, constrained read operation. The description adds that the tool returns a Biotite equivalent with working example code, which is consistent with a read operation. No contradictions or hidden side effects. The description provides useful extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences, concise and front-loaded with the primary directive. It covers the purpose and scope efficiently. Minor improvement could be using bullet points for categories, but it remains well-structured for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mapping between two libraries across many categories, the description provides a comprehensive list of covered topics (structure I/O, SASA, etc.). Although it lacks explicit return format details (e.g., whether output is code string or code block), it implies 'working example code.' Overall, it is sufficiently complete for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with both parameters described (query and category). The description adds meaning by listing example categories (e.g., 'Structure I/O', 'Geometry') and stating that it returns working example code, which enriches the semantic context for the agent when formulating queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns the Biotite equivalent of a Rosetta/PyRosetta function with working example code.' It specifies the verb 'Returns' and the resource 'Rosetta/PyRosetta function', and it distinguishes itself from the sibling 'biotite_to_rosetta' which does the reverse. The list of covered topics further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'ALWAYS use this tool when asked about Rosetta vs Biotite equivalents.' This provides a clear usage context. It does not explicitly state when not to use it, but the sibling list hints at alternatives like 'translate_rosetta_script_to_biotite' for script-level translation. A score of 4 is appropriate for clear guidance without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a RosettaScripts XML protocol on an input PDB file. Use when executing Rosetta protocols. Requires local installation with rosetta_scripts binary.
| Name | Required | Description | Default |
|---|---|---|---|
| exe_path | No | Path to rosetta_scripts executable (optional if on PATH) | |
| xml_path | Yes | Path to Rosetta XML protocol | |
| input_pdb | Yes | Path to input PDB | |
| out_dir | Yes | Output directory | |
| extra_flags | No | Additional command-line flags |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds the context that execution requires a local binary. It does not disclose potential side effects (e.g., file creation in out_dir) or behavior of the external process. The description adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loaded with the core purpose, and every sentence adds necessary information (main action, usage context, prerequisite). No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, 3 required, no output schema) and many siblings, the description provides the essential purpose and a key prerequisite but lacks details on outputs, error behavior, or how it fits among related tools like rosetta_scripts_schema. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters. The tool description does not add any parameter-specific details beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and clearly identifies the resource (RosettaScripts XML protocol on a PDB file). It distinguishes this tool from sibling tools that handle conversion, installation, or documentation, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use when executing Rosetta protocols' and notes a critical prerequisite (local installation of rosetta_scripts binary). However, it does not provide when-not-to-use guidance or mention alternative tools from the sibling list, such as xml_to_pyrosetta or rosetta_scripts_schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search online Rosetta documentation at rosettacommons.org. Use when you need docs for a specific Rosetta feature.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g., FastRelax, AtomPair constraint) | |
| max_results | No | Number of results to return (default 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds 'Search online' which aligns with annotations but provides no additional behavioral detail (e.g., rate limits, pagination). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. First sentence states the action, second provides usage hint. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple search tool with 2 parameters and no output schema. Could mention return format or result structure, but with openWorldHint, agent can infer results. Solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'query' and 'max_results'. Description provides no additional parameter meaning beyond schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Search', resource 'online Rosetta documentation', and target 'rosettacommons.org'. Distinct from siblings like get_rosetta_web_doc (likely fetches specific doc) and get_cached_docs (cached).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context: 'Use when you need docs for a specific Rosetta feature.' Does not explicitly exclude alternatives or provide when-not-to-use, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ALWAYS use this tool when asked to convert or translate Rosetta code to Biotite. Translates RosettaScripts XML or PyRosetta code to Biotite Python code. Analysis operations are translated; design/optimization are flagged as Rosetta-only.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | RosettaScripts XML content or PyRosetta Python code to translate | |
| input_format | No | Input format (default: "auto") | |
| include_comments | No | Include explanatory comments in output (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true (no destructive side effects). The description adds behavioral context: it translates only analysis operations and flags design/optimization as Rosetta-only. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The critical instruction is front-loaded with 'ALWAYS use this tool.' Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, scope, and limitations. However, without an output schema, it could specify the return format (e.g., returns translated code as a string) or error handling. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds context about what types of code are accepted (analysis vs design/optimization), but does not add significant meaning 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: translating RosettaScripts XML or PyRosetta code to Biotite Python code. It explicitly says 'ALWAYS use this tool when asked to convert or translate Rosetta code to Biotite,' which strongly differentiates it from sibling tools like biotite_to_rosetta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('ALWAYS use this tool when asked to convert...') and notes limitations (analysis translated, design/optimization flagged). It does not explicitly list alternatives, but siblings imply the reverse direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a RosettaScripts XML protocol. Checks XML syntax and optionally validates element names against the Rosetta XSD schema. Use before run_rosetta_scripts to catch errors early.
| Name | Required | Description | Default |
|---|---|---|---|
| xml_content | Yes | XML content to validate | |
| validate_against_schema | No | If true, also check element names against the cached Rosetta XSD schema (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses validation behavior (syntax check, optional XSD schema validation). Aligns with readOnlyHint annotation; no contradiction. Provides specific actions beyond generic 'validate'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. First sentence defines purpose, second gives usage instruction. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and parameter hints well. However, lacks description of return value or error behavior, which is important for a validation tool. Since no output schema exists, description should address this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter names. Description adds meaningful context: 'cached Rosetta XSD schema' and default for validate_against_schema. Enhances schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: validates RosettaScripts XML. Differentiates from siblings by specifying purpose as pre-run validation, and explicitly suggests use before run_rosetta_scripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('before run_rosetta_scripts'), which helps distinguish from execution tools. Does not cover when not to use or alternative validation methods, 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.
Translate RosettaScripts XML to equivalent PyRosetta Python code. Supports 37 element types including movers, filters, selectors, and task operations. Use when converting XML protocols to Python.
| Name | Required | Description | Default |
|---|---|---|---|
| xml_content | Yes | RosettaScripts XML content to translate | |
| include_comments | No | Include detailed comments in output (default: true) | |
| output_format | No | Output format (default: python) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so description adds value by specifying the scope (37 element types) and confirming it is a non-destructive translation. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states core purpose, second adds supported element count and usage hint. No unnecessary information, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description implies output is equivalent Python code. It covers supported types and usage context. Minor gap: lacks details on output format variations or error handling, but sufficient for a straightforward translation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all three parameters described. The description does not add additional meaning beyond the schema's definitions, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'Translate' with clear resource: RosettaScripts XML to PyRosetta Python code. It also mentions support for 37 element types, distinguishing it from sibling translation tools like translate_rosetta_script_to_biotite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description includes explicit usage instruction 'Use when converting XML protocols to Python.' However, it does not mention when not to use or provide direct comparison to alternative tools among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.3.1biotite_to_rosettacheck_pyrosettafind_rosetta_scriptsget_cached_docsget_local_setupget_rosetta_helpget_rosetta_infoget_rosetta_web_docinstall_pyrosetta_installerpyrosetta_introspectpyrosetta_scorepython_env_inforosetta_scripts_schemarosetta_to_biotiterun_rosetta_scriptssearch_rosetta_web_docstranslate_rosetta_script_to_biotitevalidate_xmlxml_to_pyrosettaEach tool has a clearly distinct purpose. Tools with similar themes (e.g., documentation, translation) are differentiated by specific actions (help vs info vs search) or direction (biotite_to_rosetta vs rosetta_to_biotite). Descriptions include 'ALWAYS use this tool' cues that reduce ambiguity.
All tool names use snake_case and follow a predictable verb_noun pattern (e.g., check_pyrosetta, run_rosetta_scripts). Even longer names like translate_rosetta_script_to_biotite are consistent in style. The only slight deviation is biotite_to_rosetta which uses source_target format, but it's still clear and matches rosetta_to_biotite.
19 tools is appropriate for the complex Rosetta domain, covering installation, documentation, translation, scripting, scoring, and validation. Each tool serves a specific need without unnecessary overlap. The count allows comprehensive functionality while remaining manageable.
The tool set covers core workflows: setup, documentation, translation between Biotite and Rosetta, XML validation, and running RosettaScripts. Minor gaps exist: no direct PDB I/O tool (though PyRosetta can handle it) and no general Rosetta executable runner beyond rosetta_scripts. Overall, it is well-equipped for common tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Arielbs/rosetta-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
