---
title: "Amazon EKS MCP Serverとは？ホスト型とOSS版の違い・接続手順と権限設計【2026年10月】"
url: "https://www.issoh.co.jp/tech/details/7340/"
published: 2025-06-20
updated: 2026-10-02
categories: ["AIエージェント・MCP"]
publisher: "株式会社一創"
---

# Amazon EKS MCP Serverとは？ホスト型とOSS版の違い・接続手順と権限設計【2026年10月】

Amazon EKS MCP Serverは、KiroやClaude Code、CursorといったAIアシスタントに、EKSクラスターの実データ（Podのログ、イベント、Insights、VPC構成など）を読ませるためのMCPサーバーです。現在は、AWSがクラウド側で動かす**ホスト型（2025年11月21日からプレビュー）**と、利用者のPCで起動する**OSS版 awslabs.eks-mcp-server**の2つがあります。名前は同じでも、ツール名・既定の権限・扱える入力が違うため、混同したまま設定すると「読み取り専用のつもりで書き込みツールが開いている」状態になりかねません。この記事では2026年10月2日時点の公式ドキュメントと、OSS版0.2.1・mcp-proxy-for-aws 1.7.0を手元で動かした結果をもとに、選び方・接続手順・IAMの組み方・本番前に確かめる制約を整理します。

## まとめ：EKS MCP Serverの選び方と安全に使うための要点

新しく始めるならホスト型を選び、IAMで書き込みを止めるのが基本です。要点は次の5つです。

- **提供形態**：ホスト型はエンドポイント `https://eks-mcp.{region}.api.aws/mcp` に、ローカルのプロキシ mcp-proxy-for-aws 経由でSigV4署名して接続します。2026年10月2日時点でも公式ドキュメントは「preview release」と明記しています。
- **既定の権限が逆**：OSS版は何も付けなければ読み取り専用で、書き込みは `--allow-write` で解禁します。ホスト型のプロキシは何も付けなければ全ツールが有効で、`--read-only` を付けたときだけ書き込み系を隠します。
- **本当の歯止めはIAM**：ホスト型では `eks-mcp:CallPrivilegedTool` を持たないロールなら書き込みツールを呼べません。AWS管理ポリシー AmazonEKSMCPReadOnlyAccess にはこのアクションが入っていないので、まずはこれだけを付けます。
- **Kubernetes APIへの書き込みはパブリックエンドポイントのクラスターだけ**：ホスト型のKubernetes API読み取り操作はプライベートクラスターにも届きますが、Kubernetes API書き込み操作は `endpointPublicAccess=true` のクラスターにしか届きません。
- **Secretを渡さない**：応答中のトークンや証明書は `HIDDEN_FOR_SECURITY_REASONS` に置き換えられますが、AWSは「MCPツールでKubernetes Secretを作らない」ことも求めています。

## Amazon EKS MCP Serverの役割と2つの提供形態

MCP（Model Context Protocol）は、AIアプリケーションが外部のツールやデータへ同じ作法でつながるための規格です（規格そのものは[MCP（Model Context Protocol）の仕組みを解説した記事](/tech/details/5736/)で扱っています）。EKS MCP Serverはその「EKS用の受け口」で、AIがkubectlやAWS CLIの代わりに、決められたツールを通してクラスターの状態を読み、許可されていれば変更を加えます。

### AIにクラスターの実データを渡すツール群の中身

公式ドキュメントはツールの用途を、クラスター管理、Kubernetesリソースの管理、トラブルシューティング、ドキュメント検索の4つに分けています。たとえば「Runningでない Pod を挙げて」と頼むと、AIは `list_k8s_resources` でPod一覧を取り、`get_pod_logs` で直近100行（既定値）のログを読み、`get_k8s_events` でイベントを突き合わせてから原因を答えます。AIの知識だけで推測するのと違い、クラスターの今の状態を根拠にできるのが利点です。`search_eks_troubleshooting_guide` のように、AWSが運用知見から作ったトラブルシューティングの知識ベースを引くツールもあります。

### 2025年5月のOSS版と2025年11月のホスト型の違い

先に出たのはOSS版で、[PyPIの awslabs.eks-mcp-server](https://pypi.org/project/awslabs.eks-mcp-server/) は2025年5月29日に0.1.1が公開されました。2026年9月8日公開の0.2.1が最新で、ここまでに37版が出ています。ホスト型は2025年11月21日にAWSが「フルマネージドのEKS MCP Server（プレビュー）」として発表したもので、同日にAWS管理ポリシー AmazonEKSMCPReadOnlyAccess も追加されました。

| 項目       | ホスト型（プレビュー）              | OSS版 awslabs.eks-mcp-server                     |
| -------- | ------------------------ | ----------------------------------------------- |
| 動く場所     | AWSのクラウド                 | 利用者のPC（uvxで起動）                                  |
| 接続       | mcp-proxy-for-aws＋SigV4  | stdioで直接起動                                      |
| ツール数     | 20（読み取り16・書き込み4）         | 16（IAMモード）／7（kubeconfigモード）                     |
| 既定の権限    | 全ツール有効                   | 読み取り専用                                          |
| 権限の切り替え  | IAMの3アクション＋`--read-only` | `--allow-write`／`--allow-sensitive-data-access` |
| YAMLの渡し方 | 本文を文字列で渡す                | ローカルのファイルパスを渡す                                  |
| 監査       | CloudTrailに記録            | 自前でログを取る                                        |
| 更新       | 自動                       | `@latest`で起動時に取得                                |

同じ名前で全AWSサービスを扱う「AWS MCP Server」もありますが、こちらはAPI呼び出しとドキュメント検索を束ねた汎用サーバーで、EKS専用のツールは持ちません。違いは[AWS MCP ServerのGA版の接続手順と全ツール・権限設計を解説した記事](/tech/details/17726/)で確認できます。

## ホスト型EKS MCP Serverの接続手順

ホスト型ではサーバーをインストールしません。手元で動くのは、ローカルのAWS認証情報で要求にSigV4署名を付けてエンドポイントへ中継する mcp-proxy-for-aws（2026年9月15日公開の1.7.0が最新）だけです。

### 前提となるAWS CLI・Python・uvの準備

公式ガイドの前提は、認証情報を設定済みのAWS CLI、Python 3.10以上、uvの3つです。なお、mcp-proxy-for-aws 1.7.0がPyPIで宣言しているPython要件は3.10以上3.15未満です。uvxが実行環境を用意するので、事前の `pip install` は要りません。`@latest` を付けると起動時に最新版を確認しますが、取得済みのパッケージはキャッシュから再利用されます。以下の `eks-readonly` は、読み取り専用ポリシーを付けたロール用に自分で作るプロファイル名の例です。

```
python3 --version   # 3.10以上
uv --version
aws configure list --profile eks-readonly  # 後続の設定と同じプロファイルを確認
aws sts get-caller-identity --profile eks-readonly --region us-west-2
```

### mcp-proxy-for-awsを指定するMCP設定JSON

KiroのIDEとCLIはどちらも、ユーザー単位なら `~/.kiro/settings/mcp.json`、ワークスペース単位なら `.kiro/settings/mcp.json` に書きます。CursorやClineも同じ `mcpServers` 形式です。最初は `--read-only` を付けた形から始めます。

```
{
  "mcpServers": {
    "eks-mcp": {
      "disabled": false,
      "type": "stdio",
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://eks-mcp.us-west-2.api.aws/mcp",
        "--service", "eks-mcp",
        "--profile", "eks-readonly",
        "--region", "us-west-2",
        "--read-only"
      ]
    }
  }
}
```

リージョンの指定は2か所あり、意味が違います。AWSのブログによると、URLの `eks-mcp.{region}` はMCPサーバーが動いているリージョン、`--region` は操作するクラスターがあるリージョンです。Windowsでは `"--from", "mcp-proxy-for-aws@latest", "mcp-proxy-for-aws.exe"` の順に書き換えます。

Claude Codeなら、設定ファイルを編集せずにコマンド1行で登録できます。`--` より後ろがプロキシの起動コマンドです。

```
claude mcp add eks-mcp -- uvx mcp-proxy-for-aws@latest \
  https://eks-mcp.us-west-2.api.aws/mcp \
  --service eks-mcp --profile eks-readonly --region us-west-2 --read-only
```

### Amazon Q Developer CLIの手順がKiro CLIへ移った点

EKSのユーザーガイドは今も「Option A: Amazon Q Developer CLI」を先頭に置き、設定ファイルを `~/.aws/q/mcp.json` としています。ところがQ Developer CLIは2025年11月24日の自動更新でKiro CLIに置き換わっており、Amazon Q Developerも2026年5月15日に、IDEプラグインからの無料枠アカウント作成とサブスクリプションの新規作成を停止しました。これから設定するなら、AWSのブログと同じくKiro CLIの `~/.kiro/settings/mcp.json` を使ってください。Kiroそのものは[Kiroの機能と料金を解説した記事](/tech/details/7963/)にまとめています。

## OSS版 awslabs.eks-mcp-server の起動とフラグ

OSS版はホスト型の前身で、今もPyPIで更新が続いています。プレビュー段階のホスト型を社内規程で使えない場合や、OIDCでクラスターに入る環境では、こちらが選択肢になります。

### 既定の読み取り専用でも16ツールすべてが見える実測結果

0.2.1をuvxで起動し、MCPの `tools/list` を投げてツール一覧を取ったところ、フラグなし・`--allow-write` あり・両フラグありのいずれでも、返ってきたツールは同じ16個でした。OSS版の読み取り専用は「書き込みツールを隠す」のではなく、「呼ばれたときに断る」作りです。実際、フラグなしで呼ぶと次の応答が返りました。

```
apply_yaml          → Operation apply_yaml is not allowed without write access
manage_eks_stacks   → Operation generate is not allowed without write access
manage_k8s_resource → Operation delete is not allowed without write access
get_pod_logs        → Access to pod logs requires --allow-sensitive-data-access flag
manage_k8s_resource（kind=Secret, read）
                    → Access to Kubernetes Secrets requires --allow-sensitive-data-access flag
```

AIからは書き込みツールが見えるので、「apply\_yamlで直します」と提案してから失敗する、というやり取りが起こります。挙動としては安全側ですが、書き込みツールの呼び出しを避けたいなら、クライアント側でも対象ツールを無効にします。ただし、ツールを無効にしてもAIが文章で変更案を示すこと自体は止められません。

### 2つのフラグで解禁される操作

[OSS版のREADME](https://github.com/awslabs/mcp/tree/main/src/eks-mcp-server)によると、2つのフラグはどちらも既定でfalseです。解禁されるものは次のとおりです。

| フラグ                             | 解禁される操作                                               |
| ------------------------------- | ----------------------------------------------------- |
| `--allow-write`                 | apply\_yaml、generate\_app\_manifest                   |
| `--allow-write`                 | manage\_eks\_stacks（generate・deploy・delete）           |
| `--allow-write`                 | manage\_k8s\_resource（create・replace・patch・delete）    |
| `--allow-write`                 | add\_inline\_policy                                   |
| `--allow-sensitive-data-access` | get\_pod\_logs、get\_k8s\_events、get\_cloudwatch\_logs |
| `--allow-sensitive-data-access` | get\_eks\_vpc\_config、get\_eks\_insights              |
| `--allow-sensitive-data-access` | manage\_k8s\_resourceでのSecret読み取り                     |

注意したいのは、READMEのQuickstartにあるKiro・Cursor・VS Codeのワンクリック導入ボタンが、両方のフラグを付けた設定を書き込むことです。ボタンで入れた場合は、設定ファイルを開いてフラグを消してから使い始めてください。また、ローカルで動くOSS版ではマニフェストをファイルとして扱います。`apply_yaml` の必須引数は `yaml_path`（ローカルのファイルパス）、`generate_app_manifest` の必須引数は `output_dir` です。`--allow-write` 付きで `generate_app_manifest` を呼ぶと、Deploymentと `aws-load-balancer-scheme: internal` 注釈付きのLoadBalancer型Serviceが `web-manifest.yaml` として書き出されました。

### kubeconfigモードで7ツールに減る条件

既定のIAMモードでは、Kubernetes APIに入れるのは「そのクラスターを作ったIAMプリンシパル」か「EKSアクセスエントリーが設定されたプリンシパル」だけです。OIDCなどkubeconfigで認証している環境では、`--auth-mode kubeconfig`（または環境変数 `EKS_AUTH_MODE=kubeconfig`）で起動します。このモードではAWSのAPIを使うツールが登録されず、手元で数えると16個から7個に減りました。残るのはlist\_k8s\_resources、get\_pod\_logs、get\_k8s\_events、list\_api\_versions、manage\_k8s\_resource、apply\_yaml、generate\_app\_manifestです。CloudWatch・IAM・Insights・トラブルシューティング知識ベースは使えなくなります。

## ホスト型とOSS版で異なるツール名と引数

ホスト型のツールは20個です。読み取り16個のうち、search\_eks\_documentation、describe\_eks\_resource、list\_eks\_resources、read\_k8s\_resource の4つはOSS版にありません。逆に、OSS版の `search_eks_troubleshoot_guide` はホスト型では `search_eks_troubleshooting_guide` と名前が変わっています。プロンプトやエージェントの手順書にツール名を直接書いているなら、移行時に書き換えが必要です。

| 用途                      | ホスト型                                         | OSS版                                |
| ----------------------- | -------------------------------------------- | ----------------------------------- |
| Kubernetesリソース1件の取得     | read\_k8s\_resource                          | manage\_k8s\_resource（read）         |
| EKSリソースの一覧・詳細           | list\_eks\_resources／describe\_eks\_resource | なし                                  |
| EKSドキュメント検索             | search\_eks\_documentation                   | なし                                  |
| トラブルシューティングガイド検索        | search\_eks\_troubleshooting\_guide          | search\_eks\_troubleshoot\_guide    |
| YAMLの適用                 | apply\_yaml（yaml\_content）                   | apply\_yaml（yaml\_path）             |
| CloudFormationでのクラスター作成 | manage\_eks\_stacks（template\_content）       | manage\_eks\_stacks（template\_file） |
| マニフェスト生成                | generate\_app\_manifest（読み取り扱い）              | generate\_app\_manifest（書き込み扱い）     |

ホスト型の書き込みツールは manage\_k8s\_resource、apply\_yaml、manage\_eks\_stacks、add\_inline\_policy の4つです。なお、旧版のこの記事で紹介していた `describe_k8s_resource` と `delete_k8s_resource` は、どちらの版にも存在しません。リソースの削除は `manage_k8s_resource` の `operation: delete` で行います。

## EKS MCP Serverの権限設計：IAMとKubernetes側アクセス

ホスト型の権限は、MCPサーバー自体を使う許可と、その先でEKS・EC2・CloudWatchなどを読み書きする許可の2層で考えます。

### eks-mcpの3アクションと読み取り専用の管理ポリシー

MCPサーバーへの許可は3つのアクションで分かれています。

| アクション                      | 必要になる場面      |
| -------------------------- | ------------ |
| eks-mcp:InvokeMcp          | 初期化とツール一覧の取得 |
| eks-mcp:CallReadOnlyTool   | 読み取りツールの呼び出し |
| eks-mcp:CallPrivilegedTool | 書き込みツールの呼び出し |

[AmazonEKSMCPReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html)（2026年2月12日編集のv3が既定）は、このうち `InvokeMcp` と `CallReadOnlyTool` に加えて、eksのDescribe・List系と `eks:AccessKubernetesApi`、IAMロールとポリシーの参照、VPC・サブネット・ルートテーブルの参照、`logs:StartQuery`／`logs:GetQueryResults`、`cloudwatch:GetMetricData`、`sts:GetCallerIdentity` を含みます。`CallPrivilegedTool` は入っていません。プロキシの `--read-only` は手元の設定ファイル1行で外せますが、IAMの拒否は手元から外せません。AIに設定ファイルを書き換えられる環境では、IAMのほうを本当の境界と考えてください。ただしIAMは付与された許可の合算で判定されるので、読み取り専用ポリシーを付けても、同じロールに付いた別ポリシーの書き込み許可は消えません。利用ロールには他のポリシーを付けず、権限の追加や高権限ロールの引き受け（`sts:AssumeRole`）も許さない設計にします。IAMのユーザーやロールを人ごとに配る代わりに、[IAM Identity Centerの権限セット](/tech/details/15900/)へこの管理ポリシーを付ける方法もあります。

### 書き込み用ポリシーに含まれる削除系とiam:PassRole

書き込み用のAWS管理ポリシーはありません。[公式の導入手順](https://docs.aws.amazon.com/eks/latest/userguide/eks-mcp-getting-started.html)は `EKSMcpWriteManagementPolicy` というカスタマー管理ポリシーを自分で作る方式で、その中には `eks:DeleteCluster`、`ec2:DeleteVpc` などの削除系、`iam:CreateRole`／`iam:PutRolePolicy`、`eks.amazonaws.com` と `ec2.amazonaws.com` に限った `iam:PassRole`、`eks-mcp:*` が入っています。AWS自身が高リスクの権限を含むと明記しており、理由は manage\_eks\_stacks がVPCごとクラスターを作って消すためです。クラスターを作らせないなら、この雛形から `cloudformation:*`・`ec2:Create*`／`ec2:Delete*`・`iam:CreateRole` 系を外し、`eks-mcp:CallPrivilegedTool` とKubernetes APIの権限だけを足す構成にします。

### Kubernetes側の認可とアクセスエントリー

IAMで `eks:AccessKubernetesApi` を許可しても、Kubernetes APIの中で何ができるかは別に決まります。OSS版のREADMEは、IAMモードでKubernetes APIの操作が通るのは「プリンシパルがクラスターの作成者」か「アクセスエントリーが設定されている」場合だけだと明記しています。認可エラーが出たら、まず `aws eks list-access-entries --cluster-name <クラスター名>` で自分のロールが登録されているかを確認します。読み取りだけを許すなら、アクセスポリシーに AmazonEKSViewPolicy を名前空間単位で関連付けるのが最小構成です。

## 本番クラスターにつなぐ前に確かめる制約

### Kubernetes API書き込み操作のパブリックエンドポイント制約

ホスト型の[ツールリファレンス](https://docs.aws.amazon.com/eks/latest/userguide/eks-mcp-tools.html)は、読み取り系のKubernetes API操作はプライベートとパブリックの両方のクラスターに届く一方、書き込み系は「as of today」パブリッククラスター（`endpointPublicAccess=true`）にしか届かない、と書いています。本番をプライベートエンドポイントのみにしている構成では、ホスト型からKubernetes APIを通じて本番リソースを書き換えることはできません。読み取り専用で使うと割り切れるなら、これはむしろ好都合です。

### CloudTrailに残る呼び出しの範囲

[EKSのユーザーガイド](https://docs.aws.amazon.com/eks/latest/userguide/eks-mcp-introduction.html)は、CloudTrailに記録されるのは「初期化とフルアクセス（書き込み）ツールの呼び出し」だとしています。[発表時のブログ](https://aws.amazon.com/blogs/containers/introducing-the-fully-managed-amazon-eks-mcp-server-preview/)は「すべてのツール呼び出し」と書いていたので、記述が食い違います。読み取りツールの呼び出しまで監査証跡に必要なら、導入前にCloudTrailのイベント履歴を実際に見て、どの呼び出しが残るかを確かめてください。OSS版にはこの仕組みがなく、記録はクライアント側のログに頼ることになります。

### 応答の秘匿化とSecretを扱わない運用

ホスト型は、ログやリソース記述などすべての応答で、トークンや証明書によくある形の文字列を `HIDDEN_FOR_SECURITY_REASONS` に置き換えます。ただしパターンに合うものだけです。公式の注意事項は、apply\_yamlに渡すYAMLやプロンプトに秘密情報を入れないこと、MCPツールでKubernetes Secretを作らないこと（秘密の値をモデルに渡すことになるため）を挙げ、代わりにSecrets ManagerやParameter Store、IRSAを使うよう求めています。また、YAMLの中身はKubernetes APIの検証に任せており、サーバー独自の検証はしません。

### manage\_eks\_stacksが消せるスタックの範囲

manage\_eks\_stacks のdeployとdeleteは、このツール自身が作り `CreatedBy=EksMcpServer` タグが付いたCloudFormationスタックにしか効きません。既存のIaCで作ったスタックを、manage\_eks\_stacksが消すことはありません。ただしこの制約は同ツールの対象スタックに限ったもので、書き込み用ポリシーに `eks:DeleteCluster` が入っていれば、別のAWS APIやツールを経由した削除までは防げません。既存クラスターの削除防止はIAM側で設計します。一方で、AIに作らせたクラスターは自社のTerraformやCDKの管理外にできあがります。クラスター作成は15〜20分かかる操作でもあるので、検証用の使い捨て環境に限るのが無難です。IaCで組むなら[Terraform MCP Serverの導入手順とtoolsetの権限設計を解説した記事](/tech/details/16551/)の構成と組み合わせるほうが、変更の履歴が残ります。

## EKS MCP Serverを採用すべき場面と見送る場面

向いているのは、**障害調査の一次切り分けを読み取り専用で回す用途**です。CrashLoopBackOffのPodについてログ・イベント・Insights・CloudWatchメトリクスを横断して読む作業をAIにまとめて任せられ、しかも読み取り専用の権限で済みます。開発・ステージングのクラスターで、AmazonEKSMCPReadOnlyAccess だけを付けたロールから始めるのが現実的な入り方です。[EKS Auto Mode](/tech/details/4420/)でノード運用をAWSに任せているクラスターなら、AIに見せる範囲もワークロード側に絞れます。

一方、次の条件に当てはまるなら見送るか、読み取りに限定してください。

- **Argo CDやFluxでGitOps運用している**：apply\_yamlやmanage\_k8s\_resourceで直接変更すると、Gitとの差分（ドリフト）が生まれ、次の同期で巻き戻るか、逆に意図しない状態が固定されます。変更はプルリクエストで出す運用を崩さないことです。
- **プレビューの機能を本番運用に入れられない社内規程がある**：ホスト型は「変更される可能性がある」と明記されたプレビューです。この場合はOSS版を読み取り専用で使います。
- **本番クラスターがプライベートエンドポイントのみ**：ホスト型からKubernetes APIへの書き込みは届きません。PodやDeploymentなどを直接変更する用途には使えません。

EKSそのものの構成や料金から確認したい場合は、[Amazon EKSの仕組み・料金と採用判断を解説した記事](/tech/details/15437/)が前提知識になります。

## よくある質問

### Amazon EKS MCP Serverの料金はかかりますか？

2026年10月2日時点で、EKSの料金ページ、ユーザーガイド、発表時のブログのいずれにも、EKS MCP Server自体の料金は書かれていません。ツールが呼び出す先のサービスには通常の料金がかかりますが、EKS MCP Server自体に追加料金があるかどうかは、記載が無いことだけでは判断できません。呼び出し先の例として、`get_cloudwatch_logs` はCloudWatch Logs Insightsのクエリを実行するので、スキャンしたデータ量に応じた通常のLogs Insights料金がかかります。manage\_eks\_stacksで作ったクラスターやNATゲートウェイも通常どおり課金されます。プレビュー終了時に条件が変わる可能性もあるため、GA発表の時点で料金ページを確認してください。

### 東京リージョン（ap-northeast-1）から使えますか？

使えます。発表時のAWSブログは、プレビューの提供範囲を「GovCloudと中国を除くすべての商用リージョン」としています。設定ではURLを `https://eks-mcp.ap-northeast-1.api.aws/mcp`、`--region` を `ap-northeast-1` にします。2026年10月2日に署名なしでこのURLへ要求を送ると、HTTP 403（`MissingAuthenticationTokenException`）が返りました。署名が無いので拒否されただけで、エンドポイント自体は東京にあります。存在しないリージョン名に変えると名前解決の段階で失敗します。

### AWS MCP ServerとEKS MCP Serverはどう使い分けますか？

EKSクラスターの中身（Pod、イベント、ログ、Insights）を扱うならEKS MCP Server、EKS以外も含めてAWSのAPIを広く呼びたいならAWS MCP Serverです。両方を同時に登録することもできます。その場合も、AWS MCP Serverにはクラスターの中を読む専用ツールが無いので、Podのログやイベントを読む役割はEKS MCP Serverに任せることになります。

### OSS版からホスト型へ移行するときに変わる点は何ですか？

設定ファイルの `awslabs.eks-mcp-server@latest` を `mcp-proxy-for-aws@latest` とエンドポイントURLに差し替えます。そのうえで、OSS版のフラグに頼っていた権限をIAMの `eks-mcp:*` 系アクションへ移し、ツール名を直接書いた手順書を新しい名前に直します。

### kubectlの代わりになりますか？

なりません。ツールは決められた操作の組み合わせで、port-forwardやexec、rollout undoに当たる専用のツールはありません。状態を読んで原因の当たりを付けるところまでをEKS MCP Serverに任せ、変更はkubectlかGitOpsで人が行う、という分担が安全です。Kubernetesのバージョンとサポート期限は[Kubernetesの最新バージョンと確認方法をまとめた記事](/tech/details/17151/)で確認できます。

## 関連記事

- [AWS MCP Serverとは？GA版の接続手順と全ツール・権限設計【2026年版】](/tech/details/17726/)
- [Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説](/tech/details/15437/)
- [EKS Auto Modeとは？自動化される範囲・料金・NodePoolの制約【2026年版】](/tech/details/4420/)
- [Terraform MCP Serverとは？導入手順とtoolsetの権限設計を実装目線で解説](/tech/details/16551/)
- [MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説](/tech/details/5736/)

---

出典: [Amazon EKS MCP Serverとは？ホスト型とOSS版の違い・接続手順と権限設計【2026年10月】](<https://www.issoh.co.jp/tech/details/7340/>)（株式会社一創）