Loading ToolBench
BY (Blatant-Why) is a protein design agent for Claude Code featuring multi-agent antibody & protein binder design with cloud compute and lab integration. It consists of multiple specialized MCP servers: adaptyv (lab submission), campaign (state management), cloud (compute orchestration), knowledge (learning), and local_compute (local execution).
This server has serious definition quality issues. While it provides 15 tools with some structure, many lack proper descriptions, parameters are often underspecified, and output schemas are largely undocumented. The codebase shows careful attention to security (3-layer safety gates for lab submissions, approval files, TTL-based confirmation codes), but the tool definitions themselves do not meet production standards. Most tools fall into the 30-50 range individually. Tool descriptions vary from adequate (adaptyv_prepare_submission, adaptyv_confirm_submission) to vague (campaign_transition, cloud_submit_job). Parameter schemas are present but lack type definitions in many cases. Output schemas are almost never documented. Error handling is minimal, most tools lack recovery guidance.
Confirm and submit a prepared lab submission to Adaptyv Bio. Requires the confirmation code from adaptyv_prepare_submission and user approval via /approve-lab in the TUI.
Estimate the cost of an Adaptyv Bio experiment. Pure computation -- no API call, no safety gate required.
Prepare a lab submission to Adaptyv Bio for review. This does NOT submit anything. It validates the sequences, generates a confirmation code, and stores the payload for later confirmation. The agent must then call adaptyv_confirm_submission with the returned code to actually submit. The user must also have approved the submission via /approve-lab in the TUI.
Create a new campaign with directory structure and initial state.
Estimate campaign cost based on tool, tier, and parameters.
Log a campaign decision with reasoning and alternatives.
Output schemas are almost never documented. Tools return structured data but LLMs cannot predict what fields to expect. For example, cloud_list_providers describes listing providers with 'status, quota, and capability details' but the schema shows no return type specification. This forces LLMs to guess at field names and makes tool chaining impossible.
campaign_transition has only a 2-sentence description ('Transition campaign to a new status with validation of valid state transitions.'). This is vague, the LLM cannot infer when to call it instead of other campaign tools, what state transitions are valid, or what happens on invalid transitions. Description is well under the 10 - 1024 character guideline minimum actionable detail.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Transition campaign to a new status with validation of valid state transitions.
Get the status of a submitted cloud compute job.
List available compute providers with status, quota, and capability details. Reads ~/.by/environment.json for Tamarind config, pings each SSH host from ~/.by/config.json, and checks CUDA_VISIBLE_DEVICES for local GPU availability.
Submit a design job to a cloud or local compute provider.
Find similar past campaigns using keyword search with MMR diversity re-ranking.
Get ranked scaffolds by performance across historical campaigns.
Store a completed campaign outcome in the knowledge base. Embeds a text summary for semantic search and stores full data as metadata.
Detect which BY tools are installed locally and their availability status.
Run a design job on local GPU or remote SSH server.
Many parameter descriptions are generic or missing detail. Example: campaign_estimate_cost has 'tool' parameter described as 'Design tool (boltzgen, pxdesign, protenix)', missing whether enum constraint is enforced, whether this is the ONLY valid set, or what happens if an invalid value is passed. cloud_submit_job 'config' parameter says 'Tool configuration (JSON or file path)', unclear format, no validation guidance, no example structure.
No error handling guidance. Tools lack recovery suggestions. Example: cloud_submit_job could fail due to provider unavailable, invalid tool config, missing output directory, or resource exhaustion, but the tool definition provides no categorization (retryable vs user-fixable vs fatal) or guidance for the LLM.
Parameter types are sometimes missing from schema definitions. While most tools show type constraints in descriptions, some lack explicit JSON Schema type declarations. For example, 'config' in cloud_submit_job and local_compute_run_design is described as 'JSON or file path' but the actual type (string) and validation rules are not formally specified.
Pagination and result limits are not documented. knowledge_query_similar has a top_k parameter defaulting to 5, but no mention of maximum or what happens if top_k=1000 is passed. cloud_list_providers does not specify how many providers it returns or whether results are paginated. Large uncapped results could blow context windows.
Tool composition: adaptyv_prepare_submission and adaptyv_confirm_submission are well-separated (2-step gate), but there is no documented way for the LLM to know what fields adaptyv_prepare_submission returns (e.g., confirmation_code structure, expiration time, or other metadata). The output schema is missing, breaking the tool chain.
knowledge_store_campaign accepts 'parameters' and 'outcomes' as object types but does not define their structure. An LLM has no way to know which keys are valid ('scaffold', 'seeds', 'temperature' are hints in the description, but not a formal schema). This invites hallucinated fields and silent failures.