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., "@Genetic Optimization MCP Server minimize (x-1)^2+(y+2)^2 with x,y in [-5,5], small budget, seed 42"
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.
AI エージェントの代わりに単目的遺伝的アルゴリズム最適化を実行する、再利用可能な MCP サーバーです。エージェントが変数、目的関数、制約、計算予算を定義すると、サーバーが定義を検証し、pymoo を用いた混合変数 GA を隔離されたワーカープロセスで実行し、構造化された結果を返します。
得られた結果は予算内で見つかった最良の候補であり、大域最適解を保証するものではありません。
混合変数型: float（線形/対数）、integer（ステップ付き）、choice、boolean。
目的関数と制約は、サンドボックス化された数式評価パーサー、または管理者が登録した評価関数から指定可能。
回帰テスト済みの評価予算: 最大評価回数、最大世代数、ウォールクロックタイムアウト、シード。
管理者管理の評価関数フォルダ。各フォルダが独自の uv プロジェクトと .venv を持ち、uv run --locked と永続的な JSON Lines ワーカープロセスで実行。
同期および非同期実行、SQLite バックアップの実行履歴、キャンセル、実行結果の比較。
MCP 応答はサニタイズ済み。ログは stderr とローテーションする JSON Lines ファイルに出力され（stdout には出力されない）。
Related MCP server: RelayMe
Python >= 3.12
uv（登録済み評価関数に必要）
uv sync --extra devこれによりサーバー用の .venv が作成されます。登録済み評価関数はこの .venv にはインストールされません。各評価関数は独自の環境を持ちます。
uv run optimization-mcp --config config/default.tomlデフォルトのトランスポートは stdio です。診断と設定確認:
uv run optimization-mcp --config config/default.toml --diagnose{
"mcpServers": {
"genetic-optimization": {
"command": "uv",
"args": [
"run",
"--directory",
"/絶対パス/to/genetic-optimization-mcp",
"optimization-mcp",
"--config",
"/絶対パス/to/genetic-optimization-mcp/config/default.toml"
]
}
}
}ツール | 目的 |
| 許可リスト入り評価関数、そのスキーマ、準備状態を一覧表示 |
| 評価を行わずに問題を検証 |
|
|
| 実行のステータスと結果サマリーを取得 |
| 実行履歴を検索しページング |
| 実行中/キューイング中のジョブのキャンセルを要求 |
| 2–10 件の実行を比較し、明示的な非比較性の注記を付与 |
optimization.list_evaluators を呼び出し、available、deterministic、パラメータスキーマを確認する。
問題を定義し、optimization.validate_problem を validation_level="strict" で呼び出す。
小さい予算から始める: optimization.solve。
目的値を信用する前に、constraints.feasible、termination_reason、warnings、variables_at_bounds を確認する。
必要に応じて範囲や予算を変更し、再実行する。optimization.compare_results で比較する。目的関数、評価関数バージョン、パラメータ、制約が異なる場合、単一の改善率を報告することは拒否される。
最大 5 回の反復（上限 20 回）で終了し、結果を「探索により見つかった最良の候補」として、条件と残りの不確実性とともに報告する。
サーバーは LLM を呼び出さず、制約を勝手に緩和することもありません。
球関数を最小化:
{
"problem_name": "sphere_example",
"variables": {
"x": {"type": "float", "min": -5.0, "max": 5.0},
"y": {"type": "float", "min": -5.0, "max": 5.0}
},
"objective": {
"kind": "expression",
"expression": "(x - 1) ** 2 + (y + 2) ** 2",
"direction": "minimize"
},
"algorithm": {"population_size": 40, "generations": 60, "seed": 42},
"budget": {"max_evaluations": 2000, "timeout_seconds": 30}
}混合変数と制約:
{
"problem_name": "mixed_example",
"variables": {
"lr": {"type": "float", "min": 0.0001, "max": 0.1, "scale": "log"},
"depth": {"type": "integer", "min": 2, "max": 10, "step": 2},
"optimizer": {"type": "choice", "options": ["adam", "sgd"]},
"augment": {"type": "boolean"}
},
"objective": {
"kind": "expression",
"expression": "depth + 0.2 * augment",
"direction": "minimize"
},
"constraints": [
{"constraint_id": "lr_depth", "kind": "expression", "expression": "lr * depth", "operator": "<=", "limit": 0.5}
]
}evaluator_root（デフォルト ./evaluators）直下の各子フォルダが 1 つの評価関数です:
evaluators/
└── model_quality_v1/
├── evaluator.toml
├── params.schema.json
├── pyproject.toml
├── uv.lock
├── evaluator.py
└── .venv/ # `uv sync --locked` で作成、コミット対象外evaluator.toml:
evaluator_id = "model_quality_v1"
version = "1.0.0"
description = "Evaluates a deterministic toy model quality score"
module = "evaluator.py"
function = "evaluate"
deterministic = true
timeout_seconds = 30
params_schema_file = "params.schema.json"evaluator.py は次のように公開します:
def evaluate(candidate: dict, params: dict, context: dict) -> float:
...サーバーが強制する規則:
ID はスラッグ（^[a-z0-9][a-z0-9_-]{0,63}$）であり、フォルダ名と一致しなければならない。
フォルダは設定されたルートの直接の子でなければならない。ルートを抜けるシンボリックリンク、重複 ID、メタデータ/ロックファイルの欠落により評価関数は利用不可になる。
uv lock は MCP リクエストに応答して決して実行されない。ロックの欠落/不整合はエラーとなる。
uv sync --project <dir> --locked は初回使用時、またはロックのフィンガープリントが変更されたときに遅延実行される。
評価ワーカーは JSON Lines を stdout で送信する。評価関数の print() 出力は stderr にリダイレクトされ、プロトコルを汚染しない。
評価結果は有限の JSON 数値でなければならない（ブール値、NaN、Infinity は拒否される）。
サンプル評価関数の準備:
cd evaluators/model_quality_v1
uv lock
uv sync --lockedconfig/default.toml を参照してください。パスは設定ファイルを基準として解決されます。環境変数のオーバーライドは OPTIMIZATION_MCP_ プレフィックスと __ でネストを表現します。例: OPTIMIZATION_MCP_LIMITS__MAX_VARIABLES=20。
管理者による上限値は MCP リクエストから引き上げることはできません。予算を超えるリクエストは BUDGET_EXCEEDED で拒否され、値は黙ってクランプされることはありません。
SQLite データベース: data/optimization.db（WAL モード、トランザクション）。
JSON Lines ログ: logs/optimization-mcp.log（ローテーション、保持期間は設定済み）。
標準出力は MCP stdio トランスポートに専用。ログは stderr/ファイルを使用。
フル人口ではなく、サマリーと上位候補のみが永続化される。
persistence.log_retention_days と persistence.log_max_bytes / backup_count を設定してください。データベースを安全にバックアップするには:
sqlite3 data/optimization.db ".backup 'backup-optimization.db'"復元はサーバーを停止し、data/optimization.db をバックアップと置き換えて行います。旧データベース取得時に running だった実行は、次回の起動時に failed（キャンセルが要求されていれば cancelled）として復旧します。完了済みの実行は引き続き問い合わせ可能です。
数式は Python ast で解析され、許可リストに基づいて評価される。eval、exec、属性アクセス、添字アクセス、内包表記、ラムダ、インポートは拒否される。
MCP 入力からコード、パス、モジュール名、コマンドを提供することはできない。管理者が登録した評価関数 ID のみがコードを実行できる。
uv 環境は依存関係の分離であり、OS サンドボックスではない。信頼できる評価関数コードのみを評価関数ルートに配置する。信頼できないコードには OS ユーザー/コンテナ/リソース制限を使用する。
エラー応答はサニタイズされる。トレースバック、絶対パス、環境変数は含まれない。
認証、TLS、レート制限なしで Streamable HTTP を有効にしないこと（デフォルトでは無効）。
uv run pytest
uv run ruff check src testsuv 環境を必要とするテストは、uv が利用できない場合や OPTIMIZATION_MCP_SKIP_UV_TESTS=1 が設定されている場合はスキップされます。
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.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| run_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does meaningful work: it discloses the two-phase behavior (cooperative request, then process-group kill after a grace period) and that 'accepted' and 'termination_confirmed' are distinct outcomes. It still omits whether cancellation is idempotent, what happens to partial results, or permission requirements.
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 action, with no filler. Minor noise from docstring artifacts (double backticks, stray indentation) but the content is efficient.
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?
An output schema exists, so the mention of 'accepted' and 'termination_confirmed' correctly focuses on process rather than return format. However, for a destructive, annotation-free mutation it should state irreversibility, permission needs, and the meaning of its two inputs.
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 0% for two parameters. The description never explains run_id (format, where to get it) or what reason is used for, so an agent gets no meaning beyond the bare property names.
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 ('Request cancellation') and resource ('a queued or running run'), and scopes which runs are eligible. It does not name or contrast with any sibling (e.g., list_runs to find a run_id, get_result to inspect status), so differentiation is inferable but not explicit.
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 phrase 'queued or running run' implicitly excludes completed runs, which is a useful usage boundary. But there is no guidance on when to cancel versus poll with get_result, no prerequisites about who may cancel, and no mention of how to obtain run_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| run_ids | Yes | ||
| compare_fields | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add genuine behavioral context: it discloses the comparable=false condition and that no single improvement percentage is emitted, which prevents misreading the output. It still omits that this is a read-only operation and what happens for invalid inputs (fewer than 2 runs, unknown IDs).
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?
Front-loaded with the action and scope, followed by the one behavioral caveat that matters. Every sentence earns its place; the only minor cost is the inline code formatting of comparable=false.
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?
An output schema exists, so return structure needn't be explained, and the description covers the one non-obvious output semantic (comparable=false). For a 2-parameter read tool this is sufficient for correct invocation, with compare_fields the sole residual gap.
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?
run_ids gains real meaning from the '2–10 runs' constraint, which the schema itself does not encode (no minItems/maxItems). However compare_fields — the only other parameter, defaulting to null — is never explained; the list of mismatch axes (objective, variables, constraints, evaluator versions, parameters) hints at it but doesn't say whether those strings are valid values.
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 (compare runs) with an explicit cardinality bound (2–10) and the outcome it produces (condition mismatch report). It is clearly distinguishable from siblings like get_result or list_runs, though it never names 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?
The 2–10 run bound implies a batch comparison context, and the mismatch clause hints at when the result is not a simple delta. But there is no explicit guidance on when to prefer this over get_result or how to prepare inputs (same problem/objective baseline).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| include_top_solutions | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a non-obvious behavioral trait: full candidate populations are never returned and top_solutions is capped by the run's top_k. It also notes the smaller-response option. It does not mention whether results are partial for an in-progress run, which is the main remaining gap.
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 purpose and followed by the truncation caveat and the size option. No waste, though the line breaks and inline code styling are slightly noisy.
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?
An output schema exists, so return-value explanation is not required. Given that, the description covers purpose, the key data-completeness limitation, and the response-size control, which is everything needed to invoke it correctly.
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 0%, so the description must compensate. It explains include_top_solutions' effect ('smaller response') and ties top_solutions to top_k, but says nothing about run_id's format or source, leaving half the parameters undocumented.
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 ('Fetch') and resource ('run status, progress and the stored result summary'), which is clear enough to distinguish it from siblings like list_runs or compare_results. It does not explicitly contrast with those siblings, keeping it short of 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?
Usage is only implied: fetching results implies the run exists, and the include_top_solutions flag is framed as a response-size tradeoff. There is no explicit statement of when to use this versus compare_results or list_runs, and no prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses the return payload fields and a redaction guarantee ('Internal paths and environment variables are never returned'), but says nothing about pagination, ordering, empty-result behavior, or permissions required to see administrator-registered evaluators.
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?
Front-loaded with the purpose, followed by one compact enumeration of returned fields. Efficient and free of filler; only the odd indentation and a slight redundancy with the output schema cost it a point.
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?
Because an output schema exists, the return-value enumeration is a bonus rather than a necessity. However, the description leaves the entire input surface unexplained and omits how the listed evaluator IDs are consumed downstream, which is a real gap for a discovery 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 description coverage is 0% and both parameters are undocumented in the schema, yet the description never mentions 'limit' or 'query' at all. With two undocumented parameters, the description should have explained filtering and pagination semantics but does not.
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 first sentence gives a specific verb and resource ('List administrator-registered evaluators') plus a scope qualifier ('their readiness'). It is clearly distinct from siblings like list_runs, solve, and compare_results, though it never names an alternative to sharpen the boundary.
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 guidance on when to call this versus list_runs or get_result, no mention of prerequisites (admin role?), and no statement that returned IDs feed into solve/validate. Usage must be inferred entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| status | No | ||
| problem_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose meaningful behavior: newest-first ordering, default page size of 20, an enforced administrator maximum, and next_cursor pagination. It does not explicitly state that the operation is read-only or describe permission requirements, so some transparency gaps remain.
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 short, front-loaded, and every sentence adds useful information about filtering, ordering, or pagination. There is no redundant restatement of the title or 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?
An output schema exists, so return values need not be explained, and the description covers the important operational context of ordering and cursor pagination. It remains silent on permissions or side-effect guarantees, which is more important because no annotations are provided.
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 0%, so the description must compensate. It identifies the purpose of all four parameters (limit as page size, cursor for next page, status and problem_name as filters) and mentions the default page size, but it omits allowed status values, the actual maximum limit, and problem_name format details.
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 and resource: list run history, with newest-first ordering and optional status/problem filters. It is clearly separable from mutation-oriented siblings like solve and cancel, though it does not explicitly name an alternative tool.
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 implied: inspect run history, optionally filter by status or problem, and paginate with cursor. It gives no explicit when-to-use versus get_result, list_evaluators, or compare_results, and no when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| problem | Yes | ||
| execution_mode | No | sync | |
| client_request_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a decent job: sync blocks until completion, async returns immediately with run_id and status, and a repeated client_request_id returns the existing run rather than starting a duplicate. That idempotency disclosure is valuable. Missing are error semantics on an invalid problem, whether runs persist/can be cancelled, and any cost or rate-limit context.
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, then branching behavior, then the idempotency caveat. Nothing restates the name or the schema, and every clause carries information an agent could act on.
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?
An output schema exists, so return values needn't be spelled out, and the async return shape is described anyway. For a tool whose single required parameter is a deeply nested problem spec with expression syntax, evaluator IDs, and budget/timeout knobs, the description leaves the agent without guidance on constructing a valid problem or on what happens when a budget is exhausted.
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 0%, so the description must compensate. It does well for execution_mode (whose schema has no enum, so the two accepted values and their meaning come entirely from the description) and client_request_id (explains the dedupe semantics). But the required `problem` object — variables, objective kind, constraints, budget, algorithm, evaluator_params — gets no semantic explanation at all, leaving the dominant payload documented only by structure.
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 opening sentence gives a specific verb and resource ("Run the optimization") and the body routes the async path to optimization.get_result, so the agent can tell it apart from that sibling. It does not, however, distinguish it from optimization.validate_problem or list_evaluators, which is the more likely confusion for a first-time caller.
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?
It clearly frames the sync-vs-async decision and the follow-up call needed in async mode, which is real usage guidance. It gives no when-not guidance, no prerequisite (e.g. validating the problem first, registering evaluators needed for kind="registered" objectives), and no statement about how expensive or long-running a call is.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| problem | Yes | ||
| validation_level | No | basic |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that validation does not evaluate the problem and names what is checked, but it does not state side effects, permissions, error behavior, or read-only guarantees explicitly.
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 key constraint that nothing is evaluated. The remaining sentences add concrete validation scope and one strict-mode behavior without waste.
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?
The tool takes a complex nested problem object and has no annotations, so completeness demands more than a short purpose statement. The description covers validation scope and strict mode, and an output schema exists, but it omits explicit routing relative to optimization.solve and deeper parameter guidance.
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 0%, so the description must compensate. It explains that strict mode surfaces non-deterministic evaluators and oversized budgets and lists validation targets, but it does not fully explain basic versus strict behavior or add much detail about the complex problem object.
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 and resource: validate a problem definition. The phrase 'without evaluating anything' sharply distinguishes it from optimization.solve, and the list of checks gives concrete scope.
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?
It gives one explicit usage rule for strict mode, saying it surfaces non-deterministic evaluators and oversized budgets. However, it does not explicitly say when to call this instead of optimization.solve, nor does it state prerequisites or exclusions.
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.3.0optimization.canceloptimization.compare_resultsoptimization.get_resultoptimization.list_evaluatorsoptimization.list_runsoptimization.solveoptimization.validate_problemScored 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.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
Run AI agent tasks in isolated sandboxes with a cost cap, saved workflows and scoped connections.
Scoped agent execution. Server-side credentials, policy, budgets and verifiable receipts.
Give your AI agents the tools to build, manage, and run automation workflows.
