Loading ToolBench
Mathematical optimization MCP server with PuLP and OR-Tools support for linear programming, integer programming, assignment, transportation, knapsack, routing, scheduling, and portfolio optimization problems.
MCP Optimizer has 10 tools with moderate schema completeness but significant issues with description depth, parameter documentation, and error handling guidance. Most tools have basic descriptions (20-50 chars) that lack actionable context for LLM selection. Parameter descriptions exist but are minimal (e.g., 'List of workers' without explaining what constitutes a valid worker object). No output schemas are documented, critical for chaining and result extraction. Error recovery guidance is absent across all tools. The assignment/transportation/knapsack solvers lack proper tool registration evidence (inferred from file references but not explicitly visible in the source code provided). These are HARD SCORING penalties per the rubric.
Optimize asset allocation using Modern Portfolio Theory to maximize return for given risk level
Solve assignment problems to minimize or maximize total cost when assigning workers to tasks
Solve integer programming problems with binary and general integer variables
Solve 0/1 knapsack and bounded knapsack problems to maximize value subject to weight constraints
Solve linear programming problems with support for maximization/minimization, constraints, variable bounds, and sensitivity analysis
Solve production planning problems to optimize production schedules and inventory levels
Solve vehicle routing and traveling salesman problems to find optimal routes
Solve job scheduling problems to minimize makespan or other scheduling objectives
Output schemas are completely undocumented. None of the 10 tools document what fields are returned, data types, or how results should be structured. LLMs cannot plan downstream operations or extract fields for chaining without knowing the response shape.
Tool descriptions are too brief (10-30 chars) and lack context for LLM selection. 'Solve a linear programming problem' does not explain WHEN to use this vs integer programming, what input constraints are, or what constitutes valid input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 12 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Solve transportation problems to minimize cost of shipping goods from suppliers to customers
Validate optimization problem inputs for feasibility and correctness
Parameter descriptions are minimal and lack actionable constraints. 'List of workers' (assignment problem) does not specify what format workers must be in, what fields are required, or what data types are valid. Same issue across 'costs' (matrix format?), 'constraints' (array of what?), and 'processing_times'.
Complex parameter objects (objective, variables, constraints in linear/integer programming) lack documented schemas. What is the structure of 'objective'? What fields must 'variables' contain? What do constraint array items look like? Without sub-schemas, LLMs cannot construct valid requests.
No error handling or recovery guidance. No tool documents what happens on infeasible problems, unbounded solutions, timeouts, or invalid input. LLMs receive only success/failure with no path to debug or recover. Pattern:recovery-guide requires 'Try X tool first' or 'Call Y to fix this.'
Assignment, transportation, knapsack, routing, and scheduling tools lack explicit tool registration in source code provided. File references (fallback_solver.py, etc.) suggest implementation exists, but tool definition code is not visible. Per hard scoring rule: 'If you cannot see the actual tool definition, cap at 50.' Inferred tools cannot reliably verify schema structure.
No tool accepts pagination parameters (limit, offset, page_size) or declares result size limits. If optimization results include large matrices or lists, truncation behavior is undocumented. LLMs may be flooded with context, risking exhausted token limits.
No confirmation or dry-run pattern for destructive operations. While these are optimization solvers (not deletions), if production planning or financial optimization results are used to execute real purchases/production, no safe preview mechanism is offered.
No solver parameter validation. 'solver' param accepts GLPK, CBC, GUROBI, CPLEX but no enum is declared, no description clarifies which is default or available at runtime, no guidance if a requested solver is unavailable. LLM has no constraint on valid choices.
validate_optimization_input tool lacks clarity on what validation it performs and what it returns. Is it a discovery tool or pre-flight check? Does it return validation errors, warnings, or a pass/fail? Description does not differentiate it from the solve_* tools or explain when to call it first.