Loading ToolBench
MCP Server for Cyclic Peptide Design Tools based on AlphaFold. Provides tools for structure prediction, fixed backbone design, de novo hallucination, binder design, and complex prediction with async job queue management.
The server provides 12 well-structured tools for cyclic peptide design with consistent naming, comprehensive parameter schemas, and reasonable descriptions. However, there are notable gaps in output schema documentation, error handling guidance, and parameter validation. Tool names follow verb_noun patterns (get_, submit_, cancel_, list_) consistently. All tools have docstrings exceeding 20 characters. Most parameters include type and description. The main weaknesses are: (1) Output schemas are not documented, callers cannot predict return structure; (2) Error handling lacks recovery guidance and categorization; (3) Parameter constraints are described in prose but not formally defined (enums, min/max); (4) No indication of idempotency, retry safety, or side effects for WRITE operations; (5) Tool descriptions lack context on when to use a tool vs. alternatives (e.g., distinction between submit_hallucination and submit_fixbb_design is unclear without domain knowledge).
Cancel a pending or running cyclic peptide design job.
Get log output from a running or completed job.
Get the results of a completed cyclic peptide design job.
Get the status of a submitted cyclic peptide design job.
Get current job queue status.
List all submitted cyclic peptide design jobs.
Resubmit a failed or cancelled job. Creates a new job with the same parameters as the original. Useful for retrying jobs that failed due to server restarts or transient errors.
Output schemas are not documented for any tool. Callers cannot predict return structure (e.g., is get_job_status returning a dict with 'status', 'timestamp', 'queue_position'? Unknown). This forces LLMs to guess field names and rely on implicit assumptions.
WRITE operations (submit_*, cancel_job, resubmit_job) lack idempotency hints and side-effect documentation. LLMs cannot determine if a tool is safe to retry on ambiguous failures or will cause duplicate submissions. The description of submit_structure_prediction does not state 'This creates a new job', it's inferred from context.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Submit a cyclic peptide binder design job for a target protein. Designs cyclic peptides that bind to protein targets using motif grafting and sequence optimization.
Submit a cyclic peptide + target protein complex structure prediction job. Predicts the 3D structure of a cyclic peptide bound to a target protein using AlphaFold-multimer with cyclic offset constraints applied only to the peptide chain.
Submit a fixed backbone sequence design job for a cyclic peptide. Redesigns the amino acid sequence to maximize folding propensity for a given cyclic peptide backbone structure using categorical cross-entropy loss between target and predicted distograms.
Submit a de novo cyclic peptide hallucination job. Simultaneously generates a new cyclic peptide structure AND its corresponding sequence from scratch. Uses AlphaFold to predict well-structured peptides with high confidence scores.
Submit a cyclic peptide structure prediction job. Predicts the 3D structure of a cyclic peptide from its amino acid sequence using AlphaFold with cyclic offset constraints for head-to-tail cyclization.
Parameter constraints are described in prose, not formally defined. E.g., list_jobs documents 'status' as 'Filter by status (pending, running, completed, failed, cancelled)' but does not declare it as an enum constraint in the schema. Submit_binder_design's 'target_hotspot' parameter format ('e.g., "1-10,12,15"') is not formally specified, LLMs may pass invalid formats.
Error handling is absent. No tool description states what happens on failure (e.g., invalid sequence, PDB file not found, job timeout). Descriptions do not offer recovery guidance (e.g., 'If job_id is invalid, call list_jobs() to find the correct ID'). LLMs cannot self-correct or plan fallbacks.
Tool selection is ambiguous for domain experts. The difference between submit_structure_prediction, submit_fixbb_design, and submit_hallucination is not obvious from descriptions alone. An LLM must infer: 'structure_prediction = given sequence, predict structure', 'fixbb_design = given backbone, redesign sequence', 'hallucination = generate both from scratch'. This disambiguation should be explicit in each description, e.g., 'Use this when you have a target backbone structure. To generate from sequence, use submit_structure_prediction. To generate both, use submit_hallucination.'
Numeric parameters lack min/max constraints. E.g., num_recycles (default 6) has no stated range, can it be 0? 100? 1000? rg_weight (default 0.1) has no bounds. soft_iters (default 0) could be negative. LLMs may pass absurd values that cause runtime errors or timeouts.
Pagination is absent. list_jobs has no limit, offset, or next_cursor parameters. If a user has thousands of jobs, the response could be massive, wasting tokens and context. The description does not state a result limit.
Return values for submit_* tools are not documented. The description states 'Returns: Dictionary with job_id for tracking', but what other fields are in this dict? Is there a queue_position? An estimated_time? Without output schema, LLMs cannot plan downstream calls or extract relevant data reliably.