SQLite MCP：先在測試庫上唯讀探查，再決定是否寫入

適合誰

適合要在本機 SQLite 檔案上跑 SQL、看業務資料，並留下 insight memo 的人。證據寫明：這台 MCP 透過 SQLite 提供資料庫互動和商業智慧，能執行 SQL、分析業務資料，並自動產生商業洞察 memo。

你必須能提供 --db-path 指向的 SQLite 檔案，並接受行程會讀、甚至改這個檔案。官方範例是 ~/test.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 換成可丟棄的測試庫。

前置條件：已安裝 uv；測試庫你有權建立或開啟。這會存取本機檔案，不是無本機讀取的沙箱。

設定位置：用戶端 MCP 的 command / args。

低風險第一次呼叫：先做不會改表的探查——用身分說明裡的「執行 SQL 查詢 / 分析業務資料」查看測試庫裡已有內容，或只讀資源 memo://insights。證據寫明共有六件核心工具，但該條 locator 沒有列出唯讀工具名與參數。不要先呼叫已完整展開的 write_query：它執行 INSERT、UPDATE 或 DELETE，回傳 { affected_rows: number }。也不要先跑會改 memo 的 append-insight。

成功訊號：伺服器拉起後，你能對測試庫跑出查詢結果，或讀到 memo://insights 的目前內容。若行程起不來，先核 uv 與目錄，不要改走 Docker。

使用案例

案例 1：在測試庫上做一次業務資料查看。依據身分證據執行 SQL 查詢或分析。六件工具的唯讀簽章未在 locator 展開，因此只做到「能對 --db-path 指向的庫查詢/分析」這一層，不要編造工具名或過濾參數。

案例 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。六件工具除 write_query 與 append-insight 外，名稱與參數大多未在 locator 展開。本機檔案存取和寫庫都不是零風險。證據沒有寫備份、交易回溯或封存後的替代實作。