Cursor 用 MCP 設定のテンプレート｜mcp.json の共有とキーの渡し方

当社は Claude Code などの生成AIの導入と、業務の自動化を支援する側の会社です。チームで Cursor を使うリードエンジニアと情シスの方に向けて、MCP の設定のどこまでをリポジトリに入れ、どこからを各自のパソコンと管理者に任せるかを、Cursor の公式ドキュメントに沿って書きます。MCP サーバーの作り方と、Cloud Agents の設定の細部は扱いません。

ここからは、架空の社内プロジェクト「受注管理」のリポジトリに、GitHub の公式 MCP サーバー（GitHub がクラウドで動かすリモートのサーバー）と、リポジトリの中のスクリプトで検証用のデータベースを読む自作のサーバー「order-db」をつなぐ作例で進めます（説明のための架空の例です）。

置き場所は2つ。同じ名前のサーバーはプロジェクトの設定が使われる

Cursor が読む mcp.json は2か所にあります。プロジェクトの .cursor/mcp.json はそのプロジェクトだけで使う道具、ホームフォルダの ~/.cursor/mcp.json はどのプロジェクトでも使う道具の置き場所です（Cursor「MCP」）。2つのファイルは合わせて読まれ、同じ名前のサーバーが両方にあると、プロジェクトの設定が優先されます（Cursor ヘルプ）。

ファイルを書かずに、サイドバーの［Customize］→［MCPs］からマーケットプレイスのサーバーを入れることもできます。入れたサーバーのオンとオフの切り替えも、この画面でします（Cursor ヘルプ）。

つなぎ方（通信方式）は3つです。stdio は Cursor がパソコンの中でコマンドを起動し、標準入出力でやり取りする方式で、使うのは1人です。SSE と Streamable HTTP は、URL で指したサーバーにつなぐ方式で、複数の人が同じサーバーを使え、OAuth の認証に対応します（Cursor「MCP」）。2026-07-28 版の MCP 仕様が標準として定めるのは stdio と Streamable HTTP の2つです（MCP 仕様「Transports」）。作例では、order-db が stdio、GitHub のサーバーが Streamable HTTP です（GitHub の Cursor 向けの手引き）。

作例：リポジトリに入れるのは、キーの入っていない3つのファイル

作例の .cursor/mcp.json は次のとおりです。値が入るところは、すべて変数の参照にしてあります。

.cursor/mcp.json（作例。コミットする）

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/readonly",
      "headers": {
        "Authorization": "Bearer ${env:GITHUB_PAT}"
      }
    },
    "order-db": {
      "type": "stdio",
      "command": "node",
      "args": ["${workspaceFolder}/tools/mcp/order-db-server.js"],
      "envFile": "${workspaceFolder}/.env.mcp"
    }
  }
}

GitHub のサーバーの URL の末尾の /readonly は、読み取りのツールだけに絞る GitHub の指定です（GitHub「Remote GitHub MCP Server」）。GitHub の Cursor 向けの手引きによると、このサーバーは今のところ OAuth ではなく個人用アクセストークン（PAT）で認証します（GitHub の手引き）。そのトークンを、各自の環境変数 GITHUB_PAT に置きます。

order-db が読む .env.mcp は各自が作るファイルで、コミットしません。代わりに、変数の名前だけを書いた見本と、.gitignore への1行をコミットします。

.env.mcp.example（作例。変数の名前だけを書き、コミットする）

# 各自がこのファイルを .env.mcp に写し、値を入れる
ORDER_DB_URL=

.gitignore に足す1行（作例）

.env.mcp

項目ごとに、何を入れ、間違えると何が起きるか

出典は Cursor「MCP」の「STDIO server configuration」と「Config interpolation」です。Cursor が変数を置き換えるのは command・args・env・url・headers の5つの欄で（固定の OAuth の設定 auth も同じ。envFile も、項目の表に ${workspaceFolder} を使った例があります）、使える変数は次の5種類です。

Claude Code と同じリポジトリで使うとき

Claude Code は、同じ目的のファイルを別の場所で読みます。チームで共有するのはプロジェクトのルートの .mcp.json で（claude mcp add --scope project で登録するとここに書かれます）、環境変数の書き方は ${VAR} と、変数が無いときの既定値を付ける ${VAR:-default} です。.mcp.json のサーバーも、対話のセッションで使う前に承認を求められます（Claude Code「MCP」）。Cursor の .cursor/mcp.json を写して .mcp.json を作るときは、${env:NAME} の書き方を直します。Claude Code 側で、どのフォルダに触らせるかの決め方はExcel MCP の記事に書いています。

キーの渡し方は、stdio とリモートのサーバーで分かれる

MCP の仕様は、認証の取り決め（OAuth）を HTTP でつなぐサーバーのために定めていて、stdio のサーバーはそれに従わず、資格情報を環境から得るべき（SHOULD NOT … instead retrieve credentials from the environment）としています（MCP 仕様「Authorization」）。Cursor の設定も、この線で2つに分かれます。

OAuth に対応したサーバーなら、キーを配る必要はありません。マーケットプレイスから入れたサーバーで認証が要るものは、OAuth でサインインします。動的なクライアント登録に対応しないサーバーには、mcp.json の auth に固定のクライアント ID とシークレットを書けますが、その値も ${env:MCP_CLIENT_ID} のように環境変数で渡すよう、公式が書いています（Cursor「MCP」）。

.env.mcp に値をそのまま書いて置きたくないなら、パスワード管理ツールの CLI で、起動するときに値を入れる手もあります。たとえば 1Password の CLI の op run は、op:// で始まる保管場所の参照を書いた環境ファイルを --env-file で読み、値を環境変数にしてからコマンドを起動します。参照だけを書いた環境ファイルは、1Password の手引きもソース管理に入れる使い方を示しています（1Password「Load secrets into the environment」）。各自のパソコンで 1Password の CLI が使える状態になっている前提で、order-db をこれで起動する形を書くと次のとおりです。作例で、動かして確かめてはいません。1Password の手引きの例は --env-file=ファイル の形で、下のように空白で分けた形は例示されていないので、使う前に op run --help で確かめてください。

.cursor/order-db.op.env（作例・未検証。値ではなく参照だけを書く）

ORDER_DB_URL=op://保管庫の名前/項目の名前/欄の名前

1Password の CLI 経由で order-db を起動する（作例・未検証）

"order-db": {
  "type": "stdio",
  "command": "op",
  "args": ["run", "--env-file", "${workspaceFolder}/.cursor/order-db.op.env", "--",
           "node", "${workspaceFolder}/tools/mcp/order-db-server.js"]
}

Cursor の args の例は、変数を文字列の先頭に置いたものだけなので、変数を先頭に置けるよう引数を分けています。MCP Allowlist を使う会社では、この形だとコマンドの全文が op run … で始まるので、下の節で書く *node … の形の登録には当たりません。

キーをコミットしてしまったとき

キーを書いたまま mcp.json をコミットしてしまったら、最初にそのキーを失効させるか、作り直します。GitHub は、履歴を書き換えて消す作業には副作用が多く、消しきれる保証もないとして、失効かローテーションを最初の手順に挙げています（GitHub Docs「リポジトリからの機密データの削除」）。

キーの権限は、使うツールの分だけにする

Cursor は、MCP サーバーに渡すキーは必要な権限だけに絞ったものを使い、大事なつなぎ先では、サーバーのコードを読んでから使うよう勧めています（Cursor「MCP」の Security considerations）。作例の GitHub なら、URL を読むだけの /readonly にし、PAT の権限も読み取りにしておくことをお勧めします。AI が使うツールを選び違えても、サーバーとキーの両方の側で書き込みが止まるからです。

clone したメンバーの画面で起きること

リポジトリの .cursor/mcp.json は、読み込まれただけでは動きません。Cursor は MCP の接続ごとに承認を求めます。ツールの呼び出しについて、Cursor の「Agent Security」のページは1回ずつ承認が要ると書いていますが（Cursor「Agent Security」）、どう扱われるかは実行のモードで決まります。ツール名の横の矢印を開くと、渡す引数を見てから許可できます（Cursor「MCP」）。

Cursor 3.6（2026年5月）からは、［Cursor Settings］→［Agents］→［Approvals & Execution］の既定の実行のモードが Auto-review です。許可リストにある MCP のツールはすぐ動き、それ以外は分類器（Cursor が用意する小さなモデル）が判断します。Cursor は、Auto-review は安全の境界ではなく、分類器は誤って通すことも止めることもあると書いています。許可リストだけで決めたいなら Allowlist のモードを選び、許可リストに無いツールは承認してから動かします（Cursor「Run Modes」、Cursor ヘルプ）。

許可リストはファイルでも書けます。ホームの ~/.cursor/permissions.json と、リポジトリの .cursor/permissions.json の中身はつなげて読まれ、ツールは「サーバー名:ツール名」、そのサーバーのツール全部は「サーバー名:*」で指します（Cursor「Deployment patterns」）。リポジトリに入れた許可は、clone した全員の自動実行の許可に足されるので、入れるのは読むだけのツールに限ることをお勧めします。

.cursor/permissions.json（作例。読むだけのツールだけを入れる）

{
  "mcpAllowlist": [
    "github:get_file_contents",
    "github:search_code",
    "github:list_issues"
  ]
}

ツールの名前は、GitHub の公式サーバーの README にある名前です。

mcp.json の起動のコマンドは、承認すればそのまま実行されます。MCP の公式のセキュリティの手引きは、設定に悪意のある起動コマンドを紛れ込ませる攻撃を挙げ、攻撃者は MCP のクライアントの権限で任意のコマンドを実行できると書いています（MCP「Security Best Practices」）。締めに書くとおり、.cursor/mcp.json の変更は取り込む前に読みます。

.env.mcp のようなファイルは、.gitignore に入っているものと Cursor の既定の無視リスト（.env* を含む）に当たるので、エージェントが Cursor の機能で読むことは止められます（完全ではないと公式も書いています）。ただし Cursor は、ターミナルと MCP のツールはこの無視の設定に従えないと書いています（Cursor「Ignore file」）。.env.mcp を置いたパソコンでは、ターミナルのコマンドを承認なしで動かす範囲を広げすぎないようにします。

管理者が決められること：配るのはマーケットプレイス、縛るのは MCP Allowlist

当社は、リポジトリで配るか管理者が配るかを、そのサーバーがリポジトリの中身に頼って動くかで分けることをお勧めします。リポジトリの中のスクリプトで動くサーバーは、そのリポジトリの外では動かないからです。

Teams と Enterprise のプランでは、管理者がダッシュボードの［Plugins & MCPs］で、チームの MCP サーバー（Team MCP）を登録できます。登録したサーバーは Cloud Agents から使え、［Team MCP Servers］の［Add to Team Marketplace］で既定（Default）のチームのマーケットプレイスにつなぐと、メンバーが［Customize］から、自分の Agent Window・IDE・CLI に入れて設定できるようになります（Cursor「MCP」、「Plugins」）。チームのマーケットプレイスは、Teams では1つまで、Enterprise では数の制限がありません。作例の GitHub のように、どのリポジトリでも使うサーバーは、ここで一度配れば、リポジトリごとに書かずに済みます。

マーケットプレイスにつないでも、全員に入るわけではありません。入れ方は、各自が選んで入れる［Default Off］、最初から入るが外せる［Default On］、常に入り外せない［Required］から選び、見られる人は［Marketplace Access］で組織のグループに絞れます。認証が要るサーバーは、メンバーがそれぞれサインインすることがあります。マーケットプレイスからつないだサーバーを外したり、マーケットプレイスを消したりすると、Team MCP のサーバーごと消えることがあるので、確認の画面を読んでから進めます（Cursor「Plugins」）。

Enterprise では、動かしてよいサーバーを MCP Allowlist で決められます。［Team Settings］→［MCP Configuration］で、stdio のサーバーは起動のコマンドの形、リモートのサーバーは URL の形で登録し、許可リストが有効なあいだは、どれにも当てはまらないサーバーは動きません。ただし管理者は、利用者が登録の形の外で自分のサーバーを使うこと（User MCP extensions）を許すこともできます（Cursor「MCP」）。許可しても、メンバーのパソコンに配られるわけではありません（Cursor「Model and Integration Management」）。

コマンドの照合は、command と args を空白でつないだ全文に対して行われ、npx はふつう /usr/local/bin/npx のような絶対パスになります。そのため公式は、先頭に * を付けた *npx -y @acme/mcp-tool@latest のような書き方を例に挙げています（同じページ）。作例なら、order-db は *node */tools/mcp/order-db-server.js、GitHub は https://api.githubcopilot.com/mcp/* のように登録できます。

MCP Allowlist の画面では、許可したサーバーごとに、さらに次の2つを決められます。

出典は 「Model and Integration Management」です。承認なしで動くツールの許可リストは、ダッシュボードなど管理者の設定、permissions.json（ホームとリポジトリをつなげたもの）、エディターの設定の順に効き、上のものがあれば下は使われず、足し合わされません。~/.cursor/permissions.json は MDM（Jamf・Kandji・Intune など）でパソコンに配ることもできます（Cursor「Deployment patterns」）。管理者が許可リストを決めていれば、リポジトリの permissions.json の中身は効かなくなります。

つながらない・値が入らないとき

最初のコミットは、キーの入っていない3つのファイルから

作例の .cursor/mcp.json、.env.mcp.example、.gitignore の1行を1つのプルリクエストにして、レビューで「値が1つも入っていないか」「起動のコマンドを読んで何が動くか分かるか」を確かめてから取り込んでください。どのリポジトリでも使うサーバーが増えてきたら、そこからはマーケットプレイスでの配布に移します。

つなぐ先の設計は、GitHub・GitLab の Issue と PR を MCP でエージェントに任せる設計と社内だけで使う Discord の Bot に何を読ませるかの設計に書いています。チームの MCP の設定と運用のルールづくりは、当社のClaude Code 導入支援で一緒に進められます。

仕様と画面の名前は、2026年10月14日に、Cursor の公式ドキュメントとヘルプ、MCP の公式ドキュメントと仕様（2026-07-28 版）、GitHub・1Password・Claude Code の公式ドキュメントで確かめました。Cursor の画面の名前と既定の設定は、版によって変わります。