Lance support: contrib/lance_fdw and the MCP server's Lance tools #2139

Activity

1. MisterRaindrop

   self-assigned this

   on Oct 16, 2026
2. 23A91A6183 commented on Oct 19, 2026

   

   23A91A6183

   on Oct 19, 2026

   More actions

   Thanks for laying out the stack so clearly. The mcp-server write-back item (#2145) caught my eye: it's off by default, limited to tables in MCP_WRITE_TABLES, and execute_query deliberately has no readOnlyHint, since a query can call a function that writes. I'm researching how database teams scope agent writes, and I'd value short written answers here if you have a moment:

   • In practice, who do you expect to choose MCP_WRITE_TABLES: the DBA who runs the cluster, or the person setting up the agent?
   • Have users asked for execute_query itself to be held read-only, or is limiting writes to write_results the main control they want?
   • When an agent writes extraction results back, would anyone want to record which agent run and which person started it, beyond the model and extracted_at columns?

   Happy to share an early look at what we're building if that's useful. Rajesh, Shagun Labs
3. MisterRaindrop commented on Oct 20, 2026

   

   MisterRaindrop

   on Oct 20, 2026

   ContributorAuthor

   More actions

   Thanks, Rajesh. These are useful questions.

   1. MCP_WRITE_TABLES is server-side configuration. I expect the team operating the MCP server and its database role—typically a DBA or platform team—to choose the allowed tables. The database role’s grants remain the final permission boundary.
   2. The whitelist applies to write_results; it does not govern execute_query. Queries default to a READ ONLY transaction, but a caller can set readonly=false, and read-only transactions do not prevent every side effect. I don’t have a concrete user request to cite for making execute_query unconditionally read-only. That boundary deserves an explicit decision rather than treating the write-back whitelist as a complete write policy.
   3. Recording the agent run and the person who started it could be useful in a shared deployment. Today model is supplied by the caller and extracted_at records the write time; neither verifies an identity. Reliable attribution would need an authenticated identity from the deployment, rather than another value supplied by the agent.

   If you have a concrete database-team use case behind these questions, please share it here. That would help us evaluate the right scope.
4. 23A91A6183 commented on Oct 20, 2026

   

   23A91A6183

   on Oct 20, 2026

   More actions

   Thanks, this is really helpful, especially the point that the whitelist isn't a complete write policy.

   The concrete case I'm exploring with database teams: a shared Cloudberry cluster where several people run agents through one MCP server. The DBA wants agents to read freely, write extraction results only to approved tables, and never flip readonly=false unless a named person has allowed that for a specific run. Afterwards they'd want to answer "which agent run changed this, and who started it" from something the agent couldn't have made up.

   Two quick follow-ups if you have a moment:

   • Would a server-side switch that stops callers from setting readonly=false (unless the operator enables it) be in scope for the mcp-server, or would you rather leave that to database role grants?
   • For attribution, is there an identity the deployment already passes to the MCP server today (for example from the client connection), or would that need new plumbing?

   Rajesh, Shagun Labs
5. MisterRaindrop commented on Oct 20, 2026

   

   MisterRaindrop

   on Oct 20, 2026

   ContributorAuthor

   More actions

   Thanks, that makes the scenario clearer.

   An operator-controlled setting that prevents callers from setting readonly=false would be in scope for the MCP server. I would treat it as an additional control alongside database role grants, not a replacement for them. A server-wide setting would not, by itself, support an exception approved by a named person for a specific run; that needs per-run authorization.

   The server does not currently pass an authenticated client or human identity into its tools. It uses configured database credentials, so Cloudberry sees that database role rather than the person who started the agent. A deployment could authenticate clients in front of the MCP server, but we would still need a trusted way to pass that identity into tool calls and record it with writes. An agent-supplied run_id or user name would not provide the attribution you described.

   I think these are useful requirements to consider, but I would keep the per-run authorization and audit design separate from the current write-back PR until we have a concrete identity source and deployment model.
6. 23A91A6183 commented on Oct 20, 2026

   

   23A91A6183

   on Oct 20, 2026

   More actions

   Thanks, that's a clear line, and keeping per-run authorization and audit out of the write-back PR makes sense to me.

   If you have a moment, a few short questions in writing:

   • If a deployment authenticated clients in front of the MCP server, how would you prefer that identity reach tool calls: carried on each call, set once per connection, or something else?
   • For a per-run exception approved by a named person, would you expect the MCP server to hold that approval itself, or to check a separate service before running the query?
   • Would you want the identity recorded alongside the written results, or in a separate audit record?

   Happy to share an early look at what we're building whenever it's useful. Rajesh, Shagun Labs