Skip to content

Warehouse tools and workspace engine tools both serve the same capability, with no arbitration #1155

Description

@ralphstodomingo

When a bound workspace's integration engine attaches, the model is offered two implementations of the same capability with different credential sources: the native warehouse tools (sql_execute, sql_explain, schema_inspect, warehouse_list) over local keychain connections, and the engine's MCP tools over the workspace's SaaS connection.

Nothing arbitrates between them. The model picks by description, and that choice silently decides which credentials run the query and whether the call is audited — engine calls are audited server-side, native calls are not.

Two properties make this hard to get right:

  • The engine's warehouse integrations are not symmetric. Snowflake serves execute/explain/inspect; BigQuery and PostgreSQL serve execute only; Databricks serves execute only. Anything that arbitrates per warehouse type rather than per capability would redirect sql_explain on a BigQuery connection to a tool that does not exist.
  • A running engine is not necessarily serving the bound workspace. An IDE writes its engine entry unpinned, and such an engine serves whichever teammate is active in that IDE, changing at runtime.

Expected: the engine wins for the capabilities it actually serves on a given type, local connections keep serving everything else, and anything undetermined runs locally with an explicit notice rather than silently.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions