Decisify
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BASE_URL | No | Optional base URL override for the LLM provider API. Use for OpenRouter (https://openrouter.ai/api/v1) or Azure endpoint (https://<resource>.openai.azure.com/openai/v1). | |
| OPENAI_API_KEY | Yes | Your OpenAI-compatible API key (e.g., OpenAI, OpenRouter, Azure, or local vLLM/Ollama). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| decompose_optimization_queryA | Analyzes optimization queries or problems. If the problem is high-level or open-ended, breaks it down into a step-by-step plan using individual modular tools (clarify_requirements, review_requirements, formulate_math_model, review_math_model, generate_model_code, review_model_code, execute_model_code, review_execution_result). NEVER recommends using the overall end-to-end workflow tool. If the request is already specific, recommends only the single required tool. |
| clarify_requirementsB | Analyzes raw user optimization problem descriptions to identify missing requirements, implicit constraints, sets, parameters, decision variables, bounds, and objectives. Produces a structured, unambiguous specification. |
| review_requirementsA | Reviews a clarified problem specification for completeness, consistency, and feasibility. Returns 'REVIEW_STATUS: PASSED' or 'REVIEW_STATUS: FAILED' with specific critique. |
| formulate_math_modelA | Develops a rigorous mathematical optimization formulation (sets, parameters, variables, objective function, constraints) in LP/MILP/MINLP format from a problem specification. Optionally incorporates reviewer feedback. |
| review_math_modelA | Audits a mathematical optimization formulation for index consistency, variable domains, bounds, objective alignment, and constraint correctness. Returns 'REVIEW_STATUS: PASSED' or 'REVIEW_STATUS: FAILED'. |
| generate_model_codeB | Translates an approved mathematical formulation into structured, executable PySCIPOpt Python code. Returns structured metadata (model_name, description, code, dependencies, assumptions, objective_sense). |
| review_model_codeB | Reviews PySCIPOpt Python code against the mathematical formulation and PySCIPOpt API standards. Returns 'REVIEW_STATUS: PASSED' or 'REVIEW_STATUS: FAILED' with bugs and corrections. |
| execute_model_codeB | Executes PySCIPOpt optimization code inside an isolated sandbox subprocess, returning execution metrics, solver logs, stdout, and error status. |
| review_execution_resultB | Evaluates solver execution logs, solution optimality, status, and feasibility. Returns 'REVIEW_STATUS: PASSED' or 'REVIEW_STATUS: FAILED' with diagnostic analysis. |
| execute_pyscipopt_sandboxB | Direct sandbox execution tool for running Python / PySCIPOpt scripts in an isolated subprocess. Returns success flag, exit_code, stdout, stderr, and execution_time_seconds. |
| run_end_to_end_workflowA | Executes the full autonomous multi-agent optimization workflow graph with automated feedback loops (Clarification -> Math Modeling -> Code Generation -> Sandbox Execution). CRITICAL WARNING: This tool should ONLY be used when the user EXPLICITLY requests full autonomous end-to-end workflow execution. Otherwise, use individual modular tools. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| clarify_problem | Prompt template for requirements clarification. |
| formulate_optimization_model | Prompt template for mathematical model formulation. |
| implement_pyscipopt_code | Prompt template for generating PySCIPOpt code. |
| audit_optimization_model | Prompt template for auditing a mathematical model. |
| diagnose_execution_error | Prompt template for diagnosing sandbox execution and solver errors. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| get_agent_catalog | Catalog of available modular optimization tools, agents, and guidelines. |
| get_workflow_topology | Workflow graph architecture and feedback loop documentation. |
| get_executable_code_schema | JSON Schema for structured ExecutableModelCode output. |
| get_formulation_ir_schema | JSON Schema for FormulationIR model. |
TDQS
Scored across 11 tools
Most tools target distinct artifacts in the optimization workflow, but execute_model_code and execute_pyscipopt_sandbox both run PySCIPOpt code in a sandbox without clearly distinguishing their intended use. decompose_optimization_query also overlaps in an advisory role with clarify_requirements, creating some misselection risk.
All tool names use consistent snake_case with a clear verb_noun pattern (review_*, execute_*, formulate_*, etc.). The naming is predictable and readable throughout.
Eleven tools is a reasonable size for a multi-stage optimization modeling workflow covering clarification, formulation, code generation, execution, and review. However, the two execution tools are likely redundant, making the set slightly larger than necessary.
The tool surface covers the end-to-end lifecycle from requirements clarification through math modeling, code generation, execution, and review at each stage. Minor gaps exist, such as tools for solution interpretation/reporting or model persistence, but core workflows are well supported.