mealie-mcp

自己ホスト型のレシピ管理・食事計画ツールである Mealie 向けの Model Context Protocol サーバーです。

このサーバーはモデルに Mealie インスタンスの厳選されたビューを提供します。材料と手順を含むレシピの検索・閲覧、ウェブサイトからの新規レシピのインポート、タグとカテゴリの整理、食事の計画、その計画に基づく買い物リストの作成、実際に調理したものの記録ができます。

📖 完全なドキュメント: mealie-mcp.ni-c.de

Mealie の REST API には 175 パスに 259 の操作があります。このサーバーは、一般的なタスクが1回の呼び出しで完了し、危険な領域には一切到達できないように選ばれた 52個のツール を公開しています。Mealie v3.22.0 で検証済みです。すべてのリクエスト形式の正典は、公開されているドキュメント（数か所が古くなっています）ではなく、稼働中のインスタンスの GET /openapi.json です。

要件

• Node.js 22 以上

• Mealie インスタンスと Settings → API Tokens から取得した API トークン

Related MCP server: Blender Open MCP

設定

この2つのブール値はリテラル文字列 true と比較されるため、タイプミスがあると オフ のままになります。stderr の起動行に実際に有効なモードが報告されるので確認してください。

トークンは読み取られた時点でプロセス環境から削除されるため、子プロセスが /proc/<pid>/environ から取得することはできません。

インストール

Claude Desktop、または JSON 設定を受け取る MCP クライアント:

{
  "mcpServers": {
    "mealie": {
      "command": "npx",
      "args": ["-y", "@ni-c/mealie-mcp"],
      "env": {
        "MEALIE_URL": "https://mealie.example.com",
        "MEALIE_API_TOKEN": "…"
      }
    }
  }
}

claude mcp add mealie \
  -e MEALIE_URL=https://mealie.example.com \
  -e MEALIE_API_TOKEN=… \
  -- npx -y @ni-c/mealie-mcp

Codex（~/.codex/config.toml）:

[mcp_servers.mealie]
command = "npx"
args = ["-y", "@ni-c/mealie-mcp"]

[mcp_servers.mealie.env]
MEALIE_URL = "https://mealie.example.com"
MEALIE_API_TOKEN = "…"

またはコンテナとして:

docker run --rm -i \
  -e MEALIE_URL=https://mealie.example.com \
  -e MEALIE_API_TOKEN=… \
  ghcr.io/ni-c/mealie-mcp

ツールを対話的に試すには:

npx @modelcontextprotocol/inspector npx -y @ni-c/mealie-mcp

ツール

レシピ — search_recipes, get_recipe, suggest_recipes, create_recipe, update_recipe, duplicate_recipe, set_recipe_last_made, delete_recipe 🔒

インポート — preview_recipe_url（ドライラン、何も保存しません）、import_recipe_from_url、 import_recipe_from_html_or_json、import_recipe_from_image

整理 — list_organizers, create_organizer, update_organizer, delete_organizer 🔒 — 各ツールは kind: tag | category | tool を受け取ります

材料 — list_foods, create_food, merge_foods 🔒, list_units, create_unit, merge_units 🔒, parse_ingredients

食事プラン — list_mealplans, get_todays_meals, create_mealplan_entry, create_random_meal, update_mealplan_entry, delete_mealplan_entry 🔒

買い物 — list_shopping_lists, get_shopping_list, create_shopping_list, delete_shopping_list 🔒, add_shopping_list_items, update_shopping_list_items, delete_shopping_list_items 🔒, add_recipe_to_shopping_list, remove_recipe_from_shopping_list

クックブック — list_cookbooks, get_cookbook, create_cookbook, delete_cookbook 🔒

メモと共有 — set_recipe_rating, add_recipe_comment, delete_recipe_comment 🔒, list_recipe_comments, list_recipe_timeline, create_timeline_event, list_share_tokens, create_share_token 🔒, delete_share_token

インスタンス — get_about

🔒 は確認トークンが必要です。最初に一度呼び出してトークンを受け取り、それを持ってもう一度呼び出します。

レシピはすべてのツールで slug または UUID のどちらでも指定できます。Mealie は識別子空間をこの2つに分割しており、ツールは渡されたほうを解決します。

あえて公開していないもの

/api/admin 配下のすべて（バックアップ、リストア、メンテナンス、ユーザー・グループ・世帯管理、メール、AIプロバイダー設定）、/api/users/api-tokens（API 資格情報を生成するツールは権限昇格の攻撃面になるため）、認証ルート、ユーザー CRUD とパスワード、ウェブフック、イベント通知、レシピアクション（この3つはすべてインスタンスから外部への HTTP をトリガーします）、食事プランのルール、マイグレーション、シーダー、招待、一括エクスポートと ZIP ダウンロード、アセットと画像のアップロード。

PUT /api/recipes/{slug} も公開されません。これは33フィールドのレシピオブジェクト全体を置き換えるため、これを通した部分更新は材料・手順・タグを黙って失わせます。update_recipe は PATCH を使用します。

安全性

• インスタンスのコンテンツは信頼できない入力です。 レシピは日常的に任意のウェブサイトからスクレイピングされ、コメントは他のユーザーからもたらされるため、インスタンスのコンテンツを含みうるすべてのツール結果には、それをデータとして扱うようモデルに指示する明示的なマーカーが前置されます。これはインポート後も重要です。テキストはデータベースに残り、get_recipe で再び返ってくるからです。

• インポートツールがフェッチを実行するのは、このサーバーではなく Mealie です。 URL はパブリックな http/https アドレスに制限され、ループバック、プライベートレンジ、リンクローカル、.lan/.internal/.local のホストは拒否されます。

• 確認プロンプトは上流のテキストを引用しません — ID、件数、フラグのみです。

• レスポンスには上限があります: 過大な結果は JSON を文字列の途中で切るのではなく項目全体を破棄し、レスポンスボディが 8 MB を超えて読み取られることはありません。

• リダイレクトは拒否されるため、トークンが別のホストに再送信されることはありません。

信頼モデルと脆弱性の報告方法については SECURITY.md を参照してください。

開発

npm install && npm test && npm run build

scripts/verify-live.mjs は、使い捨ての Mealie インスタンスに対して52個すべてのツールを実行します。セットアップ方法は CONTRIBUTING.md に記載されています。

アーキテクチャ図とソーシャルカードは docs/assets/architecture.source.svg と docs/assets/og.json から npm run assets で生成されます。レンダリング済みのコピーが手で編集されていると CI が失敗します。

リリース

すべてはタグによって駆動され、手動の公開手順はありません。

1. CHANGELOG.md の [Unreleased] セクションを新しいバージョンに移動し、日付を入れます。リリースワークフローはそのセクションを awk で抽出するため、## [x.y.z] の見出し形式が重要です。

2. package.json の version を更新します。

3. npm run lint && npm run build && npm run test:coverage.

4. コミットし、署名付きアノテーションタグ を作成します:

git tag -s v0.1.1 -m "v0.1.1"
git push origin main v0.1.1

release.yml はタグが package.json と一致することを検証し、Trusted Publishing（OIDC — 漏洩する npm トークンは存在しません）により provenance 付きで npm に公開し、server.json の両方のパッケージエントリにバージョンを同期し、MCP レジストリに公開し、チェンジログのセクションから GitHub リリースを作成します。ci.yml は並行してマルチアーキテクチャのコンテナイメージを GHCR にプッシュします。

ライセンス

MIT