MCPymol

Overview Schema Source Related Servers Discussions Admin

fetch_alphafold

DestructiveIdempotent

Load a predicted AlphaFold DB structure by UniProt accession into PyMOL, colored by pLDDT confidence to assess model reliability.

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

Name	Required	Description
`replace`	No	Clear 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.
`fragment`	No	Fragment number for long proteins split across models (F1, F2, …). Most entries only have F1.
`obj_name`	No	Optional custom name for the object in PyMOL.
`uniprot_id`	Yes	UniProt accession (e.g. "P69905" for human haemoglobin alpha). An "AF-" prefix is accepted and stripped.
`model_version`	No	Pin 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

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.5.1Aug 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered; the description adds real value by explaining that these are predictions, that pLDDT rides in the B-factor column, and that low B-factor means high confidence — a non-obvious inversion. It does not itself mention that the default wipes the session (that lives only in the schema's replace parameter), so not a full 5.

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?

Purpose is front-loaded in the first sentence, then the confidence-colouring and B-factor caveats follow. The colour interpretation paragraph is slightly long for what it conveys, but every sentence carries information the agent cannot get elsewhere.

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?

An output schema exists, so return values need no explanation, and the description covers the domain-specific pitfalls an agent would otherwise get wrong (mis-coloured putty/bfactor views, orange regions as disorder). The only gap is that session-clearing behaviour is documented solely in the schema, not the prose.

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 every parameter including fragment, obj_name and model_version is documented in the schema with examples and caveats. The description text adds no parameter-level meaning, 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?

States a specific verb and resource with its source: 'Fetches a predicted structure from AlphaFold DB by UniProt accession.' The 'predicted' qualifier and the named database distinguish it from fetch_structure/load_structure siblings without the agent needing to open schemas.

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 strongly routes the agent away from bfactor_view and putty_view toward plddt_view, which is useful downstream guidance, but it never states when to choose this tool over fetch_structure or load_structure. Operator usage is implied rather than explicit.

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

Deploy Server