Skip to main content
Glama
rerofumi

fm-mcp-comfyui-bridge

by rerofumi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fm-mcp-comfyui-bridge

Python 3.13+ License

ComfyUIにアクセスするためのMCPサーバー実装です。ComfyUI の API との連携を行い、画像生成機能を提供します。

🌟 機能

  • 🖼️ ComfyUIを利用した画像生成機能

  • 📝 生成画像のキャプション生成機能

  • 🏷️ 生成画像のタグ解析機能

  • 🔄 uvによる簡単なセットアップと起動

  • 🌐 MCPサーバーとしてAPIエンドポイントを提供

Related MCP server: ComfyUI MCP

🔧 要件

  • Python 3.13以上

  • ローカルで動作するComfyUI（デフォルト: http://localhost:8188）

  • uv パッケージマネージャ

  • ローカルで動作する ollama と画像認識ができる vision model

📥 インストール

uv がインストールされた環境を用意してください。

uvを使用したインストール

# リポジトリをクローン
git clone https://github.com/rerofumi/fm-mcp-comfyui-bridge.git
cd fm-mcp-comfyui-bridge

# uvを使用して依存関係をインストール
uv pip install -e .

ComfyUI の workflow が動作するか確認

src\fm_mcp_comfyui_bridge\config\workflow\ 下にある json ファイルを ComfyUI に読み込ませて、ノードエラーになっていないことを確認。 足りないカスタムノードとかあったらインストールしておいてください。

🚀 使用方法

MCPサーバーとして設定

利用するエージェントツールのMCP設定に以下のように設定してください

{
  "mcpServers": {
    "fm-mcp-comfyui-bridge": {
      "command": "uv",
      "args": [
        "--directory",
        "(インストールしたディレクトリ)/fm-mcp-comfyui-bridge",
        "run",
        "fm-mcp-comfyui-bridge"
      ],
    }
  }
}

ComfyUIのエンドポイント設定

デフォルトでは、ComfyUIのエンドポイントは http://localhost:8188 に設定されています。必要に応じて main.py 内の設定を変更してください。

Loraの設定

画像生成に使用するモデル設定ファイルを作成する必要があります。以下の手順で設定を行ってください：

  1. サンプル設定ファイルをコピーします：

    cp src/fm_mcp_comfyui_bridge/config/sample_config.yaml src/fm_mcp_comfyui_bridge/config/config.yaml

  2. コピーした config.yaml ファイルを編集して、使用するモデル名を設定します：

    checkpoint: (使いたいチェックポイントモデル名).safetensors
image-size:
  height: 1024
  width: 1024
lora:
- enabled: false
  model: (使いたいLoRAモデル名).safetensors
  strength: 1.0
  trigger: 
sampling:
  cfg: 5
  steps: 24
vpred: true

  3. 設定項目の説明：

    • checkpoint: 使用する基本モデルのファイル名（例：animagine-xl-3.0.safetensors）

    • image-size: 生成する画像のサイズ設定

    • lora: LoRAモデルの設定

      • enabled: LoRAを有効にするかどうか（trueまたはfalse）

      • model: 使用するLoRAモデルのファイル名

      • strength: LoRAの適用強度（0.0〜1.0）

      • trigger: LoRAのトリガーワード

    • sampling: サンプリング設定

      • cfg: CFGスケール値

      • steps: 生成ステップ数

    • vpred: v-predictionを使用するかどうか

モデルファイルはComfyUIの適切なディレクトリに配置されている必要があります。

ollamaの設定

生成された画像のキャプションを取得するために ollama で使用する vision モデル設定ファイルを作成する必要があります。以下の手順で設定を行ってください：

ollama.yaml を編集する

  • vision_model: 画像解析でキャプションを生成する ollama の vision 対応モデル名

利用可能なツール

  1. generate_picture - プロンプトに基づいて画像を生成

    @mcp.tool()
def generate_picture(prompt: str) -> str:
    """生成したいプロンプトを渡すことで画像生成を依頼し、生成された image の url を返す"""

  2. get_picture - 指定された画像のPNGバイナリデータを取得

    @mcp.tool()
def get_picture(subfolder: str, filename: str) -> Image:
    """subfolder と filename を指定して画像の PNG バイナリを取得する"""

  3. get_caption - 画像のキャプションをテキスト形式で取得

    @mcp.tool()
def get_caption(subfolder: str, filename: str) -> str:
    """subfolder と filename を指定して生成した画像のキャプションをテキスト形式で取得する"""

  4. get_tag - 画像からWD1.4タグを解析して取得

    @mcp.tool()
def get_tag(subfolder: str, filename: str) -> str:
    """subfolder と filename を指定して生成した画像からWD1.4タグを解析してテキスト形式で取得する"""

custom workflow の利用

src\fm_mcp_comfyui_bridge\config\workflow\ の下に API 形式の workflow ファイルを置いて、カスタムワークフローとして実行することができます。

src\fm_mcp_comfyui_bridge\config\custom.yaml が存在していたらカスタムワークフローとして実行されます。 存在しない場合はデフォルトのワークフローが実行されます。

example/ ディレクトリにサンプルのカスタムワークフローファイルを置いています。 config の下にコピーして動作を試してください。Flux1-dev で画像生成を行うサンプルとなっています。

カスタムワークフローについての詳細は [README_custom_workflow.md] を参照してください。

サンプルプロンプト

"1girl, cute cat ear maid" で画像を生成してください

画像生成後 画像のキャプションを表示

WD14タグを表示

画像生成のプロンプトが以下に添付されています。
まずはユーザーがこのプロンプトでどんな絵を描かせようとしているかを分析してください。
ユーザーの意図に対しプロンプトが不向き、もしくはより良い表現がある場合は意図を崩さない範囲で修正を加えて構いません。

ユーザーが与えたプロンプトを comfyui MCP を使って画像にしてください、comfyui に与える prompt は英語しか受け付けないのでプロンプトは必ず英語、それもできるだけ danbooru tag に翻訳して generate を依頼してください。generate の実行結果として返る文字列はURLです、生成の結果としてその URL を以下の markdown フォーマットで表示してください。
![{生成結果URL}]({生成結果URL})

danbooru tag におけるクオリティタグは以下です、頭に必ず追加するようにしてください。
"masterpiece, best quality, newest,"

生成されたリンクは画像ファイルへのリンクです。リンクのパラメータにある subfolder と filename を使って comfyui MCP の get_caption と get_tag 両方を取得して、画像に何が映っていたかを確認してください。それらキャプション＆タグ情報と目指しているプロンプトを分析し異なっていたら、元のプロンプトの意図へ近づけるよう、より良いプロンプトになるよう編集し、画像生成を繰り返してください。プロンプトで指示してもその単語が認識されないことがあります。一つの表現に固執するのではなく、目指しているものを別の表現で実現することを目指してみてください。
最大で 8回繰り返しながらより良いプロンプトを構築していきます。
## prompt
女の子と猫とリビング。窓から暖かい春の日差しが差し込んでいて、その暖かい光を受けて猫と女の子が居眠りをしている。部屋はフローリングだが、ラグとクッションがあり、そのクッションを枕にしている。寝る女の子の頭に猫がすり寄っていて、仲がよさそう。穏やかな日常の風景。

APIリソース

@mcp.resource("info://about")
def get_info() -> str:
    """サーバー情報"""

@mcp.resource("help://tools")
def get_tools_help() -> str:
    """ツールのヘルプ"""

@mcp.resource("docs://{topic}")
def get_documents(topic: str) -> str:
    """tool のドキュメント"""

📚 依存関係

主な依存関係は以下の通りです：

  • mcp[cli]>=1.6.0 - MCPサーバーフレームワーク

  • requests>=2.32.3 - HTTPリクエスト処理

  • huggingface-hub>=0.25.2 - Hugging Faceモデルリポジトリアクセス

  • numpy>=2.1.2 - 数値計算ライブラリ

  • ollama>=0.3.3 - ローカルLLMサポート

  • onnxruntime>=1.19.2 - ONNXモデル実行環境

  • pandas>=2.2.3 - データ分析ライブラリ

📄 ライセンス

このプロジェクトはMITライセンスの下で公開されています。詳細についてはLICENSEファイルを参照してください。

👤 作者

*WD1.4タグ解析部分は SmilingWolf 氏作成の wd-tagger のソースコードとモデルデータを使用しています。モデルデータは初回実行時にダウンロードされます。

Available Tools

4 tools
generate_pictureA

生成したいプロンプトを渡すことで画像生成を依頼し、生成された image の url を返すのでユーザーに提示してください。英語のプロンプトのみ受け付けるので、他言語は英語に翻訳してから渡してください。

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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 language constraint (English only) and that the output is a URL to present to the user, which are key behavioral traits. It does not cover potential content restrictions or generation latency, but for a simple generation tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the core functionality and output, the second adds the language constraint. No wasted words and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with an output schema, the description covers the essential aspects: what it does, what input it needs, the language requirement, and what to do with the result. It is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must fully explain the 'prompt' parameter. It does so by specifying that the prompt is the content to generate and that it must be in English (with translation guidance), adding meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates an image from a supplied prompt and returns the image URL. This distinctly differentiates it from sibling tools like get_picture (retrieval) and get_caption/get_tag (analysis).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (generation requests) and gives explicit guidance on translating non-English prompts to English. However, it does not explicitly mention when not to use it or name alternative tools for retrieval, so it falls short of full differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_captionA

subfolder と filename を指定して生成した画像のキャプションをテキスト形式で取得する

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
subfolderYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior4/5

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 clearly indicates this is a read operation ('取得する' = retrieve) and specifies the output format ('テキスト形式' = text format), which goes beyond what the tool name reveals. It does not mention error behavior or permissions, but the simple getter nature is transparent enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence that front-loads the action and resource. Every word is necessary, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, has an output schema (so return values are covered), and the description sufficiently explains what the tool does. The main gap is the lack of usage guidance, but for a straightforward getter, the description is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the description merely restates the parameter names ('subfolder と filename を指定して') without providing additional meaning, format, or constraints. It vaguely indicates they identify which image's caption to retrieve, but does not clarify what values are valid or what subfolder refers to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action (retrieve/get), a specific resource (caption of a generated image), and the required parameters (subfolder and filename). It effectively distinguishes from siblings like get_picture and get_tag by specifying that it retrieves the caption in text format.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or how it relates to get_picture or get_tag. The usage context is only implied by the tool name and siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pictureA

subfolder と filename を指定して画像の PNG バイナリを取得する

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
subfolderYes

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It states the output is a PNG binary, but does not mention error handling, permissions, path resolution, or any side effects. The tool is likely a read operation, but this is not stated. Minimal behavioral disclosure beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that directly conveys the purpose and required inputs. There is no redundancy or extraneous information. It is appropriately sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately covers the core function and input for a simple retrieval tool, but with no annotations or output schema, it lacks details on response format (e.g., binary vs base64), error conditions, or constraints. It is minimally complete but leaves some ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides no descriptions for the two string parameters, and the description only says they are used to specify the location. It does not clarify what the subfolder is relative to, or any expected format. This adds minimal value beyond the parameter names themselves.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: to retrieve a PNG binary by specifying a subfolder and filename. This distinguishes it from sibling tools like generate_picture (which creates) and the caption/tag tools (which analyze metadata). The verb '取得する' (retrieve) is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving existing images, which distinguishes it from generate_picture. However, it does not explicitly mention alternative tools or provide exclusionary guidance. The context is clear but lacks explicit 'when/not' instruction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_tagB

subfolder と filename を指定して生成した画像からWD1.4タグを解析してテキスト形式で取得する

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
subfolderYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full burden of behavioral disclosure. It states the action (analyze tags and retrieve text) but does not mention read-only semantics, error behavior, preconditions (e.g., image must exist), or any side effects. This leaves significant behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant words or filler. It efficiently conveys the core functionality without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although the tool is simple and has an output schema, the description lacks essential context for agent selection: no usage guidelines, no behavioral traits, and no differentiation from sibling tools. It is minimally adequate for understanding purpose but incomplete for confident invocation in a broader toolset.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates by indicating that both 'subfolder' and 'filename' are used to specify the image. However, it does not elaborate on formats, path conventions, or the relationship between the two beyond the obvious, leaving some semantic gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: given a subfolder and filename, it analyzes the corresponding generated image and retrieves WD1.4 tags as text. It uses a specific verb (取得する/retrieve) and resource (WD1.4 tags), and it is distinct from siblings like get_caption and get_picture.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like get_caption or get_picture. The usage context is only implied by the purpose, with no explicit exclusions or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.2.0
    • First observedgenerate_picture
    • First observedget_caption
    • First observedget_picture
    • First observedget_tag
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: generating an image, retrieving the image binary, retrieving the caption, and retrieving tags. Although three tools share the same parameters, their outputs are completely different, so an agent can easily select the right one.

Naming Consistency5/5

All tool names follow the same lowercase snake_case verb_noun pattern (generate_picture, get_picture, get_caption, get_tag). This consistent structure makes the tool set predictable and easy to navigate.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose as a ComfyUI bridge. It covers image generation and retrieval of the generated outputs without unnecessary bloat, fitting comfortably within the ideal range.

Completeness4/5

The core workflow of generating an image and retrieving its binary, caption, and tags is fully covered. Minor gaps exist, such as no listing or deletion of generated images, but these are not critical for the primary use case.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • comfyui-mcp

    KerbalTheGathering
    F
    license
    Not graded
    quality
    C
    maintenance
    MCP server exposing a local (or LAN) ComfyUI instance's HTTP API as tools, so an LLM client can queue generations, inspect the queue/history, upload reference images, browse installed models/nodes, and pull back generated images.
    -

  • comfy-mcp

    cuzelac
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server that enables AI agents to control a local ComfyUI instance for image generation, allowing workflow understanding, parameter modification, execution, and model discovery.
    23 npm
    3
    Apache 2.0