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., "@lingo-mcp solve this LINGO model: MAX = 3X1 + 4X2 + 2X3; X1 + 2X2 + X3 <= 30; X2 <= 24; X3 <= 30;"
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.
An MCP server that lets an AI assistant solve optimization models with a locally installed LINGO 11, and read the results back as structured data.
It drives LINGO's own command-line executable (RunLingo.exe) with a generated
command script, so answers come from the real LINGO solver — not from a
reimplementation.
Zero npm dependencies (plain Node.js, stdio JSON-RPC)
Structured output: status, objective, variable values, reduced costs, row slacks, dual prices
Recognises infeasible and unbounded outcomes instead of silently reporting a number
Verified against an independent exact-arithmetic LP solver in the test suite
Node.js 18 or newer
LINGO 11 installed. The server looks at, in order: $LINGO_HOME, C:\LINGO11,
D:\LINGO11, C:\Program Files\LINGO11, C:\Program Files (x86)\LINGO11,
C:\LINGO, D:\LINGO, then the registry.
Only the solver is required. Lingo11.exe (the GUI) is not used; if it is missing
the server still works, it just reports gui: null.
Related MCP server: HiGHS MCP Server
git clone https://github.com/Han-maker-wp/lingo-mcp.git
cd lingo-mcp
node src/index.js # run it
npm test # 13 end-to-end tests against your local LINGOZCode / Claude Desktop / mcporter — add to your MCP config:
{
"mcpServers": {
"lingo": {
"command": "node",
"args": ["C:\\path\\to\\lingo-mcp\\src\\index.js"]
}
}
}If LINGO is installed somewhere unusual, set the LINGO_HOME environment
variable to that directory.
lingo_solveSolve a model and return the structured solution. Pass model (inline LINGO
source) or file_path (a .lng / .lg4 file).
// arguments
{
"model": "MAX = 3*X1 + 4*X2 + 2*X3;\nX1 + 2*X2 + X3 <= 30;\nX2 <= 24;\nX3 <= 30;",
"nonzero_only": false, // optional: report only nonzero variables
"timeout_ms": 120000 // optional
}// result
{
"ok": true,
"status": "optimal", // optimal | local_optimal | feasible
// | infeasible | unbounded | no_solution | null
"objective": 90,
"infeasibilities": 0,
"iterations": 0,
"variables": [ { "name": "X1", "value": 30, "reducedCost": 0 }, ... ],
"rows": [ { "row": 1, "slackOrSurplus": 90, "dualPrice": 1 }, ... ],
"errors": [],
"report": "...raw LINGO output..."
}ok is true only when a usable solution came back. An infeasible or unbounded
model is reported as such, with ok: false — the tool never invents an optimum.
Row numbering follows LINGO: row 1 is the objective function, constraints start at row 2.
lingo_run_commandsRun arbitrary LINGO command-window commands after loading a model, for analyses
lingo_solve does not structure (sensitivity, solution picture, raw rows).
{ "model": "MAX = X + 2*Y;\nX + Y <= 4;\nX - Y >= 3;",
"commands": ["GO", "RANGE 1", "PICTURE 1"] }lingo_statusDetected install path, LINGO version, license expiry, and solver memory.
lingo_list_samplesList the example models in the LINGO Samples folder, with an optional filter.
These are the behaviours that make scripted LINGO 11 work, each learned the hard
way. They are encoded in src/lingo.js.
RunLingo.exe takes a command script, not a model.
runlingo <script.ltf> executes a LINGO command script. The command set is a
small subset of the GUI command window: MODEL, TAKE, GO, SOLU, NONZ,
DIVERT, RVRT, LOOK, RANGE, PICTURE, DUAL, SMPS, QUIT, and so on.
There is no OPEN and no SOLVE; loading a file is TAKE and solving is GO.
Command scripts must use CRLF line endings. With bare LF, LINGO reads the whole file as one line and rejects every command as invalid.
A model file must start with MODEL: and end with END. Without the
MODEL: header, LINGO 11.0 fails to parse the objective line with
"Invalid input. A syntax error has occurred" — and if the model is left
completely empty, it instead reports the misleading
"The model generator ran out of memory". This server wraps bare models
automatically.
MODEL is for keyboard input, not files. It reads a model from stdin.
Using it on a redirected stdin fails; use TAKE for files.
Paths in scripts and models may use forward slashes. Backslashes are fine
but must be written literally — an escaped \a, \n or similar in the
generating layer turns into a control character and LINGO reports a
misleading "Unable to open file".
DIVERT must come before the commands whose output you want to keep.
Output produced before DIVERT goes to the terminal, not the report file.
The solution report is printed twice — once as part of GO, once for
SOLU. The parser de-duplicates it, so variables and rows are not doubled.
The evaluation build has a size ceiling (150 constraints, 300 variables, 30 integer variables). Larger models fail with error 108; that is a licensing limit, not a bug in this server.
The GUI (Lingo11.exe) needs the Visual C++ 2005 runtime (Microsoft.VC80.CRT
and Microsoft.VC80.MFC, x86). It refuses to start with "its side-by-side
configuration is incorrect" on a machine without them. The command-line solver
has no such dependency, so this server does not need them.
npm testThe suite spawns the server over stdio exactly as an MCP client would, then
cross-checks every optimal objective against test/exact-lp.js — a small
exact-rational LP solver (vertex enumeration over BigInt fractions) written
independently of LINGO. Agreement is therefore meaningful rather than a
tautology. It also asserts that the point LINGO reports is actually feasible and
scores exactly the optimum, so a merely-feasible answer cannot pass.
MIT
List the example models shipped in the LINGO Samples folder, optionally filtered by name.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Case-insensitive substring to filter sample names. |
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 conveys an implicitly safe, read-only listing operation and scopes it to the shipped Samples folder, but it says nothing about permissions, the shape of returned entries, ordering, or whether the list is paginated.
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?
A single front-loaded sentence with the resource stated first and the optional filter trailing. No filler or redundancy.
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 one-parameter, no-output-schema listing tool this is largely sufficient: it identifies the source folder and the filter behavior. The only gap is that return format and ordering are unspecified, which is minor given the tool's simplicity.
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?
There is a single parameter with 100% schema description coverage, so the schema already explains the case-insensitive substring filter. The description's 'optionally filtered by name' merely confirms optionality without adding syntax or matching-behavior detail beyond the schema; baseline 3 is 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 names a specific verb (List) and resource (example models in the LINGO Samples folder), so the agent knows exactly what the tool returns. It does not explicitly differentiate itself from the sibling tools (lingo_solve, lingo_run_commands, lingo_status), but the resource is distinct enough to be told apart.
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?
Usage is only implied: an agent can infer this is a discovery step for finding shipped example models, but there is no explicit when-to-use statement, no when-not-to-use condition, and no mention of the sibling tools it complements. The only guidance is the optional filter, which is really a parameter note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an arbitrary sequence of LINGO command-window commands against a model and return the raw output. Use this for analyses the structured solver does not cover, e.g. ["GO", "RANGE 1", "PICTURE 1"]. Commands run after the model is loaded.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | LINGO model source. | |
| commands | Yes | LINGO commands, e.g. ["GO", "SOLU", "RANGE 1", "DUAL 1"]. | |
| file_path | No | Path to a LINGO model file to load instead. | |
| timeout_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses sequencing ('commands run after the model is loaded') and output shape ('raw output'), but an arbitrary command-execution tool should also warn about side effects (e.g., PICTURE/RANGE writing files) and timeout behavior for the undocumented timeout_ms parameter. It is more informative than a blank description but leaves the riskiest traits unstated.
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?
Three short sentences, front-loaded with the core action before the usage guidance and sequencing note. No filler, though the trailing sentence could be folded in.
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?
A 4-parameter escape-hatch tool with no output schema; the description covers purpose, the alternative path, input format, and return shape ('raw output'), which is sufficient for correct invocation. It omits the model-vs-file_path relationship and timeout semantics, so it is not fully complete.
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 coverage is 75%, so most parameters are already documented. The description adds example command values (["GO", "RANGE 1", "PICTURE 1"]) that clarify format, but says nothing about how model and file_path relate or what timeout_ms controls. Baseline 3 is 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?
States a specific verb+resource: running a sequence of LINGO command-window commands against a model and returning raw output. It implicitly separates itself from the structured path by saying it covers analyses 'the structured solver does not cover', which points at lingo_solve without naming it. Clear, though the sibling reference is indirect.
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?
Gives an explicit condition for use ('analyses the structured solver does not cover') and a concrete example command list, which effectively steers an agent away from lingo_solve. No explicit when-not guidance or prerequisites (e.g., auth, environment) are given, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve a LINGO optimization model and return the structured solution (status, objective value, variable values with reduced costs, row slacks/surplus with dual prices). Accepts LINGO 11 model source inline or a path to a .lng/.lg4 file. The model may be written in plain LINGO 11 syntax; MODEL: and END are added automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | LINGO model source, e.g. "MAX = 3*X1 + 4*X2;\nX1 + X2 <= 10;\nX2 <= 6;". | |
| file_path | No | Path to an existing LINGO model file (.lng / .lg4) to solve instead of inline source. | |
| timeout_ms | No | Solver timeout in milliseconds. Default 120000. | |
| nonzero_only | No | Report only nonzero variable values. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does substantial work: it discloses the exact solution payload (status, objective, variables with reduced costs, slack/surplus with duals) and the auto-wrapping behavior of MODEL:/END. It stops short of disclosing failure handling (infeasible/unbounded models) or the dependency on a LINGO engine/license being available.
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?
Three sentences, front-loaded with the solve action, then input forms, then the wrapping caveat. Every sentence carries distinct information and the most decision-relevant fact leads.
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-param tool with no output schema and no annotations, the description is largely complete: it covers both input modes and compensates for the absent output schema by naming the returned fields. It omits error/solver-failure semantics, which are relevant for a solver tool.
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 coverage is 100%, so the baseline is 3; the description exceeds it by clarifying that 'model' can be written without MODEL:/END wrappers, which is genuine parameter behavior the schema does not state. It adds nothing extra for timeout_ms or nonzero_only, which the schema already documents.
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 and resource ('Solve a LINGO optimization model') and enumerates the output it produces. It is clearly distinguishable from siblings like lingo_run_commands and lingo_status, though it does not name any sibling explicitly to route between them.
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?
Usage is only implied: the agent can infer this is the tool to solve a model, and the two input forms (inline source vs .lng/.lg4 path) are noted. There is no explicit when-to-use/when-not guidance or comparison to lingo_run_commands, which an agent might confuse for a way to execute a model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the detected LINGO 11 installation: path, version, license expiry, solver memory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it partially does so: listing path, version, license expiry, and solver memory tells the agent this is an inspection/read operation with no mutation. However, it never explicitly states read-only behavior, side effects, or what happens when no LINGO 11 installation is found despite the word "detected" implying a conditional result.
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?
A single sentence with no filler, front-loaded with the verb and resource before the list of reported fields. Nothing is wasted, though the colon-list format leaves no room for the usage context that is missing.
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?
With no output schema, the description must convey return values, and it does enumerate the four key fields (path, version, license expiry, solver memory), which is genuinely useful. The remaining gap is conditional/error behavior when LINGO is absent, which an agent would need to know to handle failure.
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?
The tool takes zero parameters (schema is an empty object at 100% coverage), so there is nothing to disambiguate. Baseline of 4 applies per the rubric for 0-parameter tools.
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 ("Report") and resource ("detected LINGO 11 installation") and enumerates exactly what is reported: path, version, license expiry, solver memory. That is enough to tell it apart from lingo_solve, lingo_run_commands, and lingo_list_samples, which all act on models rather than on the installation itself. It stops just short of 5 because it never explicitly names those siblings as distinct.
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?
There is no when-to-use guidance, no prerequisite (e.g., whether LINGO must already be detected), and no mention of alternatives. The only hint is the phrase "detected installation," which implies a diagnostic role but leaves the agent to infer it.
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.
v0.1.0lingo_list_sampleslingo_run_commandslingo_solvelingo_statusScored across 4 tools
Each tool has a clearly distinct purpose: lingo_solve returns structured solutions, lingo_run_commands runs raw commands as an escape hatch, lingo_status checks the installation, and lingo_list_samples lists examples. The descriptions explicitly clarify when to use the generic command runner versus the structured solver, leaving no meaningful overlap.
All names use snake_case with a consistent 'lingo_' prefix, which makes them predictable and easy to parse. However, the verb/noun pattern is not uniform (e.g., lingo_solve is a bare verb, lingo_status is a noun, while run_commands and list_samples follow verb_noun), so it falls short of a perfect pattern.
Four tools is well-scoped for a LINGO execution server. The core solve tool, a flexible command runner, an environment status check, and a sample lister each earn their place without redundancy or bloat.
The surface covers the main workflows: solving models, executing arbitrary LINGO commands, checking installation details, and discovering samples. Minor gaps exist (e.g., no structured model validation or dedicated variable/constraint introspection), but lingo_run_commands provides a workaround for nearly any missing operation.
Optimize crew and workforce schedules, resource allocation, and routing with linear and mixed-inte…
AI-callable calculators and engineering models with real formulas. No hallucinated math.
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
FinOps for Google Cloud: size 1- and 3-year CUD commitments to known demand. Also solves LP/MIP.
