Loading ToolBench
MCP-compliant wrapper for PoseBusters validation tool. Validates ligand-protein structures using PoseBusters, supporting both pose validation and redocking validation workflows.
PoseBusters MCP server has significant quality gaps. Only 3 tools are defined, and while two (`validate_pose`, `redocking_validation`) have structured input schemas with type information, the schemas contain problematic design patterns. The `context` tool is a meta-tool with unclear purpose in the MCP context. Input descriptions are present but generic. Output schemas are not documented in the provided code. Error handling is minimal. Parameter naming uses unclear object types (`ligand_input`, `protein_input`, `crystal_input` as `{"type":"object"}`). No tool descriptions explain WHEN to use each tool vs. the other, leading to potential confusion between `validate_pose` and `redocking_validation`. The `action` parameter is redundant with tool naming (each tool already specifies its action as an enum value). No evidence of proper error recovery guidance, pagination, or structured output documentation.
Return MCP context with application metadata defining the tool's capabilities, actions, objects, and windows. Response is validated against MCP_CONTEXT_SCHEMA.
Validates a redocked pose by comparing it to a crystal ligand. Takes ligand SDF file, protein PDB file, and crystal ligand SDF file, runs validation checks via the 'bust' command with CSV output format.
Validates a pose using PoseBusters. Takes a ligand SDF file and protein PDB file, runs validation checks via the 'bust' command with CSV output format.
Input parameters use generic `object` type without clarity on file format handling. Parameters `ligand_input`, `protein_input`, `crystal_input` are typed as `{"type":"object","description":"..."}` but should document expected file formats (SDF, PDB), file size limits, and how UploadFile is handled. LLMs cannot infer that these accept file uploads from the schema alone.
Redundant `action` parameter: Both `validate_pose` and `redocking_validation` tools include an `action` parameter with enum values that duplicate the tool name itself. This violates DRY principle and adds cognitive overhead for LLMs choosing between tools. Remove the action parameter and rely on tool name selection.
No output schema documentation in tool definitions. The code references `format_results_to_mcp()` and returns objects with structure `{"object_id": ..., "data": {...}}` but the tool definitions do not document this output schema. LLMs cannot plan downstream operations without knowing return field names and types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 34 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
`context` tool is meta/introspective and not domain-functional. Tools returning metadata about the tool suite (e.g., MCP context) belong in a discovery mechanism, not as first-class tools. This inflates the tool count and confuses LLMs about what the server actually does.
Tool descriptions lack differentiation. `validate_pose` and `redocking_validation` have similar descriptions and both take similar parameters (ligand, protein, optional crystal). The descriptions do not clearly explain WHEN to use one vs. the other, forcing LLMs to guess based on parameter presence.
No error handling guidance in tool definitions. Descriptions do not explain retryable vs. non-retryable errors, what to do if files are malformed, or what constitutes a successful validation. LLMs receive raw output with no recovery path on failure.
Parameter `crystal_input` is marked optional in schema descriptions but semantics differ between tools. For `validate_pose`, crystal_input should be null; for `redocking_validation`, it is required. Tool definitions should explicitly state mutual exclusivity and parameter dependencies in descriptions, not rely on out-of-band logic.