Skip to main content
Glama

protein-mcp-server

protein-mcp-server: compare structures

protein_compare_structures
Read-only

Structurally align multiple structures (up to the configured batch cap; structures past it are returned in ignored) via the RCSB Structural Comparison service (TM-align / jFATCAT). reference:"first" aligns every structure to the first; reference:"all_pairs" computes the full pairwise matrix. Each pair is an independent async alignment job with per-pair partial success — a pair still computing when its poll budget or the call's 50 s budget runs out returns status "computing" with its job UUID, and a failed pair degrades its row without sinking the others, keeping its job UUID when the job was submitted. Re-call with a matching entry in resume[] to poll a pair's job UUID instead of resubmitting; a resumed pair reports a and b in the order its job was submitted, and a resume under a different method is rejected. Returns TM-score, RMSD, and aligned-residue count per pair, plus each structure's modeled-residue count and alignment coverage. TM-score is length-normalized and can shift sharply between structures that differ only by a terminal residue or two — the greedy superposition can settle into a worse local optimum — so read tmScore alongside rmsd, alignedResidues, modeledResidues and coverage, the columns that make such cases diagnosable.

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": {
      "structures": "<structures>"
    },
    "name": "protein_compare_structures"
  }
}

Input Schema

NameRequiredDescriptionDefault
methodNoAlignment algorithm: tm-align, fatcat-rigid, or fatcat-flexible.tm-align
resumeNoResume tickets from a prior call: for each pair whose labels match an entry here, poll the existing UUID instead of submitting a new alignment job. Copy a, b, and uuid verbatim from a prior response's pairs[]; keep structures, reference, and method unchanged. The order of structures may change — a resumed pair keeps the orientation its job was submitted in.
referenceNoAlign all to the first structure, or compute the full pairwise matrix.first
timeout_sNoPoll budget per pair in seconds before returning "computing". Defaults to the server setting. The whole call stops at 50 s, so that budget ends polling first once timeout_s nears 50 or there are more pairs than the server aligns at once (PROTEIN_FANOUT_CONCURRENCY): a pair it stops after submission returns "computing" with its uuid, and one it reaches before submission returns "failed".
structuresYesThe structures to compare, up to the configured batch cap; structures past it are returned in ignored and not compared. A structure repeated here is compared once.

Output Schema

NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
pairsNoOne row per aligned pair.
methodNoAlignment method used.
noticeNoAdvisory note: pairs still computing or failed (with how to resume them), structures beyond the batch cap that were ignored, and repeated structures compared once.
ignoredNoStructures past the batch cap, never compared — repeats dropped, in input order. Re-call with them alongside the structures to compare them against (e.g. the first structure plus these, reference "first"). Absent when the cap dropped nothing.
computingNoNumber of pairs still computing.
referenceNoComparison mode used.
pairsTotalNoNumber of pairs compared.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say readOnly and openWorld, but the description discloses the async job model, per-pair partial success, the 50 s call budget versus per-pair poll budget, the "computing"/"failed" outcome split depending on whether a pair was submitted, and rejection of resume under a changed method — all behavior an agent cannot infer from structured fields.

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?

Dense but well front-loaded — core action first, then reference modes, failure semantics, resume mechanics, and output-reading caveats. A few clauses (e.g. the TM-score local-optimum aside) are verbose, but each carries actionable information rather than 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 fan-out async comparison tool with five parameters, the description covers batching, budgets, failure degradation, resumption, and the diagnostic interpretation of TM-score. With an output schema present it does not need to enumerate return fields, and the caveat about length-normalized TM-score is exactly the extra guidance an agent needs.

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 already 100%, yet the description still adds meaning: it explains the reference:"first" vs "all_pairs" semantics and the resume orientation rule (a/b keep submission order) plus the method-match rejection, going beyond the schema's own prose.

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?

Opens with a specific verb+resource ("Structurally align multiple structures") and names the backing service and algorithms (RCSB Structural Comparison, TM-align / jFATCAT), so an agent knows exactly what capability this is versus siblings like protein_find_similar.

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?

Gives explicit operational routing: which reference mode to pick, when to re-call with resume[] instead of resubmitting, and how to read tmScore alongside rmsd/alignedResidues for pathological cases. It does not name sibling tools as alternatives, so selection across the broader toolset is still left to context.

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.