Skip to main content
Glama
OuchiniKaeru

Genetic Optimization MCP Server

by OuchiniKaeru

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
optimization.validate_problemA

Validate a problem definition without evaluating anything.

    Checks variable ranges/types, expressions, constraints, evaluator
    availability and parameter schemas, and administrator budgets.  Use
    ``strict`` to surface non-deterministic evaluators and oversized budgets.
    
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.

    ``execution_mode="sync"`` waits for completion and returns the summary.
    ``execution_mode="async"`` returns immediately with a ``run_id`` and
    ``status``; poll it with ``optimization.get_result``.  A repeated
    ``client_request_id`` returns the existing run instead of starting a
    duplicate.
    
optimization.get_resultA

Fetch run status, progress and the stored result summary.

    Full candidate populations are never returned; ``top_solutions`` is
    capped by the run's ``top_k``.  Set ``include_top_solutions=false`` for a
    smaller response.
    
optimization.list_runsA

List run history newest-first with optional status/problem filters.

    Default page size is 20; the administrator maximum is enforced.  Pass the
    returned ``next_cursor`` to fetch the next page.
    
optimization.cancelB

Request cancellation of a queued or running run.

    Cancellation is cooperative first; if the worker does not stop within
    the grace period, its process group is terminated.  ``accepted`` and
    ``termination_confirmed`` are reported separately.
    
optimization.compare_resultsB

Compare 2–10 runs and report condition mismatches.

    When objective definitions, variables, constraints, evaluator versions or
    parameters differ, ``comparable=false`` and no single improvement
    percentage is produced.
    

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
agent-guideRecommended validate → solve → compare → re-solve workflow and safety rules.

TDQS

A3.7/5.0

Scored across 7 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues