Loading ToolBench
MCP Server for Cyclic Peptide Tools - Provides synchronous and asynchronous APIs for CYC_BUILDER cyclic peptide design tools including seed preparation, structure analysis, peptide generation via Monte Carlo Tree Search, and post-processing
This server demonstrates moderate definition quality with significant gaps. All 10 tools are explicitly registered via @mcp.tool() decorators with names, descriptions, and input schemas. However, most parameter descriptions are minimal or missing, output schemas are not documented, and error handling lacks recovery guidance. Naming follows the verb_noun pattern well (get_*, list_*, submit_*, prepare_*, analyze_*, post_process_*, cancel_*), but parameter schemas and descriptions need substantial improvement for production readiness. The server falls into the 'fair' category with noticeable gaps in schema documentation and error guidance.
Analyze cyclic peptide structure and calculate binding scores (fast operation). Performs comprehensive analysis of peptide-receptor binding including interface scoring, shape complementarity, and interaction energies.
Cancel a running cyclic peptide computation job.
Get log output from a running or completed job.
Get the results of a completed cyclic peptide computation job.
Get the status of a submitted cyclic peptide computation job.
List all submitted cyclic peptide computation jobs.
Post-process and rank generated cyclic peptides (fast operation). Filters, clusters, and ranks peptide candidates based on binding scores and structural diversity to identify the most promising designs.
Output schemas are not documented. Tools return dicts with status/result/error fields, but the exact structure of nested results (e.g., what fields are in result for analyze_structure, get_job_result, post_process_peptides) is never specified. LLMs cannot plan downstream operations without knowing what data is available.
Error handling lacks recovery guidance. All tools catch exceptions and return {"status": "error", "error": str(e)}, but provide no guidance on what the LLM should do next (retry? ask user? try alternative tool?). Errors are not categorized as retryable vs. fatal.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Prepare seed peptides for cyclic peptide design (fast operation). Extracts structural binding motifs from receptor and ligand structures to create seed peptides for the CYC_BUILDER design process.
Submit batch seed preparation job for multiple receptor-motif pairs. Processes multiple receptor-motif combinations in parallel to generate seed peptides for large-scale cyclic peptide design campaigns.
Submit a cyclic peptide generation job using Monte Carlo Tree Search. This task uses MCTS to generate cyclic peptides from seed structures. In real implementation, this would take >10 minutes due to MCTS complexity.
Parameter constraints are not declared. 'top_k', 'mcts_levels', 'num_simulations', 'peptide_length', 'top_k_matches', 'tail' lack minimum/maximum bounds. No description states valid ranges (e.g., tail: 0 - 1000). LLMs can pass invalid values without validation.
No pagination or result limits documented for list_jobs. Tool may return unbounded job lists that exhaust context window. No mention of page size, offset, or total count in the return schema.
cancel_job lacks confirmation/dry-run pattern. Cancelling a long-running job is irreversible; tool should support a confirmation step or explicit --force flag to prevent accidental cancellation.
File path parameters (receptor_file, motif_file, output_dir, input_dir, seed_file, peptide_file) accept arbitrary strings with no validation. Tool descriptions should specify: file must exist? must be readable? expected format (PDB)? path traversal attacks are possible.
Parameter descriptions are generic or missing detail. E.g., 'status' in list_jobs is listed as 'Filter by status (pending, running, completed, failed, cancelled)', should be an enum constraint, not a free-form string. 'receptor_file' lacks format hints (PDB? path must exist?).
Batch operations (submit_batch_seed_preparation) accept arrays but lack per-item error handling. If one receptor-motif pair fails, the entire job response is unclear. Should return per-item success/failure status.