MCP対応のStable Diffusion WebUI Forge - Neo用MCPサーバー · MCPを話せるAIエージェントなら、自分のGPUで画像を生成できます
Claude — またはMCP対応のエージェント — に画像を頼むと、ローカルのForge Neoで生成されます。読み込まれているチェックポイントを確認し、そのモデルが期待するサンプリングパラメータとプロンプトスタイルを割り出し、プロンプトを書き、ファイルを返してくれます。
ステップやCFG、サンプラーを自分で指定する必要はありません（指定したい場合を除く）。それらはあなた自身の環境から取得されます：インスタンスの設定、過去の生成履歴、チェックポイントのメタデータ。判断できない場合は、推測せずに質問してきます。
[!IMPORTANT] Forge Neoは
--api付きで実行する必要があります。Forgeのフォルダには何もインストールされません — 拡張機能もカスタムノードもありません。ブリッジはForgeが既に公開しているREST APIと通信します。
Related MCP server: invokeai-mcp
Forge Neo |
|
Python | エージェントを実行するマシンで3.10以上 |
MCPクライアント | Claude Code、Claude Desktop、Cursor、その他MCP対応のもの |
Forgeが別のマシンで動いている場合のみ：そのマシンへのネットワークアクセス、および結果をbase64ではなくファイルパスで受け取りたい場合はファイル共有。
webui-user.bat（Windows）またはwebui-user.sh（Linux）を編集して--apiを追加します：
set COMMANDLINE_ARGS=--api既存のフラグはそのままに、--apiを追加するだけです。Forgeを再起動します。
動作確認：
http://127.0.0.1:7860/docsを開きます。/sdapi/v1/...エンドポイントが一覧表示されていれば、APIは有効です。
pip install git+https://github.com/eduardoabreu81/forgeneo-mcpClaude Code
claude mcp add forgeneo -e FORGE_URL=http://127.0.0.1:7860 -- forgeneo-mcpClaude Desktop、Cursor、またはmcp.jsonを持つクライアント
{
"mcpServers": {
"forgeneo": {
"command": "forgeneo-mcp",
"env": { "FORGE_URL": "http://127.0.0.1:7860" }
}
}
}クライアントを再起動します — MCPサーバーは起動時に読み込まれるため、ツールは新しいセッションで表示されます。
FORGE_URL以外はすべてオプションで、それもForgeが127.0.0.1:7860にない場合のみ必要です。
変数 | 機能 | デフォルト |
| Forgeの場所 |
|
|
| なし |
| Forgeのパスを自分のマシンで到達可能なパスに変換 | なし |
| 自動検出できない場合の出力フォルダ | 自動 |
| リクエストの待機秒数 |
|
| 設定を学習する際に読み込む最近の画像数 |
|
|
| オフ |
| 確認済みの回答が記憶される場所 |
|
他に何もする必要はありません — デフォルトでカバーされます。
Forgeを--listen --api付きで起動し、ブリッジをそのマシンに向けてパスをマッピングします：
claude mcp add forgeneo \
-e FORGE_URL=http://gpu-box:7860 \
-e FORGE_PATH_MAP='D:/forge-neo=//gpu-box/share/forge-neo' \
-- forgeneo-mcpFORGE_PATH_MAPはForgeが呼ぶ名前 = あなたが呼ぶ名前として読み取られます。ForgeはD:\forge-neo\output\...のようなパスを報告します。同じフォルダに\\gpu-box\share\forge-neo\output\...として到達する場合、そのマッピングによりブリッジはメガバイト単位のbase64ではなくファイルパスを渡せます。
これがなくてもすべて機能します — base64で受け取るだけです。
[!NOTE]
--listenはパスワードなしでAPIをネットワークに公開します。それが問題になる環境では、Forgeに--api-auth user:passwordを追加し、FORGE_AUTHをそれに合わせて設定してください。
新しいセッションを開き、エージェントに接続確認を依頼します。capabilitiesを呼び出して、見つかった内容を報告します：
reachable true
counts checkpoints · loras · samplers · schedulers · modules
filesystem file paths (or: base64 — no readable output dir)
history how many past generations it could read確認する価値のある3つの項目：
filesystem: base64 — FORGE_PATH_MAPが欠落しているか誤っています。致命的ではありませんが、結果が会話を肥大化させます。
history: 0 — 過去の作業から学習できません。通常は出力フォルダに到達できないか、Forgeがメタデータを保存していません（トラブルシューティングを参照）。
loras: 0 でLoRAがインストールされている場合 — Forge自身のLoRAリストが空です。UIで更新してください。
頼むだけです。エージェントが残りを処理します。
「冬のハイキングについての記事のカバー画像」
読み込まれているものを確認し、そのモデルが散文を好むかタグを好むかを判断し、それに応じてプロンプトを書き、生成します。
「同じものだけど、サムネイルに使うスタイルで」
LoRAを検索し、該当するものを見つけ、トリガーワードと通常使用する重みを取得し、プロンプトに書き込みます — 送信された内容が読めるように可視化されます。
「ポートレート用のモデルに切り替えて」
そのチェックポイントを読み込みます。異なるアーキテクチャに属する場合、対応するVAEとテキストエンコーダーも一緒に読み込まれます。
直接尋ねる価値のあるその他のこと：
「どのモデルが読み込まれていて、どうプロンプトすればいい？」 — 平易な言葉でのプロファイル
「このチェックポイントで使えるLoRAはどれ？」 — 互換性のあるものに絞り込み
「fluxのセットアップは完了してる？」 — VAEとテキストエンコーダーを確認
「停止」 — 実行中の生成を中断
エージェントが自動的に選択します。ここにあるのは、何ができるかを知るためのリストです。
ツール | 目的 |
| このインスタンスが提供するものとブリッジが読み取れたもの |
| 読み込まれているチェックポイント：パラメータ、プロンプトスタイル、モジュールの健全性 |
| このモデルがどうプロンプトされることを期待しているか、品質タグ付き |
| 名前、タグ、トリガーワード、説明でLoRAを検索 |
| 1つのLoRAに関するすべて、使用可能なプロンプト断片付き |
| チェックポイントの一覧表示、読み込み、更新 |
| 読み込まれているVAEとテキストエンコーダーがアーキテクチャに適合しているか |
| 欠落モジュールの入手先 — 承認した場合のみ取得します |
| 書かれたプロンプトから生成、txt2imgまたはimg2img |
| 実行中のジョブの確認、中断、スキップ |
Forgeに到達できないと言われる
Forgeが--api付きで実行され、http://127.0.0.1:7860/docsに/sdapi/v1/エンドポイントが一覧表示されていることを確認してください。Forgeが別のマシンにある場合は--listenも必要で、ファイアウォールが妨げになっている可能性があります。
結果がbase64で返ってきて会話が溢れる
FORGE_PATH_MAPが欠落しているか一致していません。Forgeが報告するパス — 任意の生成の情報に表示されます — と、同じフォルダに到達するために使用するパスを比較してください。
通常の設定を認識しない
過去の画像から学習しますが、そのためにはForgeが生成パラメータを保存する必要があります。設定 → 画像保存で、**「生成パラメータのテキスト情報をpngファイルにチャンクとして保存」**を有効にするか、.txtサイドカーをオンにしてください。どちらもない場合、出力にパラメータが含まれず、アーキテクチャのデフォルトにフォールバックします。
SDXLチェックポイントの系統を何度も聞かれる Pony、Illustrious、Animagine、標準SDXLはファイルからは区別できません — 同じテンソル、同じプリセット、異なるプロンプト語彙。一度答えるとファイルごとに記憶され、二度と聞かれません。
アーキテクチャ切り替え後に画像がおかしくなる モジュールチェックを依頼してください。Forgeは各プリセットで最後に選択されたVAEとテキストエンコーダーを記憶しているため、別のプリセットがアクティブな状態でチェックポイントを読み込むと、誤ったものが付いたままになることがあります。チェックは何が欠落しているか、正しいファイルが既にインストールされているかを示します。
容量不足でダウンロードが拒否された
意図的です — 数ギガバイト進んだ後に失敗するのではなく、開始前に空き容量を確認します。空き容量を確保するか、bf16の代わりにfp8_scaledのような軽量ビルドを選択してください。
モデルに合ったサンプリングパラメータ。 利用可能な場合はあなた自身の過去の生成から、そうでない場合はインスタンスの設定から取得されます — このリポジトリの表からではありません。
正しいプロンプト語彙。 役立つ場合は品質タグ、害になる場合はなし：キャプションで訓練されたモデルにmasterpiece, best qualityを追加すると、プロンプトが改善されるどころか薄まります。
検索可能なLoRA。 名前、タグ、トリガーワード、説明で検索でき、実際に使用する重み付き。プロンプトに何かが追加される際は必ず表示されます。
正直な不確実性。 証拠が尽きたところでそれを伝え、質問します。黙って推測することはありません。
モジュール健全性チェック。 プリセットが誤ったVAEやテキストエンコーダーを拾った場合に気づき、欠落しているものの公式ダウンロード先を示します。
各回答がどのように導出されるかのメモは、それを導出するコードの隣のソースにあります。
ビデオ（Wan） — Forgeは4n+1の倍数のフレーム数でビデオを生成し、ffmpegでエンコードしますが、APIは結果のパスを破棄します。ディスクからの収集は画像が返ってくる方法として既に実装されているため、これは主に配管の問題です。
EXIFメタデータ — JPEGとWebPは.txtサイドカーがオフの場合、パラメータをEXIFに保存します。その組み合わせは現在履歴を生成しません。
認証 — FORGE_AUTHは実装されていますが、実際の--api-authインスタンスに対してテストされていません。
Forge Neo by Haoming02 — ブリッジの接続先WebUI、およびモジュール参照の背後にあるDownload Modelsウィキ
モデル作者 — カードに実際のプロンプトガイダンスを公開している方々。方言テーブルは推測ではなくそれらから構築されています
Model Context Protocol — プロトコルとPython SDK
CivitAI — オプションのルックアップで使用される公開ハッシュ別エンドポイント
MIT — LICENSEを参照
Stable Diffusionコミュニティのために❤️を込めて
Report what this Forge instance offers: routes, counts, and which metadata sources are available. Call this first in a session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the burden of behavioral disclosure. It states the tool reports information, which implies read-only, but it does not explicitly confirm the absence of side effects, nor mention any authentication, latency, or output-size implications of being called first in a session.
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 sentences, no filler. The core function is stated first, and the usage instruction is a separate, front-loaded directive. Every word earns its place.
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 zero-parameter tool with no output schema, the description covers what the agent receives and when to call. It stops short of describing the exact shape of the routes/counts/metadata-source data, but that level of detail is rarely needed before invoking 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?
The tool has zero parameters, so the baseline is 4 per the rubric. The description adds context about what the returned report covers, which is the relevant semantic information an agent needs.
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 uses a specific verb (Report) with a clear resource (Forge instance) and enumerates the exact content of the report (routes, counts, metadata sources). This distinguishes it from sibling tools like model_profile or generate, which are about particular resources rather than an instance-wide overview.
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?
Explicitly instructs to call this tool first in a session, giving an unambiguous trigger condition. Since no sibling serves an overview/discovery role, there is no alternative to contrast, and the instruction is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from an already-written prompt.
The prompt is sent verbatim: include any <lora:name:weight> yourself. With
use_profile_defaults on, missing sampling parameters are filled from what the
loaded model actually used before, so leave them unset unless you mean to
override. That includes shift (Forge's distilled_cfg_scale) and the
dimensions: leaving them at 0 takes the architecture's own values instead of
a generic default. Returns file paths when the output folder is readable.
Pass init_image (a local file path) to run img2img instead, where
denoising_strength controls how far the result may drift from it: around
0.3 keeps the composition, 0.75 reinterprets it freely. Edit-style and video
models expect values close to 1.0.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| shift | No | ||
| steps | No | ||
| width | No | ||
| height | No | ||
| prompt | Yes | ||
| cfg_scale | No | ||
| scheduler | No | ||
| batch_size | No | ||
| init_image | No | ||
| sampler_name | No | ||
| negative_prompt | No | ||
| denoising_strength | No | ||
| use_profile_defaults | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the prompt is sent verbatim, requires manual LoRA syntax, explains that missing sampling parameters are filled from the model's actual history under use_profile_defaults, clarifies that shift and dimensions default to architecture-specific values when left unset, and discloses that return values are file paths only when the output folder is readable. It also details denoising_strength effects and the near-1.0 expectation for edit/video models. This is thorough and goes far beyond a bare statement of purpose.
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 paragraphs, each with a distinct focus: purpose, prompt/profile defaults, and img2img specifics. Every sentence adds meaningful information. The core purpose is stated first, and the most critical caveat (verbatim prompt, LoRA) comes immediately after. There is no fluff or redundant phrasing.
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 complex 14-parameter tool with no output schema, this description covers the essential usage nuances: the verbatim prompt behavior, profile default handling, dimension/shift semantics, img2img initiation, and denoising strength guidance. It also notes the conditional return format. What is omitted (error cases, exact output object structure) is minor and not required for correct invocation. Given the tool's complexity, the description is impressively 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 description coverage is 0%, so the description must explain the parameters. It does so selectively but effectively: it explains shift as Forge's distilled_cfg_scale, dimensions default to the architecture's own values, init_image switches to img2img, denoising_strength controls drift with concrete ranges, and use_profile_defaults influences whether other parameters are ignored. These are the non-obvious ones; standard parameters like steps, cfg_scale, and negative_prompt are left to the agent's prior knowledge, which is reasonable given their commonality.
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 opens with a specific verb+resource: 'Generate an image from an already-written prompt.' This clearly distinguishes it from all sibling tools (profiles, progress, loras, models, etc.), which are about model management and introspection, not generation. No ambiguity about what the tool does.
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?
While it doesn't explicitly name alternative tools, the context makes the intended use unambiguous: it is the image-generation tool. It does provide clear guidance on when to use img2img (pass init_image) versus text-to-image, and explains the behavior of use_profile_defaults to avoid overriding model-specific settings. This is sufficient routing for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one LoRA, including description, tags, past usage and a ready-to-paste prompt fragment with its trigger words.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of signaling behavior. It frames the tool as informational, which reasonably implies a read-only operation, and it lists concrete output facets such as description, tags, past usage, and a trigger-word prompt fragment. It stops short of explicitly stating 'does not modify anything,' but the risk of misinterpretation is low.
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?
One tight sentence with the core purpose front-loaded and the output components listed afterward. There is no filler, redundancy, or unnecessary detail.
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 simple one-parameter informational tool, the description conveys the return value and general scope, but it lacks parameter-format guidance and any routing cues relative to siblings. Since there is no output schema and no annotations, more explicit context about what to pass and when to use this tool would improve completeness.
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 schema has only the 'name' parameter with 0% description coverage, and the tool description does not explain what format 'name' should take (display name, key, path, etc.). The phrase 'for one LoRA' weakly implies the parameter identifies a LoRA, but that is not enough to confidently construct a valid argument without further inference.
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 clearly identifies the operation as retrieving full detail for a single LoRA and enumerates the specific contents returned. It also differentiates from siblings like loras, which likely provide a list rather than deep per-item detail.
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 singular phrasing 'one LoRA' implies this is for focused lookup, and sibling tools like loras are the natural list counterpart, but no explicit when-to-use or when-not-to-use guidance is given. The agent must infer the routing from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search available LoRAs by name, title, tags, trigger words or description.
Only call this when the request actually calls for one (a named style,
character, or concept) — most generations need no LoRA at all. kind can be
"content" or "accelerator"; accelerators change the sampling regime rather
than the image, so adopting one means adjusting steps and CFG together.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| limit | No | ||
| query | No | ||
| verbose | No | ||
| base_model | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the behavior of accelerators vs. content LoRAs, noting that accelerators change the sampling regime. It does not mention whether the operation is read-only (though 'Search' implies it) or what the response format is. This leaves moderate gaps, so a 3 is fair.
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 two sentences and efficiently conveys the core purpose and usage. It front-loads the action and then adds contextual guidance. It is appropriately sized, though it could benefit from a bulleted list for parameters, but as-is it's concise and clear. Score 4.
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 has 5 parameters and no output schema. The description does not explain query, limit, verbose, or base_model, nor does it describe the response. It also assumes knowledge of what 'content' vs 'accelerator' means beyond the brief note. Overall, it leaves too much unspecified for a complete tool definition. Score 2.
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 the 'kind' parameter in detail but ignores query, limit, verbose, and base_model entirely. This is insufficient for a 5-parameter tool, so a 2 is warranted.
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 clearly states the tool's function: 'Search available LoRAs by name, title, tags, trigger words or description.' It identifies the resource (LoRAs) and the action (search). However, it doesn't explicitly differentiate from sibling lora_info, though the search vs. info distinction is inferable. So a 4 is appropriate.
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 description provides explicit guidance: 'Only call this when the request actually calls for one (a named style, character, or concept) — most generations need no LoRA at all.' This clearly indicates when to use and when not to, and also explains the kind parameter's role in choosing content vs. accelerator. It doesn't name alternative tools, but the guidance is decisive enough for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the currently loaded checkpoint: architecture preset, whether it behaves as a turbo/distilled model, the sampling parameters that actually worked before, the expected prompt dialect, and whether its VAE and text encoder modules exist. Call before writing a prompt for an unfamiliar model.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It describes what the tool reports (content list) and frames it as a read-only describe operation, but it does not explicitly state that it has no side effects, nor does it describe the return format or possible failure cases (e.g., no checkpoint loaded). The content list implies a safe read, but explicit disclosure is absent, leaving a minor 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?
The description is a single, dense sentence that fronts the main action ('Describe the currently loaded checkpoint') and then lists specific attributes. It is concise but somewhat packed with details, which slightly reduces readability. Overall, it earns its place without wasted words, so a 4 is fitting.
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?
Given no parameters and no output schema, the description must convey what the agent receives; it does so by enumerating the key components (architecture, distilled status, sampling parameters, prompt dialect, module existence). It also includes the usage timing. It lacks mention of error scenarios, but for a straightforward describe tool, the provided details are sufficient for correct invocation.
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 input schema has zero parameters and 100% schema coverage, so there is nothing to explain—the baseline for 0 parameters is 4. The description adds no parameter information because none exist, which 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 opens with the specific verb 'Describe' and the resource 'currently loaded checkpoint', then enumerates the exact content: architecture preset, turbo/distilled status, sampling parameters, prompt dialect, and module existence. This clearly differentiates it from siblings like models (which likely lists available models) or prompt_dialect (which covers only one aspect). The call-before-writing-prompt instruction reinforces its distinct role.
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 description explicitly states when to call: 'Call before writing a prompt for an unfamiliar model.' This is a clear, actionable context. It does not explicitly list alternatives or exclusion conditions, but the tool's comprehensive nature and the directive make usage unambiguous, so a near-top score is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or load checkpoints. action: "list" | "load" | "refresh".
Loading swaps the model for the whole instance, including any human using
the web UI at the same time, and takes several seconds — only do it when the
operator asked for that model. When the target belongs to a different
architecture, its preset, VAE and text encoder are switched with it, since
Forge would otherwise load it against whatever modules are selected now. The
architecture is inferred from two signals and only acted on when they agree;
pass preset to state it outright.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| limit | No | ||
| query | No | ||
| action | No | list | |
| preset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility for disclosing behavior. It reveals that loading swaps the model for the entire instance, affects web UI users, takes several seconds, and switches preset/VAE/text encoder under certain architecture conditions. This is unusually transparent for such a side-effectful operation.
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 compact and front-loaded with the key action enum. The longer paragraph earns its place by disclosing critical side effects and architectural behavior. No filler or repetition.
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 load path is thoroughly described, including side effects and architecture handling. However, the list and refresh paths are under-specified, and with no output schema and no annotations, the description does not clarify what the tool returns or how limit/query affect list results. This leaves meaningful gaps for an agent.
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 0%, so the description must compensate. It explains action values ('list' | 'load' | 'refresh') and the purpose of preset, but it does not clarify what name, limit, or query do, which are essential for the list action. This is partial compensation for a low-coverage schema.
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 opens with 'List or load checkpoints,' which names a specific resource and action set. It clearly identifies the tool's scope, though it does not explicitly distinguish itself from sibling tools like model_profile or loras.
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 description gives explicit when-to-use guidance for the load action: 'only do it when the operator asked for that model.' It also explains when to pass a preset. However, it gives no guidance for choosing list vs. refresh or for using any sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the VAE and text encoders loaded for an architecture against what it actually needs, and list installed files that could fill any gap.
Defaults to the active preset. Worth calling after switching architecture or when output looks wrong for no obvious reason: Forge records the last selection made under a preset, so loading a checkpoint while another preset was active can leave the wrong modules attached. Where the reference does not state a VAE, it says so instead of guessing — a wrong VAE degrades output without raising an error.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior. It discloses that it says when a VAE is not stated instead of guessing, and explains the preset behavior. It implies read-only operation by listing files and checking, which is transparent. No contradictions with annotations since none are provided.
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 compact yet information-dense. It leads with the main purpose, then usage triggers, and finally a behavioral note. Each sentence contributes to understanding without fluff, and it is not overly long.
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 description covers what, when, why, and what it returns (list of installed files). While no output schema is provided, listing files is enough for an agent to understand the output. The description also hints at edge cases (missing VAE) and the reasoning behind the need for this tool. It is complete for a simple one-parameter 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 0% and there is only one parameter, preset. The description explains that it defaults to the active preset, which gives meaningful context for the parameter beyond the schema's default value. This compensates for the lack of schema documentation, though it does not specify format or types beyond the default.
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 clearly states the function: checking VAE and text encoders against architecture needs and listing installed files to fill gaps. It uses a specific verb (check) and resource (VAE and text encoders), and distinguishes itself from siblings like model_profile and module_download by focusing on module alignment, not profiling or downloading.
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 provides explicit scenarios for use: after switching architecture or when output looks wrong without obvious cause. It explains the underlying reason (preset selection recording) and gives a clear rationale for calling it. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find, and optionally fetch, a VAE or text encoder the architecture needs.
Called with no arguments it lists what the active preset is missing and
where each file comes from, downloading nothing. Downloading requires both a
label naming one entry and confirm=True, and the operator has to agree
first: these are multi-gigabyte files written into their models folder,
often across a network share.
Links come from the Forge Classic wiki's Download Models page. Where several builds exist — bf16, fp8_scaled, gguf — they are all offered, because which to take depends on the operator's hardware, not on a default worth hiding.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| preset | No | ||
| confirm | No |
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 so thoroughly: it discloses that no-args downloads nothing, that download writes multi-gigabyte files into the models folder often over a network share, that confirmation is mandatory, and that all model build variants are offered rather than a hidden default. This is strong side-effect and safety transparency.
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 front-loaded with the core purpose, then adds exactly the operational details needed to avoid unsafe calls. Each sentence carries information; there is no filler or restatement of the tool name.
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 no-annotation, no-output-schema context makes the description the only source of behavior, and it covers invocation modes, side effects, file source, and build choices. However, the `preset` parameter is left ambiguous, and there is no indication of the return/listing format beyond 'lists what is missing.'
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 prose must explain the parameters. It explains `label` and `confirm` well, but never describes the `preset` parameter—it only mentions 'the active preset'—so one of three parameters remains semantically unexplained.
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 names a specific action — find and optionally fetch — a concrete resource (VAE/text encoder) and a scoping context (what the architecture needs). The no-arguments behavior makes the tool's role unmistakable and sets it apart from siblings like module_check.
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 description clearly distinguishes the safe no-argument listing mode from the mutating download mode and states the exact precondition (`label` plus `confirm=True`). It does not name an alternative sibling for other cases, so it misses the 'when-not/alternatives' bar for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check or stop the current generation. action: "status" | "interrupt" | "skip".
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It lists actions but does not explain the consequences of each—for example, what 'interrupt' or 'skip' actually do, whether they are reversible, or if they have side effects. The tool appears to be a mutation-capable (stop) operation, yet that is not clearly characterized.
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 very short and front-loaded: it states the action and immediately lists the values. No filler. It could be slightly more structured (e.g., separate lines for each action) but it remains efficient and readable.
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 tool with no output schema and no annotations, the description is inadequate. It does not explain what each action returns or does, lacks details about error handling, or expected output. An agent may not know whether 'status' returns a string, a JSON object, or whether 'interrupt' requires any confirmation. This is a notable gap for such a simple 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?
The schema gives only a name and default for the 'action' parameter. The description compensates by enumerating the allowed values ('status' | 'interrupt' | 'skip'), which adds meaning beyond the schema. This fits the low schema coverage, so the description carries the semantic load effectively.
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 clear purpose: checking or stopping the current generation, and enumerates three specific actions. This is distinguishable from siblings like 'generate' or 'models' because it focuses on the lifecycle of generation. However, it does not explicitly name a sibling it is not, so it loses one point.
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 description provides no guidance on when to use this tool versus alternatives. It implies it relates to an ongoing generation but does not specify conditions, such as 'use after generate' or 'use to retrieve status.' No exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How the loaded checkpoint expects to be prompted, with its quality tags.
Returns the dialect (pony / illustrious / animagine / anima / sd15 / sdxl_base / natural), the quality prefix and negative baseline it needs, and where that conclusion came from. Quality tags are not decoration: an Illustrious prompt without them degrades, and a Flux prompt with them degrades too.
When the dialect comes back unknown — xl covers Pony, Illustrious and
stock SDXL, which share tensors and preset — ask the operator, then call
again with confirm set to their answer. It is cached by file hash and
never asked again.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden and does so thoroughly. It reveals caching by file hash, the ambiguous xl case covering multiple dialects, the need for operator confirmation, and the warning that quality tags meaningfully affect output. No hidden side effects or surprising behaviors are apparent.
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 front-loaded with purpose, then organized into return contents, operational warnings, ambiguity handling, and caching behavior. Every sentence contributes meaningful information without filler or repetition.
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 and no annotations, the description fully covers required return semantics: possible dialects, quality prefix, negative baseline, and provenance. It also explains the ambiguous result path, the confirm parameter, and the caching behavior, making the tool safely and correctly callable by an agent.
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 input schema only exposes an optional string confirm with no description, and schema coverage is 0%. The description compensates by explaining that confirm should be set to the operator's answer when the dialect comes back unknown, tying the parameter to the ambiguity workflow. It does not explicitly enumerate valid confirm values, but the dialect list in the description implies the expected value space.
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 clearly states the tool returns the prompting dialect of the loaded checkpoint, enumerates all dialect values, and names the return components: quality prefix, negative baseline, and source. It is distinct from sibling tools like model_profile because it focuses specifically on prompt expectations and quality tags.
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 description gives clear context: use the tool to learn how the loaded checkpoint must be prompted, especially regarding quality tags. It also covers the conditional workflow when the dialect is unknown, telling the agent to ask the operator and call again with confirm. It does not explicitly name sibling alternatives or when not to use it, but the context is strong.
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.0capabilitiesgeneratelora_infolorasmodel_profilemodelsmodule_checkmodule_downloadprogressprompt_dialectScored across 10 tools
Tools are mostly distinct by resource and action—LoRA search vs detail, module check vs download, generation vs progress—but model_profile and prompt_dialect overlap on prompt dialect, and models/model_profile could be confused at a glance. The detailed descriptions mitigate most ambiguity.
Names consistently use lowercase snake_case and a readable resource-oriented style (loras, lora_info, models, module_check). Not all are verb_noun—generate is a bare verb and progress is ambiguous—so it is not a perfect 5, but there is no chaotic convention mixing.
Ten tools is well within the ideal 3–15 range and matches the server's scope: discovery, model/prompt/LoRA/module setup, generation, and progress control. No tool feels redundant or superfluous.
The surface covers the full generation workflow—model loading, profiling, prompt dialect, LoRA lookup, module diagnostics/download, generate, and progress monitoring. Minor gaps exist (no LoRA download/management, no explicit output/history listing), but they are not required for the core purpose.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
Remote MCP for RunComfy: ComfyUI deployments, hosted models, LoRA training. 31 tools.
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
Generate and edit images, video, voice, lip-sync and 3D models from your AI agent.
