mysql_mcp_server 評価: LLM に MySQL を読ませる前の権限設計

誰のためのサーバか: SQL を書ける人ではなく、スキーマを知らない人向け

このサーバが埋めるのは、AI クライアントと MySQL の間に何もない状態で生じる手間だ。LLM にクエリを書かせたいだけなら mysql クライアントに接続文字列を渡せば済むが、その場合モデルはテーブル名もカラム型も知らないまま推測で SQL を組み立てる。mysql_mcp_server は MCP のリソースとしてテーブル一覧を公開し、get_schema_info でカラム名、型、NULL 可否、既定値、コメントを返し、get_table_sample で最大 20 行のサンプルを渡す。つまり対象は、SQL の素養はあるが対象データベースの構造を把握していない開発者であり、その調査を AI に代行させたい人だ。README は「データベース探索と分析をより安全で構造化されたものにする」と表現している。分析用の参照経路を用意することが主目的で、本番の書き込み経路を AI に開放する道具ではない。

3 つのツールと単文制約が決めるデータフロー

クライアントから見える操作は execute_sql、get_schema_info、get_table_sample の 3 つに整理されている。execute_sql は SELECT だけでなく SHOW、DESCRIBE、そして INSERT、UPDATE、DELETE も受け付ける。README は DML に destructive hint が付くと書いており、対応クライアントでは承認を促す表示が出る。ここで効くのが単文制約だ。USE db; SELECT ... のような複数文はサポートされず、データベースをまたぐ場合は mydb.mytable の修飾名で指定する。get_schema_info と get_table_sample も同じ記法を受け付け、識別子に使える文字は英数字、アンダースコア、$ に限られ、ドットはデータベース名とテーブル名の区切りとしてのみ許される。この制約は地味だが、モデルが生成した文字列をそのまま SQL に連結する実装において、識別子の検証点を 1 箇所に集約できるという意味を持つ。MYSQL_DATABASE を省略するとマルチデータベースモードになり、list_resources はシステムデータベースを除いた全ユーザーデータベースを返す。

起動方法: uvx か pip、そして環境変数のどこに秘密を置くか

配布は PyPI の mysql-mcp-server で、pip install mysql-mcp-server のほか uvx mysql_mcp_server としても起動できる。Claude Code CLI への登録は README に claude mcp add --transport stdio designcomputer-mysql_mcp_server uvx mysql_mcp_server とある。Autohand Code CLI の例では autohand mcp add mysql env MYSQL_HOST=localhost MYSQL_PORT=3306 MYSQL_USER=... MYSQL_PASSWORD=... MYSQL_DATABASE=... uvx mysql_mcp_server のように、環境変数をコマンドラインに並べる。設定項目は接続系の MYSQL_HOST、MYSQL_PORT、MYSQL_USER、MYSQL_PASSWORD、MYSQL_DATABASE に加え、MYSQL_SSL_MODE が DISABLED、REQUIRED、VERIFY_CA、VERIFY_IDENTITY の 4 値、MYSQL_CONNECT_TIMEOUT、接続時の SQL モードを決める MYSQL_SQL_MODE（既定 TRADITIONAL）、文字コード関連の MYSQL_CHARSET と MYSQL_COLLATION、古い MySQL 向けの MYSQL_AUTH_PLUGIN、純 Python コネクタを強制する MYSQL_USE_PURE、警告を例外にする MYSQL_RAISE_ON_WARNINGS がある。ローカルで自分で起動する場合は python-dotenv により作業ディレクトリ（および親ディレクトリ）の .env が自動で読まれるので、cp .env.example .env して編集すればよい。

Claude Code と Claude Desktop では .env が読まれない

README が警告として挙げている落とし穴がこれだ。Claude Code と Claude Desktop はサーバを自身の作業ディレクトリから起動するため、プロジェクト直下の .env は探索対象に入らず、Missing required database configuration で失敗する。対処は MCP 設定の env ブロックに MYSQL_* を直接書くことだと明記されている。つまり .env による快適な設定は、自分でサーバを起動する使い方にしか適用されない。ここは設計上の割り切りとして受け止めるべきで、認証情報をリポジトリ管理下のファイルに置かずクライアント設定に集約する運用を強制する効果もある。ただしクライアント設定ファイル自体が平文の秘密置き場になる点は変わらない。SSH トンネルを使う場合も同じ env ブロックに MYSQL_SSH_ENABLE、MYSQL_SSH_HOST、MYSQL_SSH_PORT、MYSQL_SSH_USER、MYSQL_SSH_KEY_PATH、MYSQL_SSH_REMOTE_HOST、MYSQL_SSH_REMOTE_PORT、MYSQL_LOCAL_PORT を並べることになる。

リモート運用の前提: SSE と Host ヘッダの許可リスト

MCP_TRANSPORT=sse にすると Streamable HTTP で待ち受ける。README はリモートや自ホストの配備には SSE モードを推奨している。関連する設定は MCP_SSE_HOST（Docker やホスティングでは 0.0.0.0 が必要と明記）、PORT（MCP_SSE_PORT のフォールバック）、そして MCP_SSE_ALLOWED_HOSTS だ。最後の項目は Host ヘッダの許可リストで、既定値は localhost:{port} と 127.0.0.1:{port} のみ。0.0.0.0 で待ち受ける構成にした場合、この既定のままだと外部ホスト名からのアクセスは弾かれる。コンマ区切りで許可するホストを明示する必要がある。ここはセキュリティ機能として素直に働く一方、配備時に最初に踏む設定ミスでもある。トランスポートを切り替えるだけで待ち受けアドレスと Host 検証の両方を見直す必要が出る点は、stdio 前提で組み立てた設定をそのまま流用できないことを意味する。

向かない場面: マイグレーション、複数文、監査が要る作業

execute_sql は単文しか受け付けない。これは安全性の担保として合理的だが、スキーマ変更の一連の手順や、複数の INSERT をまとめて流す用途にはそのままでは使えない。DDL の可否について README は明示していないため、CREATE や ALTER が通るかは接続ユーザーの権限次第であり、この記事の材料からは断定できない。もう 1 つの限界は権限の粒度だ。サーバ側にテーブル単位の読み取り許可やカラムマスキングの仕組みは見当たらず、アクセス制御は MySQL の GRANT に完全に委ねられている。したがって、個人情報を含むテーブルを AI に触らせたくない場合、サーバの設定では防げない。読み取り専用ユーザーを作り、対象外のテーブルには権限を与えない運用が前提になる。監査ログについても README は「包括的なログ」と述べるのみで、どの項目をどこに出すかの記載はない。コンプライアンス目的でクエリ履歴を保全したい要件には、このままでは答えられない。

代替との違い: 汎用 DB クライアント型 MCP との比較

同じ MCP の世界には、複数のデータベースエンジンを 1 つのサーバで扱う汎用型の実装も存在する。対比すると設計の重心が見える。汎用型は接続先を切り替えながら SQLite、PostgreSQL、MySQL を横断できる代わりに、エンジン固有の機能は薄くなる。mysql_mcp_server は MySQL に限定する代わりに、MYSQL_SSL_MODE の 4 段階、MYSQL_AUTH_PLUGIN による古い認証方式への対応、MYSQL_SQL_MODE や MYSQL_RAISE_ON_WARNINGS といった接続セッションの挙動、SSH ジャンプホスト経由の接続まで設定項目を用意している。既存の MySQL 運用に合わせて接続の作法を寄せられる点が違いだ。逆に、複数エンジンを 1 つの設定で扱いたい、あるいは読み取り専用の保証をサーバ側で強制したい場合は、汎用型や読み取り専用に振り切った実装のほうが素直に収まる。

保守とライセンス: MIT と 0.4.x の更新間隔

ライセンスは MIT で、派生物の公開義務は課されない。商用製品に組み込む場合も条件は緩いが、無保証である点は MIT の定型どおりで、接続障害や誤った DML の責任は利用側にある。ここは法的助言ではないので、社内規程への適合は別途確認してほしい。保守の観点では、提供された情報によれば v0.4.2 が 2026-06-20、v0.4.3 と v0.4.4 が 2026-07-30 に立て続けに切られ、最終 push は 2026-08-02 となっている。パッチリリースが同日に 2 版出ているのは、直前の版に修正が必要な問題があった可能性を示す。導入時は v0.4.4 を指定し、依存する mysql-connector 系のバージョンも固定しておくのが無難だ。設定キーは環境変数として外に出ているため、サーバ本体を上げても MCP 設定側の書き換えは通常不要と考えられる。ただし MYSQL_SSH_* や MCP_SSE_* のような後発の項目は、クライアント設定に追記しない限り既定値のまま動く点に注意したい。

編集部の結論

採用に向くのは、本番とは別の読み取り専用ユーザーを MySQL 側で用意でき、Claude Code や Claude Desktop の MCP 設定に接続情報を直接書く運用を許容できるチームだ。逆に、スキーマ変更や複数文のバッチ投入を AI に任せたい場合、あるいは認証情報を設定ファイルに置けない統制下の環境では、このサーバは入口として適さない。導入前に確認すべきは 3 点で、対象ユーザーの GRANT が SELECT と SHOW VIEW 程度に収まっているか、execute_sql の破壊的ヒントがクライアント側の承認ダイアログを実際に出すか、MCP_TRANSPORT=sse を使うなら MCP_SSE_ALLOWED_HOSTS を既定の localhost から書き換える必要があるかどうか。

公式情報源

1. designcomputer/mysql_mcp_server on GitHub
2. License: MIT
3. Project website
4. README
5. Releases