Skip to main content
Glama

protein-mcp-server

protein-mcp-server: get structure

protein_get_structure
Read-only

Fetch structures with metadata and coordinate-file URLs. source "experimental" takes PDB entry IDs, and also resolves the computed-model IDs protein_search_structures returns (AF_*/MA_*), which come back marked source "predicted" with their modelling provider; "predicted" takes UniProt accessions, isoform accessions (P04637-2), or AlphaFold DB entry IDs (AF-P04637-2-F1) (AlphaFold, with pLDDT/PAE confidence); "best_available" takes the same identifiers, an entry ID reduced to its accession, and returns the top federated model — the PDB entry with the widest UniProt coverage, ties going to the finest resolution (coverage measures the mapped span, so the pick can be an engineered mutant over the wild-type entry), else the model with the highest confidence on the lDDT scale (pLDDT/100 or QMEANDisCo), unscored models last, which can include an experimental model outside the PDB such as a SASBDB fit; best_available records carry coverage and the UniProt span. Under predicted and best_available, a UniProt accession merged into another entry resolves to its successor's model with a notice naming the merge, and a demerged or deleted accession lands in failed[] with its replacements. Records fetched under source "experimental", computed models included, also carry polymer entities with both chain namespaces (labelAsymIds for protein_compare_structures, authAsymIds for protein_get_annotations; each lists an entity's first 100 chains beside its chainCount, or every chain with all_chains), bound ligands, molecular weight, and release date. Resolves up to the configured batch cap per call with per-ID partial success: IDs are trimmed and repeats looked up once, missed IDs are listed in failed[] with their reasons, and IDs beyond the cap are listed in ignored, never looked up. Upstream lookups share one time budget per call; under predicted and best_available, an ID not finished within it, or whose upstream lookup failed, lands in failed[] with a reason to re-call it. Set include_coords to inline coordinate text, held to 24000 characters per response on both surfaces: a lone selected file arrives in 24000-character windows, each giving coordinatesNextOffset to pass back as coords_offset; several selected files inline whole when they total 24000 characters or fewer, and otherwise overflow lists each file's length — re-call with sections naming one structure to page through its file. coordinateUrls always link the complete files.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ids": "<ids>"
    },
    "name": "protein_get_structure"
  }
}

Input Schema

NameRequiredDescriptionDefault
idsYesPDB entry IDs or computed-model IDs such as AF_AFP69905F1 (source experimental); UniProt accessions, isoform accessions such as P04637-2, or AlphaFold DB entry IDs such as AF-P04637-2-F1 (predicted / best_available). Trimmed, and a repeat (case-insensitive) is looked up once.
sourceNoWhere to fetch: experimental (PDB), predicted (AlphaFold), or best_available (federated pick).experimental
sectionsNoStructure IDs to inline coordinates for, in place of include_coords — from an overflow outline, or one ID to page through its file with coords_offset. Each must match the id of a structure this call resolves.
all_chainsNoList every chain ID of each polymer entity. Off by default: authAsymIds and labelAsymIds hold an entity's first 100 chains, and chainCount its full count. Applies to source experimental; the other sources return no polymer entities.
coords_offsetNoCharacter offset of the window to return when exactly one structure is selected (sections naming one ID, or include_coords on a one-ID call): the window is characters [coords_offset, coords_offset + 24000). Pass the coordinatesNextOffset a previous window returned.
include_coordsNoInline coordinate text for every resolved structure — mmCIF, or PDB format when no mmCIF URL is available; coordinateFormat names which. A lone file arrives in 24000-character windows. Off by default — URLs are always returned.

Output Schema

NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
failedNoIDs that could not be resolved (partial success).
noticeNoEvery applicable advisory joined into one string: repeated IDs counted once, batch cap, partial failures, a UniProt merge that resolved an accession to its successor, an unavailable PDB check behind a best_available pick, a computed model whose provider coordinate lookup failed (only its BinaryCIF URL listed), chain-ID lists capped at 100 per polymer entity, the re-call for the next coordinate window, a coords_offset past the end of the file, a sections entry that matched no structure, coordinate-budget overflow, and failed coordinate inlining.
ignoredNoIDs past the batch cap, never looked up — trimmed, repeats dropped, in input order. Pass them as ids in a follow-up call with the same source. Absent when the cap dropped nothing.
overflowNoPresent only when two or more selected coordinate files together exceed 24000 characters, the budget for one response; their coordinates are then withheld from both surfaces.
resolvedNoNumber of processed IDs that resolved to a structure.
processedNoNumber of distinct IDs looked up: a repeated ID counts once, and IDs past the batch cap are listed in ignored instead.
requestedNoNumber of IDs in the original request, repeats included, before de-duplication and the batch cap.
structuresNoResolved structures (metadata always present).
attributionNoUpstream data-source licenses and citations for every source present in structures[] — RCSB PDB for PDB entries, the providing database (AlphaFold DB, ModelArchive, SWISS-MODEL, SASBDB, …) for any other model. Always present — the attribution obligation travels with the data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses substantial behavioral detail: per-ID partial success with failed[] and ignored lists, a shared time budget per call, merged/demerged accession handling, batch caps, and coordinate paging via coords_offset. These are exactly the operational traits an agent needs and are not available from the annotations alone.

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 very dense paragraph with long semicolon-chained clauses. The purpose is front-loaded, and most content is substantive, but the run-on structure makes it difficult to parse and some source-mode details could be organized more clearly. It is information-rich but not concise.

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, an output schema, and fully documented parameters, the description covers everything an agent needs: source-dependent identifier types, partial-failure semantics, batching limits, coordinate inlining and paging, and URL fallback behavior. No critical behavioral gap remains for correct invocation.

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 each parameter's basic meaning. The description adds cross-parameter semantics the schema does not fully convey, such as the 24000-character inlining limit, the single-file windowing behavior with coordinatesNextOffset, and when sections can be used to page through an overflow outline. This is meaningful value 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 states a specific verb and resource: 'Fetch structures with metadata and coordinate-file URLs.' It further distinguishes the three source modes and explicitly names sibling tools (protein_search_structures, protein_compare_structures, protein_get_annotations) to clarify its place in 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 thoroughly explains which source value to choose: experimental for PDB/computed model IDs, predicted for UniProt/AlphaFold accessions, and best_available for federated picks. It also notes how chain namespaces map to sibling tools. It stops short of an explicit 'use this instead of X when Y' statement against all siblings, but the source-selection guidance is strong and practical.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.