Ollama MCP 設定 2026：ローカルモデルをファイル・データベース・API につなぐ MCPサーバー入門

クイックファクト

• プロトコル： JSON-RPC 2.0 を stdio（ローカルサブプロセス）または Streamable HTTP（リモート）で通信。従来の HTTP+SSE transport は非推奨です。ローカルエージェントはほぼ stdio のみ使用します。現行の仕様リビジョンは 2026-07-28 です。
• 起源： Anthropic がオープン仕様として作成（modelcontextprotocol.io）。modelcontextprotocol/servers で今もメンテナンスされているリファレンスサーバーはごく一部（filesystem、git、fetch、memory など）で、SQLite、PostgreSQL、Puppeteer、GitHub は servers-archived に移されました。現在は各ベンダーが自社のサーバーを提供しています。
• ローカルクライアント： Goose（オープンソース、リポジトリは aaif-goose/goose）、Cline（VS Code 拡張）、Continue.dev（VS Code/JetBrains）、LM Studio（デスクトップアプリ）、加えて複数の CLI ツール。
• 互換 Ollama モデル： ネイティブ tool call 学習を持つすべてのモデル。例：Gemma 4 31B、GLM-4.7 Flash、Qwen3.6 27B、Qwen3 32B、Qwen3-Coder 30B、Llama 3.3 70B。
• サーバー transport の既定： ローカルプロセスは stdio；複数マシンや複数エージェント間でサーバーを共有する場合のみ Streamable HTTP。
• 設定はクライアント側にあります： Goose は ~/.config/goose/config.yaml の extensions ブロック（または goose configure）を読み、Cline と Continue.dev はそれぞれ独自の MCP 設定を持ちます。考え方はどれも同じ：サーバー名、command、args、env vars。
• Claude Desktop 不要。 プロトコルはオープンで Claude Desktop から独立しており、ここで使うサーバーはオープンソース（ライセンスは各自確認してください）で、準拠する任意のクライアントで動作します。

MCP がローカルモデルに対して実際に解放するもの

• 「このリポジトリのすべての TODO を見つけ、ファイルごとにグルーピングして、Markdown 要約を notes/todos.md に書き出してください」 — filesystem サーバーが読み、モデルがグルーピングし、同じサーバーが書き込みます。エンドツーエンドで往復 1 回。
• 「今四半期の売上トップ 10 顧客を出して、グラフ化してください」 — postgres サーバーが SQL を実行（read-only ロール）、モデルが要約、filesystem 経由で CSV を書き出してチャートツールに渡します。
• 「Hacker News のフロントページを開いて、AI 関連トップ 3 記事を見つけて要約し、私の reading list に追記してください」 — playwright サーバーがブラウザを操作し、モデルが抽出と要約、filesystem が追記します。
• 「私の fork に対して chore: bump deps というタイトルのドラフト PR を開き、失敗中の CI run を本文にリンクしてください」 — github サーバーが PR を作成、run を取得、本文にリンクを書き込みます。
• 「events.db の最新 100 行を見て、新しいエラースパイクの原因になっているユーザー ID を教えてください」 — データベースサーバーがデータのコピーを照会、モデルが推論、回答をチャットパネルで読みます。
• いずれも以前はクラウドモデルとホストツール、または手書きスクリプトを必要とした「文 → アクション」ワークフローです。MCP は同じサーバーを複数クライアント間で、同じモデルを複数サーバー間で再利用できる層です。

最もよく使われる 4 つの MCPサーバーの比較

構成要素のつながり

• Ollama はバックグラウンドサービスとして 127.0.0.1:11434 で動作し、OpenAI 互換 API でモデルを提供します。MCP のことは知りません — chat completion に応答し、モデルが要求すれば tool call を出すだけです。
• MCP クライアント（Goose、Cline、Continue.dev、LM Studio）が橋渡し役です。モデルについては Ollama と、ツールについては MCPサーバーと話します。モデルが tool call を出すと、クライアントが正しいサーバーへルーティングし、結果を取得し、会話に戻します。
• MCPサーバー は機能ごとに独立したサブプロセスです。stdio で JSON-RPC 2.0 を話します。各サーバーが Tools、Resources、Prompts を公開し、クライアントがそれらを統合してモデルに見せます。
• stdio transport ですべてがローカルに留まります。 サーバーはクライアントによって起動され、stdin/stdout で通信し、クライアント終了時に終了します。サーバー自身が接続を開かない限り（ブラウザサーバーは開きます、filesystem とデータベースサーバーは開きません）、ネットワーク経由になりません。
• モデルはフラットなツールリストを見ます。 モデル視点ではサーバーは存在せず、filesystem.read_file、playwright.browser_navigate、github.create_pull_request のようなツール名のリストがあるだけです。クライアントがルーティングを処理します。

MCP 設定：Ollama + Goose を 15 分で

• Step 1 — Ollama をインストール。 ollama.com/download（macOS/Windows/Linux）からダウンロード。curl http://127.0.0.1:11434/api/tags でサービスが動作していることを確認してください。
• Step 2 — tool calling モデルを pull。 Gemma 4 31B（gemma4:31b）、GLM-4.7 Flash（glm-4.7-flash）、Qwen3.6 27B（qwen3.6:27b）、Qwen3 32B（qwen3:32b）または Llama 3.3 70B（llama3.3:70b）から選択。32 GB unified memory または 24 GB VRAM で 26B–32B を Q4_K_M で快適に動かせます。
• Step 3 — Goose をインストール。 macOS または Linux では curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash（または brew install block-goose-cli）を実行します。Windows では Goose ドキュメントの PowerShell インストーラか WSL を使ってください。CLI は goose としてインストールされます。
• Step 4 — Ollama をプロバイダーとして設定。 goose configure を実行、ollama をプロバイダーに選択、モデルを pull したものに、host を http://127.0.0.1:11434 に設定（空欄でも localhost:11434 になります）。Goose は ~/.config/goose/config.yaml に書き込みます。Ollama の既定コンテキストウィンドウは小さいことがあり（Goose のドキュメントでは 4096 トークンとされています）、その場合 Goose が extension を無視することがあります — OLLAMA_CONTEXT_LENGTH=32768（またはそれ以上）を付けて Ollama を起動してください。
• Step 5 — filesystem の MCPサーバーを追加。 goose configure を実行して Add Extension、続いて Command-line Extension を選ぶか、~/.config/goose/config.yaml に extensions ブロックを追加します（下に設定例）。一度だけ試すなら goose session --with-extension "npx -y @modelcontextprotocol/server-filesystem /path/to/workspace" でそのセッションに限って有効にできます。goose session を開始し、テストディレクトリのファイル一覧を尋ねてください。最初のターンでサーバー接続が確認できます。
• Step 6 — 実際のタスクで検証。 goose session を試し、「notes/ 内の各 Markdown ファイルについて、タイトルと単語数の一覧を作って結果を notes/index.md に書いてください」と尋ねます。エージェントが読み、要約し、書き戻せばループは動作しています。

# 1. Pull a tool-calling model
ollama pull gemma4:31b

# 2. Install Goose (macOS / Linux)
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# 3. Configure Ollama as the provider
goose configure
# Provider: ollama
# Model:    gemma4:31b
# Host:     http://127.0.0.1:11434

# 4. Give Ollama a context window big enough for tool use, then start a session
OLLAMA_CONTEXT_LENGTH=32768 ollama serve   # in a separate terminal
goose session

Filesystem サーバー：サンドボックス化されたディレクトリの読み書き

• インストール： リファレンスサーバーは @modelcontextprotocol/server-filesystem、npx -y 経由で実行（グローバルインストール不要、Node.js が必要）。今もメンテナンスされているリファレンスサーバーの 1 つです。Goose、Cline、Continue.dev はすべて設定ブロックから自動起動します。
• パスを allow-list： サーバーは 1 つ以上のディレクトリ引数を受け取り、それ以外の場所での操作を拒否します。常に明示的で範囲の狭いパスを渡してください — ~ や / は絶対に避けてください。
• 公開ツール： read_file、read_multiple_files、write_file、edit_file（行ベースの置換）、list_directory、search_files、move_file、create_directory、directory_tree。モデルからは filesystem.read_file のように見えます。
• 便利機能： directory_tree は JSON ツリーを返し、特定ファイルを読む前にモデルが構造を把握するのに最適です。search_files は grep のような再帰検索を行います。
• リスク面： サーバーは allow-list を尊重しますが、リスト内では完全な読み書き権限を持ちます。allow-list を唯一のバリアと捉え、ホームフォルダではなく専用 workspace ディレクトリを選んでください。

# ~/.config/goose/config.yaml
extensions:
  filesystem:
    type: stdio
    name: filesystem
    enabled: true
    cmd: npx
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/agent-workspace"]
    envs: {}
    timeout: 300

データベースサーバー：Postgres（と SQLite）を安全に照会する

• Postgres：postgres-mcp（Crystal DBA、MIT ライセンス） は read-only モードを備えた選択肢です（PyPI の最新リリースは 2025 年 5 月なので、頼る前にリポジトリの活動状況を確認してください）。uvx postgres-mcp --access-mode=restricted（または pipx install postgres-mcp、Docker イメージ）で起動し、接続 URI は DATABASE_URI 環境変数で渡します。制限モードでは read-only トランザクションとクエリの時間制限が適用され、非制限モードは開発専用です。
• 専用の read-only ロールも併用してください。 制限モードが 1 つ目のバリア、データベースロールが 2 つ目です。SELECT のみの権限を持つ agent_ro ロールを作成し、そのロールの接続文字列を使います。
• SQLite：リファレンスサーバーはアーカイブ済みです。 Python パッケージ mcp-server-sqlite（npm パッケージではありません。最終リリースは 2025 年 4 月）で、まだ動く可能性はありますが修正は提供されません。ファイルのコピーにだけ向け、唯一のコピーには絶対に向けないでください。あるいはデータを Postgres に読み込んでください。コミュニティ製の SQLite サーバーは、ファイルを渡す前にコードを読んでください。
• スキーマ認識： 分析的な質問の前に「テーブル一覧を出して、よく使われる 5 つを describe してください」とエージェントに頼んでください — スキーマを確認したモデルは、カラム名を推測したモデルよりはるかに精度が高くなります。
• コスト： クエリは直接データベースに飛びます。1 億行テーブルへの不適切な SELECT * は人間がやった場合と同じ事故です — ロールは独立した接続プールに置き、statement timeout を設定してください。

# ~/.config/goose/config.yaml
extensions:
  postgres:
    type: stdio
    name: postgres
    enabled: true
    cmd: uvx
    args: ["postgres-mcp", "--access-mode=restricted"]
    envs:
      DATABASE_URI: "postgresql://agent_ro:${PG_AGENT_PASSWORD}@127.0.0.1:5432/analytics"
    timeout: 300

ブラウザサーバー：Playwright MCP でブラウザを操作

• 使うサーバー： Microsoft の @playwright/mcp（npx @playwright/mcp@latest）を使います。旧 @modelcontextprotocol/server-puppeteer は「no longer supported」と表示されており、@modelcontextprotocol/server-playwright という npm パッケージは存在しません。
• 公開ツール： browser_navigate、browser_snapshot、browser_click、browser_type、browser_fill_form、browser_evaluate（JavaScript 実行）、browser_take_screenshot、browser_tabs、browser_wait_for。モデルはページを browser_snapshot（アクセシビリティスナップショット。Playwright MCP は操作にはスクリーンショットよりこちらを推奨）で読み、スクリーンショットは見るためだけに使います。
• レイテンシ： 実ブラウザセッションはアクションあたり 1–5 秒。多段ブラウジングは簡単に 30–60 秒、数万トークンを消費します（ページ内容が大きいため）。32K+ コンテキストウィンドウを使ってください。
• 要素参照： モデルはスナップショット内の参照を使って要素をクリックします。小さいモデルはよく外しますが、27B+ tool calling モデルなら一般的なパターンを安定して扱います。タスクは絞ってください — 「この URL のタイトルと最初の段落を抽出してください」のほうが「サイトを巡回して contact ページを探してください」よりはるかに信頼できます。
• 良いユースケース： リサーチ（ページを開く、要約する、ノートに追記）、回帰テスト（ナビゲート、クリック、screenshot）、自分が管理するページのフォーム入力。悪いユースケース：本番 Web 上の誤クリックが結果を伴うあらゆる作業。

# ~/.config/goose/config.yaml
extensions:
  playwright:
    type: stdio
    name: playwright
    enabled: true
    cmd: npx
    args: ["@playwright/mcp@latest"]
    envs: {}
    timeout: 300
# Block obviously dangerous endpoints at the OS firewall level
# rather than relying on the agent to refuse them.

GitHub サーバー：ローカルモデルから repo、issue、PR を扱う

• インストール： GitHub 公式の github/github-mcp-server を使い、Docker イメージ（ghcr.io/github/github-mcp-server）から GITHUB_PERSONAL_ACCESS_TOKEN 環境変数に PAT を入れて実行します。旧 @modelcontextprotocol/server-github npm パッケージは「no longer supported」と表示されているので、新規構成では使わないでください。
• 公開ツール： search_repositories、get_file_contents、create_or_update_file、create_pull_request、list_issues、create_issue、add_issue_comment、merge_pull_request、ほか多数。フルセットは大きいですが、ほとんどのタスクは 5–10 ツールで足ります。
• PAT を絞る。 特定 repo に絞った fine-grained PAT を、必要最小限の権限（閲覧は Read、PR/issue 作成は Write）で使ってください。実験的エージェントに対して repo 権限のクラシック PAT は使わないでください。
• 実例ワークフロー： トリアージ（「直近の open issue 20 件を読んで、グルーピングしてラベル案を出してください」）、ドラフト作成（「README を読んで誤字を直す PR を開いてください」）、レポーティング（「今週 stale な PR を教えてください」）。
• リスク面： エージェントは issue や PR を作成、コメント、（書き込み権限があれば）コミットを push できます。merge 系ツールはモデルとワークフローの両方を信頼できる場合以外は無効化してください — fine-grained PAT の repo での誤マージは復旧可能ですが、すぐに気付いた場合のみです。

# ~/.config/goose/config.yaml
extensions:
  github:
    type: stdio
    name: github
    enabled: true
    cmd: docker
    args: ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"]
    envs:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GH_AGENT_PAT}"
    timeout: 300
# Fine-grained PAT scoped to one or two test repos,
# not your personal account-wide classic token.

モデルを信頼しないセキュリティモデル

• filesystem サーバーを 1 ディレクトリに限定。 ~ や / は絶対に使わないでください。agent-workspace/ フォルダを選び、エージェントに触らせたいファイルのコピーを置きます。エージェントが暴走しても、最悪のケースは 1 フォルダです。
• データベースサーバーは既定で read-only 運用。 専用の agent_ro ロールを SELECT のみの権限と 30 秒の statement timeout で作成すれば、ある種のインシデントカテゴリ全体が消えます。
• 書き込みやシェル系ツールはすべて明示的承認の後ろに。 Goose、Cline、Continue.dev はそれぞれツール単位の承認ルールをサポートしています。読み取りツールは既定で許可、write_file、edit_file、execute_command、create_pull_request、フォーム送信を行うブラウザアクションには承認を要求してください。
• 監査ログを使ってください。 すべての MCP クライアントは tool call と結果を記録します。長時間セッション後にログをスキャンしてください：モデルがあなたが想定しなかった操作を試みていることに気付けます（無害な場合も、権限を絞り直すべき場合もあります）。
• サードパーティーアクセスはトークンスコープを狭く。 GitHub PAT は 2 つのテスト repo に絞る。Postgres ロールは read-only。ブラウザセッションは認証情報なし。モデルはいずれあなたが想定しなかった操作を試みます；できることの限界は、モデルが正しく振る舞うことに依存させてはいけません。
• 機密データ作業時はエージェントを air-gap してください。 プライベートデータを扱うとき、エージェント実行中はホストのネットワークアクセスを無効化（または network namespace を使用）してください。ローカルスタックはマシンから何も出しませんが、defense-in-depth はサードパーティーサーバーの不具合をキャッチします。
• MCPサーバーの選定は依存関係選びと同様に扱ってください。 リファレンスサーバーはよくメンテされていますが、サードパーティーサーバーの多くはそうではありません。認証情報が必要なサーバーは、入れる前にコードを読んでください。

ローカル MCP vs Claude Desktop：何が変わり、何が残るか

ローカル MCP 用 tool calling モデルの選定

• Gemma 4 31B（gemma4:31b） — Google の tool call 学習はサイズに対して best-in-class。16 GB unified memory または 24 GB VRAM で Q4_K_M に収まります。一般推論は良好；連鎖した tool call にはやや保守的です。
• GLM-4.7 Flash（glm-4.7-flash） — Zhipu のモデルは tool call 信頼性が非常に高く、out of the box で 128K コンテキストウィンドウ。Gemma 4 よりやや重め；24 GB GPU に余裕で収まります。
• Qwen3.6 27B（qwen3.6:27b） — Ollama で使える新しい Qwen の選択肢（約 18–19 GB、256K コンテキスト、tool calling 対応）。Qwen3 32B（qwen3:32b） — バランスが良く、dense な 32B が MCP をクリーンに処理し、長時間エージェントループでも安定します。Qwen3-Coder 30B（qwen3-coder:30b） はエージェント作業がコード形態の場合の最良の選択です。
• Llama 3.3 70B（llama3.3:70b） — 最高の天井ですが最も重い。Q4_K_M で 48 GB+ unified memory または 2× 24 GB GPU。ハードウェアが対応している場合のみ；通常は小さいモデルで十分です。
• MCP 作業で避けるべきもの： 7B 未満すべて、明示的な tool call 学習のない汎用モデルすべて。形式不正な call を出してループが止まり、ハーネスを責めることになりますが — ハーネスは問題ありません。
• 任意のモデルで tool call 品質を改善する構造化プロンプティング手法は、Chain-of-Thought Prompting を参照してください。
• 頭ごなしの比較データは、2026 年のローカル tool calling 最強モデル を参照してください。

MCP vs プレーン Function Calling：違いは何か

• Function calling は LLM 側の能力です：モデルがツール名と引数を記述する構造化 JSON を出力します。OpenAI Tools、Anthropic Tools、Ollama の tool call API はすべて同じ考え方を、わずかに異なる wire format で使います。
• MCP はその上に乗ります：ツールがどう記述、発見、呼び出し、返却されるかを、プロセス間で標準化します。Function calling モデル単体ではあなたの filesystem を知りませんが、MCPサーバーが filesystem 操作を提供し、クライアントがモデルの function calling API にマッピングし、モデルがそれを呼び出せるようになります。
• メリットは interop です。 filesystem サーバーを一度書けば、Claude Desktop、Goose、Cline、Continue.dev、LM Studio が変更なしで使います。モデルを Claude から Gemma 4 に変えても、サーバーは変わりません。
• Function calling だけでエージェントは作れます。 プロジェクトごとに filesystem、データベース、ブラウザのハンドラを再実装することになります。MCP ならそれらは out-of-the-box の依存関係です。
• 1 回限りのスクリプトには素の function calling のほうが簡単です。 プロジェクトやモデルをまたいで再利用したいものなら、数日以内に MCP のほうが手間が少なくなります。

日本ユーザーのための活用ポイント

• METI AI ガバナンス 2024： 経済産業省の AI ガバナンスガイドラインは、特に金融、医療、法務など規制業界での AI 利用において、データ保護とトレーサビリティを求めています。ローカル MCP スタックは外部データ送信を排除し、監査ログでトレーサビリティを担保するため、これらの要件にクリーンに整合します。
• 個人情報保護法（APPI）： 顧客データや従業員データをクラウド AI プロバイダーに送るには、第三者提供の同意とリスク評価が必要です。ローカル推論ではこの第三者提供自体が発生せず、契約上の負担と説明責任が大幅に軽減されます。
• 日本企業のユースケース： 法律事務所、税理士法人、医療機関、製造業の設計部門、人事 — クライアント・患者・従業員データを OpenAI、Anthropic、Google に送れない領域すべて。十分なユニファイドメモリを搭載した Apple シリコンの Mac や RTX 4090 搭載ワークステーションで 27B–32B モデルが動き、書類要約、契約レビュー、社内データベースに対するコード片の検証ができます。
• 東アジアのデータ越境： 日本、シンガポール、マレーシア、韓国はそれぞれ独自のデータ residency 枠組みを持ち、APAC 全域へのクロスボーダー転送には個別の評価が必要です。ローカル推論はこの転送を完全に回避し、東アジアでの multi-region 展開時のコンプライアンス負担を取り除きます。
• 日本の中堅企業（中小企業）： 大企業向けに作られたクラウド AI 契約は、中小企業にとってはコスト・契約レビュー両面でハードルが高いケースが多く、PoC が頓挫しがちです。ローカル MCP スタックは設備投資 1 回（マシン代）のみで月額課金なし、契約も社内のみで完結します。
• 監査と説明責任： MCP クライアントの監査ログ（Goose、Cline、Continue.dev）は「エージェントが想定外の操作をしていないこと」を示す主たる証拠になります。WORM ストレージや、エージェント自身からは上書き不可能な Git リポジトリに保存してください。日本の監査文化との親和性は高いです。

ローカル MCP 設定でよくある間違い

• 間違い 1：小さい汎用モデルを使う。 7B 未満（および tool call ファインチューニングなしの 7B–13B 汎用モデルの大半）は形式不正な tool call を出します。27B+ tool call チューン済みモデルを使い、ハーネスと戦うのをやめてください。
• 間違い 2：ホームディレクトリを allow-list する。 「テストだけ」のはずの ~ の allow-list は本番運用に残ります。最初から専用の agent-workspace を作ってください。
• 間違い 3：データベースサーバーを read/write モードで放置。 自信を持ったエージェントが本番テーブルに書く DELETE クエリこそ、これで防げるインシデントです。agent_ro を既定にし、書き込みが明示的に必要なタスクのためだけに、その期間だけ別の writable ロールを立ててください。
• 間違い 4：すべてのツールを自動承認。 「すべて承認」トグルは便利で危険です。読み取りツール（read_file、list_directory、query）は自動承認、書き込み・シェル・PR 系は常に承認を要求してください。
• 間違い 5：多段ブラウザ作業に 32K コンテキストモデル。 ページ内容は大きく、3 ページ巡回で推論前に 32K トークンを使い切ることがあります。ブラウザ重めのタスクには 128K コンテキストモデルを使ってください。
• 間違い 6：エージェントに判断力があると仮定。 ありません。モデルは「これは本番データベース」「この PR はデプロイされる」という概念を持ちません。権限が唯一のバリアです。
• 間違い 7：リファレンスサーバーを最初に全部入れる。 ツールが多い = system prompt が大きい = ツール選択が遅く不正確になります。filesystem から始めて、必要になったら他を追加してください。
• 間違い 8：古いチュートリアルのアーカイブ済みリファレンスサーバーを入れる。 npm パッケージ @modelcontextprotocol/server-postgres、-puppeteer、-github は「no longer supported」と表示されており、SQLite サーバーもアーカイブ済みです。古いガイドには、存在しない npm パッケージ（server-sqlite、server-playwright）を挙げているものもあります。上で挙げたメンテナンスされているサーバーを使ってください。
• 間違い 9：MCP の設定を Ollama に書こうとする。 Ollama に MCP の設定項目はありません。サーバーはクライアント側で設定します（Goose の extensions、Cline や Continue.dev の MCP 設定）。

出典

• Model Context Protocol 仕様 — 公式仕様、JSON-RPC スキーマ、transport およびライフサイクル定義（2026-07-28 の変更履歴を含む）。
• modelcontextprotocol/servers GitHub リポジトリ — メンテナンスされているリファレンスサーバー（filesystem、git、fetch、memory など）とアーカイブ済みサーバーの一覧。
• github/github-mcp-server — GitHub 公式の MCPサーバー、Docker とバイナリのセットアップ。
• microsoft/playwright-mcp — Playwright MCPサーバーとそのブラウザツール。
• crystaldba/postgres-mcp — 制限（read-only）アクセスモードを持つ Postgres MCPサーバー。
• Goose ドキュメント — CLI インストール、Ollama プロバイダー設定、extension（MCPサーバー）の設定構文。
• Ollama モデルライブラリ — 利用可能なローカルモデル、tool call サポートフラグ、本ガイドで参照する量子化レベル。
• Cline GitHub リポジトリ — VS Code MCP クライアント実装、MCP サーバーパネル。
• Continue.dev ドキュメント — Continue.dev クライアント用 mcpServers 設定ブロックリファレンス。

よくある質問

関連資料

• 2026 年のローカル tool calling 最強モデル — 上記推奨モデル（Gemma 4、GLM-4.7、Qwen3、Llama 3.3）の頭ごなしベンチマーク。
• 自律ローカルエージェントは実際に動く — 長時間タスクでローカル MCP エージェントが何を確実にこなし何ができないかの現実チェック。
• Continue.dev vs Cline vs Aider：2026 年最強のローカルコーディングエージェント — コード形態作業のための隣接エージェント文脈；Cline と Continue.dev も MCP クライアント。
• 2026 年の最強ローカル LLM — より広い open-weights ランドスケープのモデル権威。
• ローカル AI エージェントで Zapier を置き換える — 同じ MCP スタックのワークフロー自動化フレーミング。
• Power Local LLM ハブ — ガイド全集。