Loading ToolBench
MCP server for genetic algorithm-based idea generation and evolution using parallel LLM workers
The server provides 10 tools with generally complete JSON Schema definitions and reasonable parameter coverage. Tool names follow verb-noun patterns (create_session, run_generation, get_progress, etc.), which is good. However, descriptions vary significantly in quality, some are detailed (create_session: 252 chars with clear Args/Returns structure), while others are minimal (run_generation: only 46 chars, 'Run the next generation of evolution for a session.'). Critical parameter descriptions are present for most tools, but several tools lack output schema documentation. Error handling guidance is absent, and tool compositions do not clearly explain chaining requirements. The schema definitions use Pydantic models with proper types and constraints (ge, le, minimum, maximum), but output structures are not explicitly documented. Security concerns are moderate, no obvious credential exposure in visible parameters, but no audit logging or permission gates are evident in the code sample.
Create an advanced GA session with GPU optimization and advanced features. This tool provides access to GPU-accelerated genetic algorithms with: - Advanced selection strategies (Boltzmann, SUS, rank-based) - Fitness sharing and crowding distance for diversity - Multi-population evolution with migration - Adaptive parameter control - Batch processing on GPU for efficiency Returns: Session information with advanced configuration details
Create a new idea generation session. Args: prompt: The prompt to generate ideas for mode: Evolution mode - 'single_pass' (rank top-K) or 'iterative' (genetic algorithm) population_size: Number of ideas per generation (initial size if adaptive_population=True) top_k: Number of top ideas to return generations: Number of generations (for iterative mode) fitness_weights: Weights for fitness calculation (relevance, novelty, feasibility) models: List of LLM models to use client_generated: Whether the client generates ideas instead of using LLM workers adaptive_population: Enable adaptive population size based on diversity and performance min_population: Minimum population size for adaptive adjustment max_population: Maximum population size for adaptive adjustment diversity_threshold: Diversity threshold below which population size increases plateau_generations: Generations without improvement to trigger population increase Returns: Session information including session_id
Get detailed optimization report for a session.
Minimal tool descriptions. 'run_generation' (46 chars), 'get_progress' (40 chars), 'get_session' (40 chars), and 'get_optimization_stats' (30 chars) fall below the 60-char baseline for meaningful LLM context. These descriptions provide no WHEN/WHY guidance, forcing LLMs to infer purpose from context alone.
No documented output schemas. The code shows Pydantic input models (CreateSessionSchema, RunGenerationSchema) but the source does not reveal return type definitions. LLMs cannot reason about downstream tool chaining (e.g., what fields does create_session() return? Can I pass session_id directly to run_generation?) without explicit response schemas.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Get optimization statistics for the current session.
Get progress information for an ongoing session.
Retrieve session information.
Inject manually provided ideas into a session.
Run multiple evolution experiments in batch with GPU acceleration. This tool enables efficient parallel processing of multiple experiments, maximizing GPU utilization through batched operations.
Run the next generation of evolution for a session.
Update fitness weights for a session.
No error handling or recovery guidance. Tool descriptions do not indicate what errors are retryable, what user actions are needed, or what to do if a session is not found. Absence of patterns like 'If session not found, call create_session() first' or 'This operation is idempotent' forces agents to guess recovery strategies.
Weak parameter descriptions. Parameters like 'mode' in create_session describe allowed values ('single_pass' or 'iterative') but do not explain WHEN to use each mode, what's the latency/quality tradeoff? When should an agent choose iterative over single_pass? Similar issue with 'optimization_level' (described as 'basic', 'enhanced', 'gpu', 'full' but no guidance on when to pick each).
No tool composition or chaining documentation. The relationship between create_session and run_generation is implicit, users must infer that run_generation requires a session_id from create_session. Descriptions do not state 'Call create_session first, then run_generation with the returned session_id.' This forces LLMs to discover the pattern through trial and error.
Missing tool annotations. The rubric expects tools to declare readOnlyHint, destructiveHint, and idempotentHint (current MCP spec 2026-07-28). 'create_session', 'run_generation', 'set_fitness_weights', 'inject_ideas', and 'run_batch_experiments' are marked as 'WRITE' risk (data mutation), but there is no evidence in the visible code that these are annotated with destructiveHint or idempotentHint flags. This prevents clients from understanding retry safety and destructiveness.
Parameter validation and constraints are incomplete. For example, 'fitness_weights' is described as 'Weights for fitness calculation: relevance, novelty, feasibility (must sum to 1.0)' but no constraint is visible in the schema to enforce the sum-to-1.0 invariant. Similarly, 'models' parameter accepts a list but does not validate model names or provide a discovery tool to list available models. Agents cannot know valid values without trial and error.
Over-parameterized tools. 'create_session' has 17 parameters, exceeding the 4 - 8 baseline. While Pydantic defaults mitigate this, the cognitive load for LLMs is high. Consider splitting into simpler variants: 'create_basic_session(prompt, population_size, generations)' and 'create_advanced_session(prompt, ...)' with advanced options. Current structure forces LLMs to reason about combinations of min_population, max_population, diversity_threshold, plateau_generations that may not apply to simple use cases.