Skip to main content
Glama
huangjianhuster

Biomolecule Modeling MCP Server

assemble_pdb_structures

Merge separate PDB files into a single structure, recombining processed components or building multi-chain complexes for downstream modeling.

Instructions

Merge multiple PDB files into a single PDB file.

WHEN TO USE

Use after split_pdb + fix_pdb_structure when you have separately processed components (e.g. fixed protein + original ligand) that need to be recombined before relaxation. Also useful for building hetero-complexes from individual chain files.

WORKFLOW POSITION

Optional step between fix_pdb_structure and relax_pdb_structure.

DECISION GUIDANCE

chain_id_map: Always provide this if you have performed split → fix → assemble, because fix_pdb_structure may have altered chain IDs. Map by the basename of the input file (e.g. {"protein_A_fixed.pdb": "A"}).

handle_conflicts (default "rename"): Use "rename" (default) for most cases — it is safe and non-destructive. Use "merge" only when two files represent the same biological chain split across files (e.g. modelled N-terminal extension + crystal structure). Never use "error" in automated workflows.

renumber_residues (default False): Only set True if downstream tools require sequential numbering from 1. Renumbering loses the original residue IDs, which makes cross-referencing with the source PDB harder.

renumber_atoms (default False): Set True if the output PDB will be read by tools that expect strictly sequential atom serials.

OUTPUT — WHAT TO CHECK

Run query_pdb_structure on the assembled output to verify chain IDs, residue counts, and that no unexpected gaps were introduced by the merge.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoRecord which components are being merged and why, e.g. "re-assembling fixed chain A with original ligand files before relaxation".
input_pdbsYesOrdered list of PDB paths to merge (order determines chain order in the output).
output_pdbYesPath for the assembled output file.
chain_id_mapNoMap of input basename → desired output chain ID.
renumber_atomsNoRenumber all atom serials sequentially (default False).
handle_conflictsNo"rename" | "merge" | "error" (default "rename").rename
renumber_residuesNoRenumber residues in every chain from 1 (default False).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description assumes full responsibility for behavioral disclosure. It does so thoroughly: explains chain ID mapping risks after fix_pdb_structure, differentiates handle_conflicts modes with safety implications, and warns that renumbering loses original residue IDs. This goes well beyond basic operation descriptions.

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 well-organized with clear section headers (PURPOSE, WHEN TO USE, WORKFLOW POSITION, DECISION GUIDANCE, OUTPUT). It is information-dense but every sentence serves a purpose, covering essential guidance without wasted words.

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?

Despite having 7 parameters and no annotations, the description covers all aspects needed for correct usage: purpose, workflow position, per-parameter decision guidance, and output verification steps. This is a model of completeness for a complex structural biology tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds significant meaning beyond the schema. For example, it advises when to use chain_id_map, clarifies the practical difference between 'rename' and 'merge', and explains the consequences of renumber_residues and renumber_atoms. This is substantial added value.

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 'Merge multiple PDB files into a single PDB file,' using a specific verb and resource that immediately distinguishes it from siblings like split_pdb. The inverse relationship to split_pdb is implicit, making its 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'WHEN TO USE' section provides concrete scenarios: after split_pdb + fix_pdb_structure, for building hetero-complexes, and positions itself in the workflow between fix_pdb_structure and relax_pdb_structure. This clearly guides when to choose this tool over alternatives.

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/huangjianhuster/biomolecule-modeling-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server