ひとつだけ default answer を出すなら、人気の Claude Code MCP を片っ端から入れるところから始めないことです。最初に足すべきなのは、いま一番大きい external workflow gap を閉じる integration です。2026 年 4 月 8 日時点では、それはたいてい GitHub です。repo、PR、issue が bottleneck なら GitHub、古い docs が何度も足を引っ張るなら Context7 のような current-docs MCP、browser QA や再現確認が本題なら Playwright、そして incident debugging が本当に日常の仕事なら Sentry のような observability connector を考えます。official または clearly trusted surface があるならまずそこから入り、workflow が本当に共有レベルになってから .mcp.json や plugin-bundled MCP に進む方がきれいです。
この答えは、多くの “Claude Code MCP おすすめ一覧” よりかなり狭いです。でも実際には、その方が役に立ちます。高くつく失敗は、別の server name を一つ見逃すことではありません。最初の integration が value を証明する前に、Claude Code を connector の山にしてしまうことです。
2026 年 4 月 8 日時点の Anthropic の current docs では、official connectors、remote MCP servers、local または project-scoped MCP configs、そして plugin-bundled MCP がすでに別々の surface として扱われています。Claude Code MCP docs でも、project-scoped servers は .mcp.json に置くこと、利用前に approval が入ること、third-party servers には trust と prompt-injection risk の注意が必要であることが明記されています。つまり、最初の判断は単なる tool choice ではなく、packaging と trust boundary の choice でもあります。
“エビデンス注記：この記事は Anthropic の current Claude Code MCP docs、Connectors overview、connector help-center guide を 2026 年 4 月 8 日に確認した内容と、日本語圏で自然な
最初に何を入れるかの reader language をもとに再構成しています。
最初の判断を速くする route board
たくさんの server names を見比べる前に、今日壊れている workflow を先に特定します。
| いまの bottleneck | 最初に試す MCP | ベストな first surface | Stop rule |
|---|---|---|---|
| repo、issue、PR、review context | GitHub | official または trusted GitHub integration | 足りないのが repo 外の context だけなら GitHub で止まる |
| framework や API docs の古さ | Context7 または current-docs MCP | trusted remote docs server | 一つの docs path が効いたら、docs tool を重ねない |
| browser QA、UI flow、repro steps | Playwright | trusted automation server。まずは personal が多い | team で同じ flow を共有すると確信するまで project scope にしない |
| incidents、traces、production debugging | Sentry などの observability connector | incident work が recurring job の時だけ使う | incident が主仕事でないなら入れない |
このボードの目的は、四つの名前を永遠の正解にすることではありません。tool directories が省きがちな問いを先に答えさせることです。最初に何を足すべきか。今は何を足さないべきか。
最初に選ぶべきなのは server 名ではなく surface です
このテーマで検索する人の多くは、MCP server の shopping list を探しています。実際に最初のミスが起きやすいのは、その一歩前です。Claude Code の integrations を全部同じ種類のものとして扱ってしまうことです。
そうではありません。Anthropic の current ecosystem では、recommendation を変えるのに十分な差を持つ surfaces がすでに並んでいます。Official connector は、Anthropic がその service を直接サポートしている時の最も clean な start です。friction が低く、余計な configuration ownership を背負いにくいからです。Remote MCP server は別物です。first-party integration がない service や data source を使う時には有効ですが、その server operator を trust する必要が出てきます。Project-scoped .mcp.json はさらに別の surface で、そこでは personal experiment ではなく repo が integration を持つことになります。Plugin-bundled MCP はもっと後ろの packaging answer で、setup 自体に distribution や lifecycle management が必要になった時に意味を持ちます。
だから giant top-20 list は弱い出発点になりやすいのです。real problem は discovery ではなく、missing workflow を安全に閉じる最小の surface を選ぶことだからです。
順番としては、こう考えると分かりやすいです。
- その service に official connector または clearly vetted surface はあるか。
- なければ、real な recurring gap を埋める remote MCP server はあるか。
- それはまだ personal workflow か、それとも repo が持つべき shared workflow か。
- Repo が持つなら、
.mcp.jsonで十分か、それとも plugin-style packaging まで必要か。
この四つを先に答えると、server name の選択は一気に楽になります。飛ばしてしまうと、全部 equally plausible に見えてしまいます。
Day one の場所を本当に取るべき starter MCP
最初に入れるべき path は popularity ではなく、何が一番仕事を止めているかで決まります。だから leaderboard より workflow-first guide の方が役に立ちます。
Repo-heavy workflow なら、最初の一つは GitHub が最有力です
毎日 issue、pull request、diff、review comment、repository metadata のために流れが切れているなら、GitHub は多くの開発者にとって最も強い first integration です。ローカル checkout だけでは埋まらない external context を補えるからです。
しかも、この integration は value が出るまでが速いです。大げさな justification は要りません。Claude Code とブラウザを行き来して PR thread や issue history を見に行っているなら、その時点で GitHub path はかなり本命です。
GitHub が flashy な MCP より勝ちやすい理由は novelty ではありません。すでに real な workflow の context switching を減らすからです。良い first MCP は、既存 bottleneck を短くするべきで、新しい playground を増やすべきではありません。
GitHub が唯一の missing gap なら、そこで止めて構いません。最初の integration が役立ったからといって、次を追加する義務はありません。
Current-docs MCP は stale docs が税金になっている時の最初の third-party add です
開発者によっては、最初に必要なのは issue tracker でも browser automation でもありません。最近変わった framework や SDK について、Claude Code が古い記憶で答えてしまうことを止めたいのです。
その時に Context7 のような current-docs MCP が効きます。これはしばしば、最初に入れる価値がある third-party server です。implementation guidance が current reality に寄り、hallucinated APIs が減り、自分で最新版 docs を確認するための手動の行き来も減るからです。
この種の docs integration は、browser automation ほど派手に見えないので過小評価されやすいです。でも stale guidance が週の中で何度も retry を発生させているなら、最も leverage が大きい first add になりえます。
ここにも clear な stop rule があります。一つの clean docs path が freshness problem を解いたら、すぐに別の docs tools を重ねないことです。目的は、Claude に同じ docs を五通りで読ませることではなく、古い案内に時間を奪われるのを止めることです。
UI の missing proof が問題なら Playwright が最初の add になります
ボトルネックが code を書くことではなく、ブラウザでそれが本当に正しく動いているかを確かめることなら、最初の MCP は Playwright になりやすいです。
Playwright 系の integration が早めに場所を取る価値があるのは、曖昧な frontend discussion を observable behavior に変えるからです。Claude Code が app を開き、flow を辿り、page state を見て、bug reproduction を手伝えるなら、それは単に情報量が増える話ではなく、できる仕事の種類が増える話です。
これは “たぶん動くはず” と manual browser checking の往復に時間を取られている team には特に効きます。browser automation が workflow の一部になると、Claude は UI fixes の検証、regression の再現、仮説から evidence までの距離短縮を手伝えるようになります。
ただし packaging は急がない方がいいです。Playwright に value があるからといって、すぐ shared project setup に上げる必要はありません。まだ一人が workflow を証明している段階なら、personal のままが自然です。 .mcp.json に上げるのは、その browser-testing pattern が repo-owned になるほど安定してからです。
Sentry のような observability connector は、incident work が主線の時だけ早く入れる
Observability access は powerful ですが、universal な day-one add ではありません。production debugging や incident response が本当に weekly workflow の中心にある時だけ、早めの位置を取るべきです。
例外、trace、error triage、on-call investigation が仕事の大きな部分を占めるなら、Sentry のような monitoring connector は高い価値を持つ first または second integration になります。local code だけでは見えない operational context を Claude Code に渡せるからです。
ただし、ここは setup が早く ambitious になりすぎる典型でもあります。Observability integration は見栄えが良いので、need が証明される前に入れがちです。incident が occasional で central ではないなら、prestige add にしない方がいいです。
Official connector が raw server より勝つ時と、project scope が personal setup を超える時
Workflow が見えたら、次の判断は誰が integration を持つべきかです。
Official または clearly vetted surface があるなら、まずそこを使います。 Anthropic の current connector surfaces は、raw server config に飛びつく前に十分検討する価値があります。first-party path は常にあるとは限りませんが、ある時は setup ambiguity と trust overhead を減らせます。
Official surface がないが workflow は real なら、remote MCP server を使います。 これは many third-party tools では normal case です。ただし trust はここで一気に重くなります。Anthropic の current Claude Code MCP docs は、すべての third-party servers の correctness や security を確認していないこと、untrusted content を扱う server には prompt-injection risk があることを明示しています。つまり “third-party MCP を使うな” ではなく、“real な recurring workflow 以外の理由で入れるな” ということです。
Project-scoped .mcp.json は repo が integration を持つべき時だけです。 Shared config を seriousness の badge のように扱うと、ここで判断を誤ります。複数人が同じ integration から利益を得ていて、setup も標準化できるほど stable になって初めて、この route は成立します。まだ “自分で試している” 段階なら personal のままで十分です。
Plugin-bundled MCP は packaging と lifecycle が問題になってからです。 これはほとんどの team にとって first step ではありません。distribution、startup behavior、consistent enablement across team が問題になった時に初めて意味を持ちます。
実際の順番は単純です。personal first、shared config second、packaged distribution later。この順を逆にすると、usefulness の前に sophistication にコストを払うことになります。
最悪の初手は connector sprawl です
Claude Code を “強くしたつもりで弱くする” 一番簡単なやり方は、個別にはどれも良さそうに見える integrations を次々に足すことです。
Connector sprawl には少なくとも三つのコストがあります。
一つ目は trust cost です。Anthropic の current MCP docs は、third-party server の trust は自動ではないと明言しています。untrusted content を扱う server は prompt-injection path や wider workflow risk の一部になり得ます。Third-party server は clever demo ではなく、real workflow value で正当化されるべきです。
二つ目は attention cost です。Integrations が増えることは capability だけでなく、覚える名前、debug する setup、approval path、維持する habit も増えることを意味します。たまにしか助けない server なら、maintenance burden の方が value を超えやすいです。
三つ目は usage cost です。Claude Code はもともと context-heavy です。Tool definitions、tool results、広い automation loops は session を noisier で expensive にします。Workflow がそのコストを正当化するほど重要でなければ、その integration は見た目ほど役に立っていません。
だから stop rule が重要です。一つの integration が real gap を閉じたら、一度止まる。次の gap は自然に見えてきます。早い段階で本当に良い setup は、広い stack ではなく、実際に使う compact stack です。
ここで一つ boundary をはっきりさせておきます。もし本当に足りないのが external tool access ではなく repo 内の reusable workflow knowledge なら、読むべきなのは Claude Code skills guide です。Skills は内部の手順知識向きで、MCP は外部ツールや data access 向きです。
そして、そもそも broader Claude Code setup がまだ固まっていないなら、このページを総合入口にしない方がいいです。先に Claude Code install guide から始める方が自然です。このページは narrower なままであるべきです。役目は first integration judgment であって、environment 全体の再説明ではありません。
FAQ
Claude Code で最初に入れるべき MCP は何ですか？
一番大きい external workflow gap を閉じるものです。多くの repo-heavy developer では GitHub、docs freshness が問題なら Context7 のような current-docs MCP、frontend verification なら Playwright が最初の候補になります。Novelty ではなく interruption cost で選びます。
Connectors と raw MCP server config のどちらを使うべきですか？
仕事を終わらせるのに十分で、しかも最も trusted な surface を選びます。Official connector や clearly vetted route があるなら、それが普通は best first move です。Workflow が real で、official path がない時だけ raw や third-party server config に進みます。
.mcp.json が正しいのはどんな時ですか？
その integration が一人ではなく repo に属するべき時です。Workflow 自体が必要かどうかをまだ試している段階なら、personal のままで十分です。Shared config は stable repeated need を表すべきで、early experiment を表すべきではありません。
Third-party MCP servers は安全ですか？
自動では安全ではありません。Anthropic の current Claude Code MCP docs は、すべての third-party MCP servers の correctness や security が確認済みではないこと、untrusted content を露出する server には prompt-injection risk があることを明言しています。Browser extension のように軽く扱うのではなく、real workflow dependency として扱ってください。
最初は何個くらいの MCP を入れるべきですか？
たいていは一つか二つで十分です。最初の integration が main gap を閉じたなら、そこで止まる方がいいです。早期の Claude Code MCP setup は、大きい stack より、小さいけれど pay for itself している stack の方が強いです。
これは Claude Code skills を選ぶ話と同じですか？
違います。Skills は internal workflow knowledge を扱い、MCP は external tools と data access を扱います。似て見えるのは、knowledge が足りないのか access が足りないのかを見分ける境界だけです。
本当に役に立つ Claude Code MCP strategy は、検索語の響きよりずっと小さいです。Ecosystem map ではなく workflow bottleneck から始め、official または clearly trusted surface を優先し、shared project setup は workflow が繰り返し現れるようになってからにします。それ以外の “とりあえずもう一つ足す” は、たいてい noise です。