Loading ToolBench
MCP Server for chai-1 protein structure prediction. Provides both synchronous and asynchronous (submit) APIs for all tools.
Server has 9 tools with basic definitions and schemas present, but suffers from significant gaps in parameter descriptions, output documentation, and error handling guidance. All tools have names starting with action verbs (good), and most have descriptions, but descriptions are often generic and lack depth. Parameters are defined with types but many lack actionable descriptions. Output schemas are not documented. Error handling is minimal, most tools return bare dictionaries without recovery guidance. The tool set shows reasonable separation of concerns (job management, validation, sync/async prediction, composition), but lacks the polish and LLM-optimization expected of production-grade tools. Baseline: median production tools score 194 chars for descriptions and include per-tool output schema documentation; this server's descriptions average ~150 chars but omit output documentation entirely.
Analyze amino acid composition and properties of sequences in a FASTA file. Provides quick analysis without running prediction. Runtime: ~1-10 seconds
Cancel a running job.
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.
Synchronous prediction for very small peptides/sequences. Only processes sequences up to max_length amino acids for quick results. Runtime: ~30 seconds to 2 minutes for very small sequences
Output schemas not documented. No tool explicitly documents what fields it returns or their types. LLMs cannot infer downstream field names (e.g., does list_jobs return 'jobs' or 'job_list'? Is 'status' a string or enum?). This forces agents to guess and risks broken tool chains.
Error handling lacks recovery guidance. Tools return bare dicts like {'status': 'error', 'error': '...'} but do not guide the LLM on what to do next. Example: get_job_result returns 'not completed', should hint to call get_job_status first, or suggest a retry interval.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 19 | - | v1 |
Submit basic protein structure prediction for background processing. This performs structure prediction from FASTA sequences using Chai-1. Typical runtime: 3-30+ minutes depending on sequence length and GPU.
Validate a FASTA file format and contents for structure prediction. Performs quick validation of FASTA files before prediction. Runtime: ~1-5 seconds
Parameter descriptions are inconsistent in depth. 'status' param in list_jobs has a decent description ('Filter by status...'), but 'tail' in get_job_log is minimal ('Number of lines from end'). No explanation of why 0 means 'all', LLMs may not infer this non-obvious constraint.
Tool descriptions for job management tools (get_job_status, get_job_result) are brief and lack context on when to use each. Should clarify the job lifecycle: submit → pending → running → completed, and explain which tool to call at each stage.
validate_fasta_file and analyze_sequence_composition are discovery tools but lack guidance on when to call them relative to predict_small_peptide and submit_basic_prediction. Should state: 'Call this first to understand sequence composition before prediction.'
No pagination/result limiting documented. list_jobs returns all jobs with no limit or offset params. If a user has thousands of jobs, this response will explode the context window. Should add limit (default 20-50) and offset/next_cursor params.
predict_small_peptide uses 'max_length' as both a constraint and a parameter. If a user's sequence exceeds max_length, the error says 'Sequence too long, use submit_basic_prediction instead.' This is good recovery guidance, but max_length should be an enum or have a clear range documented (e.g., 5-50 amino acids). Currently no min bound stated.