Skip to main content
Glama
yeyuan98

BioMCP

by yeyuan98
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

pdb

Search the Protein Data Bank for macromolecular structures, fetch entry metadata by ID, and download structure files in CIF or legacy format.

Instructions

Access the Protein Data Bank (RCSB PDB) for macromolecular structure data.

SEARCH: Provide "query" to find structures (e.g., "kinase inhibitor", "hemoglobin"). GET: Provide "pdb_id" to retrieve entry metadata with optional detail sections. Sections list per-entity records (polymer_entities, ligands, assembly); when some records fail while siblings succeed, each failure appears as an inline {_error} item AND the response carries a top-level "warnings" array naming the section and failed item. DOWNLOAD: Provide "pdb_id" + download=true to save the structure file and get the file path.

Input Schema

NameRequiredDescriptionDefault
limitNoMax search results
queryNoFree-text search query to find PDB entries. Omit pdb_id when searching.
formatNoFile format: "cif" (mmCIF, recommended, always available) or "pdb" (legacy format, may not exist for some entries). Only used with download=true.cif
offsetNoSearch result offset
pdb_idNoPDB identifier (e.g., "1CRN", "4HHB"). Required for get/download.
downloadNoSave the structure file to disk and return the file path. Only used with pdb_id.
sectionsNoMetadata sections: polymer_entities (chains and sequences), ligands (small molecules and ions), assembly (biological assembly), experiment (method, resolution), citation (publication). Use "all" for everything. Default: core summary only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.0-alpha.10
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / offset / maximum
      Added value: +9007199254740991
  2. First observedv0.1.8

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and openWorldHint=true; the description is consistent with this by noting that download writes a file to disk and returns the path. It also adds genuine non-schema behavior: per-record {_error} items and a top-level warnings array when section records partially fail. Missing only auth/rate-limit info, which would push it to a 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?

Front-loaded with the tool's purpose, then cleanly segmented into SEARCH/GET/DOWNLOAD labels. The warnings sentence is dense but carries unique behavior, and there is no filler; slightly tightening the section-records clause would make it a 5.

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?

With 7 optional parameters, no output schema, and only minimal annotations, the description does the heavy lifting needed for correct invocation: mode selection, file-writing behavior, and error/warning handling. Return-value detail is only partially covered for search results, keeping it just shy of a 5.

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%, so every parameter (query, pdb_id, format, sections, limit, offset, download) is already documented in the schema. The description reinforces mode combinations (query omits pdb_id; sections list per-entity records) but adds no syntax or format detail beyond what the schema provides, so baseline 3 fits.

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?

Names a specific verb/resource ('Access the Protein Data Bank for macromolecular structure data') and explicitly breaks the tool into three distinct operations (SEARCH, GET, DOWNLOAD). An agent can immediately tell what the tool does and which operation it needs.

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 mode-selection rules: use query to search, pdb_id to get metadata, pdb_id + download=true to save the file. The omission of a 'when not to use' or sibling comparison is minor since no other PDB tool exists in the sibling list, but the conditional guidance per mode is clear.

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

Deploy Server

Other Tools