Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Opti-MCP Solve a linear program to maximize profit: 3x+5y with constraints x<=4, 2y<=12, 3x+2y<=18"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides tools for solving optimization problems using Google OR-Tools. This server enables AI assistants to solve Linear Programming (LP), Integer Programming (IP), Mixed-Integer Programming (MIP), and classic combinatorial optimization problems.
Linear Programming: Solve continuous optimization problems with linear constraints
Integer/Mixed-Integer Programming: Solve optimization problems with integer decision variables
Knapsack Problem: Solve the classic 0/1 knapsack problem efficiently
Built on Google OR-Tools for robust, production-grade optimization
Simple JSON-based interface
Related MCP server: MCP Optimizer
Node.js 18 or higher
Python 3.8 or higher
Google OR-Tools Python library
Clone this repository:
git clone <your-repo-url>
cd opti-mcpInstall Node.js dependencies:
npm installInstall Python dependencies:
pip install ortoolsBuild the TypeScript code:
npm run buildAdd to your MCP settings file (e.g., claude_desktop_config.json):
{
"mcpServers": {
"opti-mcp": {
"command": "node",
"args": ["/absolute/path/to/opti-mcp/dist/index.js"]
}
}
}Solves linear programming problems where all variables are continuous.
Example: Production Planning
{
"objective": {
"coefficients": [3, 5],
"maximize": true
},
"constraints": [
{
"coefficients": [1, 0],
"upper_bound": 4
},
{
"coefficients": [0, 2],
"upper_bound": 12
},
{
"coefficients": [3, 2],
"upper_bound": 18
}
],
"variable_bounds": [[0, "Infinity"], [0, "Infinity"]]
}This maximizes 3x₀ + 5x₁ subject to:
x₀ ≤ 4
2x₁ ≤ 12
3x₀ + 2x₁ ≤ 18
x₀, x₁ ≥ 0
Solves integer or mixed-integer programming problems.
Example: Assignment Problem
{
"objective": {
"coefficients": [1, 2, 3, 4],
"maximize": false
},
"constraints": [
{
"coefficients": [1, 1, 0, 0],
"lower_bound": 1,
"upper_bound": 1
},
{
"coefficients": [0, 0, 1, 1],
"lower_bound": 1,
"upper_bound": 1
}
],
"variable_bounds": [[0, 1], [0, 1], [0, 1], [0, 1]],
"integer_variables": [0, 1, 2, 3]
}This solves an assignment problem where variables must be binary (0 or 1).
Solves the 0/1 knapsack problem.
Example: Item Selection
{
"values": [360, 83, 59, 130, 431, 67, 230, 52, 93, 125],
"weights": [7, 0, 30, 22, 80, 94, 11, 81, 70, 64],
"capacity": 850
}Maximizes total value while keeping total weight ≤ capacity.
Minimize cost while meeting nutritional requirements:
{
"objective": {
"coefficients": [2.5, 1.8, 3.0, 0.5],
"maximize": false
},
"constraints": [
{
"coefficients": [10, 5, 8, 2],
"lower_bound": 50
},
{
"coefficients": [3, 8, 1, 6],
"lower_bound": 30
},
{
"coefficients": [5, 4, 7, 3],
"lower_bound": 40
}
]
}Pack items into minimum number of bins:
{
"objective": {
"coefficients": [1, 1, 1],
"maximize": false
},
"constraints": [
{
"coefficients": [5, 0, 0],
"upper_bound": 10
},
{
"coefficients": [0, 7, 0],
"upper_bound": 10
},
{
"coefficients": [0, 0, 4],
"upper_bound": 10
}
],
"integer_variables": [0, 1, 2]
}All solvers return a JSON response with:
{
"status": "OPTIMAL",
"objective_value": 34.0,
"solution": [2.0, 6.0],
"solve_time_ms": 15
}status: OPTIMAL, INFEASIBLE, UNBOUNDED, or UNKNOWN
objective_value: The optimal value found (null if not optimal)
solution: Array of variable values (null if not optimal)
solve_time_ms: Time taken to solve in milliseconds
For knapsack problems:
{
"status": "OPTIMAL",
"total_value": 1030,
"total_weight": 850,
"selected_items": [0, 2, 3, 4],
"capacity": 850
}# Watch mode for development
npm run dev
# Build for production
npm run build
# Run the server
npm startThe MCP server:
Receives optimization problems via MCP tool calls
Translates them into Python scripts using OR-Tools
Executes the Python scripts
Returns formatted results
Requires Python 3.8+ with OR-Tools installed
Currently uses GLOP for LP and SCIP for MIP (requires SCIP installation for best performance)
Large problems may take significant time to solve
MIT
Contributions welcome! Please open an issue or PR.
Solve an integer programming (IP) or mixed-integer programming (MIP) problem using Google OR-Tools. Variables can be constrained to integer values.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | Yes | Linear objective function coefficients | |
| constraints | Yes | List of linear constraints | |
| variable_bounds | No | Bounds for each variable [lower, upper]. Defaults to [0, Infinity] | |
| integer_variables | No | Indices of variables that must be integers (0-indexed). If omitted, all variables are integers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the engine (OR-Tools) and that variables can be integer-constrained, but says nothing about optimality guarantees, time limits, infeasibility/unbounded handling, or return format — all material for a solver invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and engine. Minor redundancy in restating 'integer values' after already saying 'integer programming', but no wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter solver with nested objects, no annotations, and no output schema, the description is thin. It omits return shape (solution values, status, objective value) and edge-case behavior, leaving the agent without information it cannot derive from the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the nested objective, constraints, variable_bounds, and integer_variables parameters are already well documented in the schema. The description adds no parameter syntax or default details beyond it, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (solve) and resource (integer/mixed-integer programming problem) and names the underlying engine (Google OR-Tools). It is clear what the tool does, though it does not explicitly distinguish itself from the sibling solvers solve_linear_program and solve_knapsack.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given. The phrase 'integer or mixed-integer' implicitly separates it from solve_linear_program, but the agent is never told to prefer this tool over that sibling, nor when knapsack-style problems should route elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve the classic 0/1 knapsack problem: maximize value subject to weight capacity constraint.
| Name | Required | Description | Default |
|---|---|---|---|
| values | Yes | Value of each item | |
| weights | Yes | Weight of each item | |
| capacity | Yes | Maximum weight capacity of the knapsack |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It states the optimization goal but omits critical traits: whether the solution is exact, expected input size limits, runtime characteristics, and what the return value contains. This is insufficient for a solver tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the problem class and the optimization objective. It contains no redundant or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a solver with no annotations and no output schema, the description is too sparse. It fails to explain the return value (e.g., optimal value and/or selected items) and provides no behavioral context about the solving process, leaving the agent with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (values, weights, capacity) with clear meanings. The description adds no additional parameter semantics or formatting details beyond what the schema provides, making the baseline of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Solve the classic 0/1 knapsack problem', and specifies the objective (maximize value) and constraint (weight capacity). It does not, however, differentiate itself from sibling solvers like solve_linear_program or solve_integer_program, leaving the agent to infer that this is the specialized tool for knapsack problems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or the sibling solvers, leaving the agent without any explicit routing cues beyond the problem name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve a linear programming problem using Google OR-Tools. Maximizes or minimizes a linear objective function subject to linear constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | Yes | Linear objective function coefficients | |
| constraints | Yes | List of linear constraints | |
| variable_bounds | No | Bounds for each variable [lower, upper]. Defaults to [0, Infinity] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It states the operation is a solve but says nothing about optimality guarantees, solver status on infeasible/unbounded problems, what happens with malformed or empty constraints, or runtime characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences that front-load the verb and resource, with the maximize/minimize capability summarized immediately after. No filler or restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should describe the return value (solution vector, objective value, status) but omits it entirely. For a nested, multi-parameter solver call whose result shape is non-obvious, this is a significant omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents objective, constraints, bounds, and default semantics (including the Infinity convention). The description adds no parameter meaning beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Solve a linear programming problem') and the solver engine plus objective direction, so the purpose is unambiguous. It does not explicitly distinguish itself from solve_integer_program or solve_knapsack, which is the only thing keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus the sibling solvers (e.g., continuous variables only vs integer/knapsack), nor any mention of model-size limits or infeasibility preconditions. The agent must infer the choice from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0solve_integer_programsolve_knapsacksolve_linear_programScored across 3 tools
The three tools target distinct problem classes (LP, IP/MIP, knapsack), and descriptions make the distinct semantics clear. However, knapsack is technically a special case of integer programming, and LP is a relaxation of MIP, so boundaries overlap enough that a user might wonder which solver to pick.
All tools follow a clean solve_<problem> verb_noun pattern: solve_linear_program, solve_integer_program, solve_knapsack. The convention is predictable and readable throughout.
Three tools is thin for a general optimization server; it covers only LP, IP/MIP, and a single specialized problem. The count is borderline rather than well-scoped for the apparent breadth of the domain.
Core LP and MIP solving are covered, plus one special case, giving basic coverage with no dead ends for those tasks. However, common optimization operations such as constraint programming, quadratic/nonlinear programming, assignment/transportation, and scheduling are absent, leaving notable gaps.
Optimize crew and workforce schedules, resource allocation, and routing with linear and mixed-inte…
Vehicle routing, 3-D packing, cutting stock, rostering and knapsack with OR-Tools. 7 of 11 free.
Field operations on a deterministic solver — run jobs, crews & fleet from Claude or ChatGPT.
FinOps for Google Cloud: size 1- and 3-year CUD commitments to known demand. Also solves LP/MIP.
