Genetic Optimization MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| optimization.validate_problemA | Validate a problem definition without evaluating anything. |
| optimization.list_evaluatorsC | List administrator-registered evaluators and their readiness. Returns IDs, versions, descriptions, parameter schema summaries, determinism, estimated cost, timeout and environment status. Internal paths and environment variables are never returned. |
| optimization.solveA | Run the optimization. |
| optimization.get_resultA | Fetch run status, progress and the stored result summary. |
| optimization.list_runsA | List run history newest-first with optional status/problem filters. |
| optimization.cancelB | Request cancellation of a queued or running run. |
| optimization.compare_resultsB | Compare 2–10 runs and report condition mismatches. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| agent-guide | Recommended validate → solve → compare → re-solve workflow and safety rules. |
TDQS
Scored across 7 tools
Each tool maps to a distinct stage of the optimization lifecycle: validate, submit, poll, list history, cancel, compare, and enumerate evaluators. The only potentially adjacent pair (solve vs. validate_problem) is clearly separated by the descriptions, since validation explicitly evaluates nothing. No two tools could plausibly be mistaken for one another.
All tools share a uniform 'optimization.' namespace and use snake_case verb_noun naming (get_result, validate_problem, list_evaluators, list_runs, compare_results). The bare 'solve' is the sole noun-less verb but reads naturally as the primary action and does not break the pattern.
Seven tools is well within the sweet spot and every tool earns its place: submission, polling, validation, enumeration, history, cancellation, and comparison are all genuinely needed. There is no filler or redundant surface.
The run lifecycle is fully covered end-to-end, including idempotency, async polling, cancellation, and cross-run comparison, which is unusually thorough. Minor gaps remain: no way to delete/prune run history or manage stored problems, and no streaming/partial-progress retrieval beyond status polling.