Simon Willison在9月1日给自己的开源项目Datasette发了一个不起眼的更新：datasette-mcp 0.2。它是这个插件第一个脱离alpha阶段的正式版本，改动写在changelog里就一句话——execute_sql工具返回的“rows”字段，从数组的数组（array of arrays）变成了对象数组（array of objects）。Willison说自己已经大量自用，认为可以放心交给别人用了。
这行改动看起来像是格式洁癖，实际上是在给AI agent的“阅读理解能力”打补丁。它也顺手把datasette-mcp放进了一张越来越拥挤的数据库MCP工具地图里，逼人重新想一个问题：给agent接数据库，到底该看谁的方案，风险又藏在哪。
数组变对象，改的是什么
先说清楚这行改动本身。之前execute_sql返回的每一行数据是一个纯数组，模型要靠“第几个位置对应第几列”去反推数据含义。列多了、顺序稍微一乱，模型很容易把某一列的值安到另一列名下——这在人类读代码时不算事，交给语言模型去猜位置，出错率并不低。
0.2版本把每一行改成键值对形式，列名和值直接绑在一起，模型不需要再做位置换算。这是明确写给“较弱模型”看的修复，不是给GPT-4级别模型锦上添花，而是给一大批能力更普通、正在被塞进各种agent工作流的模型兜底。
Willison把这个原因写得很淡，但值得读者知道：这不是性能优化，是纠错优化。当前一批数据库MCP工具，工程重心已经从“协议能跑通”转向“模型不会看错数据”，这是MCP生态进入精细打磨期的一个具体信号。
别把它当成又一个SQLite连接器
datasette-mcp常被拿来跟同类工具比，但它的定位其实容易被误读。Datasette本身是一个数据发布和探索工具，构建在SQLite上，带schema浏览、canned queries、插件体系，本质是给人和agent都能用的“数据门户”。datasette-mcp只是给这个门户装了个MCP接口，注册了list_databases、get_database_schema、execute_sql几个工具，还能靠Datasette的插件钩子继续扩展。
对比同赛道的其他方案，会更清楚这个定位差在哪：
Google MCP Toolbox覆盖PostgreSQL、MySQL、SQL Server、MongoDB、BigQuery、Snowflake等十余种引擎，走的是企业多数据库路线。Microsoft的postgres-mcp和CrystalDB的Postgres MCP Pro，做的是查询计划分析、索引调优这类PostgreSQL运维深水区，datasette-mcp目前完全没碰这块。倒是mcp-sqlite跟它场景重叠最多，甚至能复用Datasette的元数据文件、把canned queries转成MCP工具——但mcp-sqlite追求的是极简本地agent接入，Datasette要背负的是整套数据发布平台的复杂度。
这意味着datasette-mcp和mcp-sqlite更像是互补而非正面竞争：已经在用Datasette托管数据、给人类做浏览界面的团队，装这个插件是顺理成章的事；纯粹只想让agent查一个本地SQLite文件、不需要发布界面的场景，mcp-sqlite反而更轻。
changelog没写的那部分：只读不是安全边界
有一个原文完全没提、但对任何想把datasette-mcp用到真实业务里的人更重要的问题：execute_sql开放给agent执行SQL查询，靠的是应用层声明的“只读模式”，这在安全上并不等于数据库层面的权限隔离。
行业里已经有过前车之鉴——早期作为MCP参考实现的Anthropic/MCP官方PostgreSQL服务器，如今已被归档弃用，不再是生产环境的推荐选择。应用层的“read-only”标记可以被绕过或写错，真正的防线是给agent单独开一个只有SELECT权限的数据库账户，配上语句超时和网络隔离。
- 风险.只靠应用代码里一句"只读"限制，不构成生产环境可信的安全边界。
这条建议不是datasette-mcp独有的问题，几乎所有把SQL执行权交给agent的MCP服务器都要面对。0.2版本的changelog只字未提，恰恰说明这件事目前更多靠使用者自己上心，而不是靠工具默认帮你兜底。
对已经在用0.1 alpha版本的开发者，这次升级不是无痛的：客户端代码里如果假设rows是数组、按下标取值，升级后要改成按键名取值，否则会直接读错数据。对正在给数据集选型MCP方案的团队，这次发布提示的是一个更朴素的判断——先看数据在哪、发布需求有多重，再决定是Datasette这条重路线，还是mcp-sqlite那种轻接法。
数组变对象省心，权限没管住才真的要命。