SQLite MCP：先にテスト DB を読み取り専用で探り、書いてよいか決める

誰向けか

ローカルの SQLite ファイルで SQL を走らせ、業務データを見、insight memo を残したい人向け。証拠は次を述べる：この MCP は SQLite でデータベース対話とビジネスインテリジェンスを提供し、SQL 実行、業務データ分析、商業洞察 memo の自動生成ができる。

--db-path が指す SQLite ファイルを用意でき、プロセスがそのファイルを読み、場合によって変えることを受け入れる必要がある。公式例は ~/test.db。本番 DB を最初の試行に使わない。

ページは servers-archived にある。証拠は保守状態もクライアント一覧も別に書いておらず、対象は「そのディレクトリで uv により mcp-server-sqlite を実行できる人」までである。

3 分で最初の試行を完了する

uv の主経路を使い、Docker を主インストールにしない。クライアントで次を設定する：

"command": "uv",
"args": [
  "--directory",
  "parent_of_servers_repo/servers/src/sqlite",
  "run",
  "mcp-server-sqlite",
  "--db-path",
  "~/test.db"
]

--directory をこのマシンの実パスに、--db-path を捨てられるテスト DB に替える。

前提条件：uv がインストール済み。テスト DB を作成または開ける権限がある。これはローカルファイルに触れる。ローカル読み取りのないサンドボックスではない。

設定場所：クライアント MCP の command / args。

低リスクな最初の呼び出し：先に表を変えない探査をする。身分説明の「SQL クエリ実行 / 業務データ分析」でテスト DB の既存内容を見るか、リソース memo://insights だけを読む。証拠はコアツールが 6 件だと述べるが、その locator は読み取り専用ツール名とパラメータを列挙しない。完全に展開済みの write_query を先に呼ばない。INSERT、UPDATE、DELETE を実行し { affected_rows: number } を返す。memo を変える append-insight も先に走らせない。

成功シグナル：サーバー起動後、テスト DB でクエリ結果が出る、または memo://insights の現在内容が読める。プロセスが起きなければ先に uv とディレクトリを確認し、Docker に切り替えない。

使用例

事例 1：テスト DB で一度業務データを見る。身分証拠に従い SQL クエリまたは分析を実行する。6 件の読み取り専用シグネチャは locator で展開されていない。したがって「--db-path が指す DB をクエリ/分析できる」層までとし、ツール名やフィルタパラメータを捏造しない。

事例 2：insight memo を読み、追記するかを決める。リソース memo://insights は分析中に見つかった insights を継続的に集め、append-insight 実行時に自動更新する。先にそのリソースを読む。追記は memo を変える。証拠に undo はなく、パラメータも書いていない。memo の書き換えを受け入れ、確認点を経てから呼ぶ。write_query が変えるのは表データで、memo とは別の副作用である。この事例では使わない。

利用上の境界

主経路は uv run mcp-server-sqlite --db-path <file>。Docker 例は docker run --rm -i -v mcp-test:/mcp mcp/sqlite --db-path /mcp/test.db であり、主経路にしない。write_query は行を変え、公式の取り消しがない。append-insight は memo://insights を更新する。6 件のうち write_query と append-insight 以外は、名前とパラメータの多くが locator で展開されていない。ローカルファイルアクセスと DB 書き込みはゼロリスクではない。証拠はバックアップ、トランザクションロールバック、アーカイブ後の代替を書いていない。