Skip to main content
Glama

fetch_alphafold

Fetch protein structures predicted by AlphaFold from UniProt accession, using confidence-based coloring to identify reliable versus disordered regions.

Instructions

Fetches a predicted structure from AlphaFold DB by UniProt accession.

These are predictions, not experimental structures, so the model is coloured by pLDDT confidence rather than the usual style — dark blue is reliable, orange is essentially unmodelled. Read the orange and yellow regions as "probably disordered or wrong", not as flexible loops.

Note that pLDDT rides in the B-factor column, so bfactor_view and putty_view will mis-colour these models (they assume low = rigid, which is backwards for confidence). Use plddt_view instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
replaceNoClear the session first, so this is the only structure loaded. Pass False to add to what is already loaded — which is how you get two structures into one session for superposition_view.
fragmentNoFragment number for long proteins split across models (F1, F2, …). Most entries only have F1.
obj_nameNoOptional custom name for the object in PyMOL.
uniprot_idYesUniProt accession (e.g. "P69905" for human haemoglobin alpha). An "AF-" prefix is accepted and stripped.
model_versionNoPin a specific AlphaFold model version. Leave unset (the default) to use whichever version the database currently serves — old versions are retired and stop resolving.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
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.

Install Server

Other Tools

Latest Blog Posts

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