Loading ToolBench
MCP Server for BindCraft Scripts - Provides synchronous and asynchronous APIs for protein binder design tools
BindCraft MCP has 9 tools with explicit definitions in src/server.py. Tool naming is generally verb-first and clear (get_*, list_*, submit_*, cancel_*, quick_*, monitor_*, generate_*). Descriptions are present for all tools (194-350 chars average, within baseline). However, there are significant gaps: (1) Input schemas are visible for all tools and include parameter types and descriptions, meeting baseline quality. (2) Output schemas are NOT documented, the code shows 'Returns: dict' but does not specify what fields the dict contains. This forces LLMs to guess at response structure. (3) Parameter descriptions lack specificity, e.g., 'config' is described as 'Path to config file (optional)' but does not explain the format or relationship to target_settings.json, which is documented only in generate_config's description. (4) Error handling is not visible in the source, no guidance on what errors each tool returns or how to recover. (5) Some parameter defaults could trigger unintended side effects (e.g., device=0 assumes GPU 0 exists; num_designs=3 in submit_async_design could be expensive). (6) Tool compositions are well-designed (job management tools vs. design tools are separate), but missing linking documentation (e.g., submit_async_design returns a job_id, but the relationship to get_job_status is not explicitly stated in descriptions).
Cancel a running job.
Generate BindCraft configuration files from PDB structures. This tool analyzes PDB files and creates configuration files for binder design. It's fast and doesn't require GPU resources. The generated target_settings.json follows the format expected by run_bindcraft.py with keys: design_path, binder_name, starting_pdb, chains, target_hotspot_residues, lengths, number_of_final_designs.
Get log output from a running or completed job.
Get the results of a completed job.
Get the status of a submitted job.
List all submitted jobs.
Monitor progress of running BindCraft jobs. Use this to check the status of jobs running in output directories. This tool reads log files and progress indicators without interfering with jobs.
Output schemas not documented. All tools return 'dict' with no specification of field names, types, or structure. LLMs cannot infer response format and must guess at chaining keys (e.g., what field contains the job_id after submit_async_design?).
Parameter constraints and formats under-specified. 'config' and 'input_file' accept paths but do not state allowed file types, location restrictions, or validation rules. 'chains' accepts a string but does not clarify format (single letter? comma-separated? A-Z uppercase only?). 'status' in list_jobs is described as 'pending, running, completed, failed, cancelled' but not declared as an enum.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 10 | - | v1 |
Quick synchronous protein binder design from PDB structure. Use this for fast binder design (typically 1-10 minutes). For longer runs or multiple designs, use submit_async_design instead.
Submit an asynchronous protein binder design job for background processing. This operation may take >10 minutes and runs in the background. Use this for multiple designs or when you want to submit and check back later.
Error handling and recovery guidance absent. No documentation of when tools fail, what errors to expect, or how to recover. E.g., does get_job_result return a structured error if the job failed, or does it throw an exception? Should the LLM retry or ask the user?
Parameter defaults with potential side effects. device=0 assumes GPU 0 exists and is available. num_designs=3 (submit_async_design) could be expensive for users who expect faster submission. binder_length=130 is reasonable but not validated for biologically feasible range.
Tool composition documentation incomplete. submit_async_design returns a job_id, but descriptions do not explicitly state 'Pass this job_id to get_job_status, get_job_result, get_job_log, or cancel_job to manage the job.' This breaks the obvious tool chain for LLMs.
Parameter naming lacks specificity in some cases. 'config' is ambiguous (could be YAML, JSON, TOML, Python). 'output_file' in generate_config says 'Path for output directory' but the parameter is named _file not _dir, creating confusion.
Missing pagination guidance. list_jobs lacks limit and offset parameters, so large job lists will not scale. No documentation of typical list size or whether results are capped.