BridgeScope: Bridging LLMs and Databases

• BridgeScope is a universal toolkit that enables LLM-based agents to orchestrate multi-step data workflows with enhanced security and efficient data transmission.
• It modularizes database operations into fine-grained tools, aligning each tool with specific privileges and reducing the risk of unauthorized actions.
• The innovative proxy mechanism directly connects data-producing and data-consuming tools, substantially lowering token usage and latency in large workflows.

BridgeScope is a universal toolkit for bridging LLMs and databases. It is designed for LLM-based agents that plan multi-step data workflows and call external tools, and it addresses four problems that the paper identifies in prevailing database toolkits: usability, security, privilege management, and data transmission efficiency. Its central design is threefold: database operations are modularized into fine-grained tools, tool exposure is aligned with both database privileges and user-defined security policies, and a proxy mechanism is introduced for direct inter-tool data transfer without routing large intermediate results through the LLM context. The design is presented as database-agnostic and transparently integrable with existing agent architectures, and an open-source PostgreSQL implementation is released (Weng et al., 6 Aug 2025).

1. Problem setting and design rationale

BridgeScope is motivated by the claim that, although LLM agents have become increasingly capable at reasoning and orchestration, the tooling layer between LLMs and databases remains coarse. In the Model Context Protocol ecosystem and similar agent stacks, database access is often exposed through only a small number of generic tools such as execute_sql and get_schema. The paper argues that such interfaces are poorly matched to real data work because they collapse semantically distinct actions—context inspection, querying, updates, deletion, DDL, and transactional control—into a single action surface.

This design has several consequences. A generic SQL endpoint increases the planning burden on the model because the agent must infer not only what to do, but also how to package that intent into a single unrestricted call. It also broadens the attack surface, since a coarse tool can expose destructive or unauthorized operations to a model that may hallucinate, mis-handle prompts, or be affected by prompt injection. A further problem is privilege blindness: if the tool layer does not reflect what a user is actually authorized to do, the LLM may generate infeasible plans and discover failure only when the database rejects execution. Finally, generic agent architectures often route intermediate datasets through the LLM context itself, which increases token cost, stresses context windows, and creates opportunities for relay-time corruption of data (Weng et al., 6 Aug 2025).

The paper therefore treats toolkit design itself as the core systems problem. BridgeScope is not framed as a read-only text-to-SQL pipeline; it targets general data-related workflows that include context retrieval, CRUD operations, transaction management, and routing into downstream analytical tools.

2. Toolkit architecture and operation model

BridgeScope abstracts LLM–database interaction into four core functionalities: F1. Context retrieval, F2. SQL execution, F3. Transaction management, and F4. Data transmission. The end-to-end workflow is agent-centric: a user issues a natural-language task, the LLM decomposes it into steps, database-related steps are delegated to BridgeScope tools, and results are returned either to the LLM or directly to downstream tools.

The architecture replaces monolithic SQL access with operation-specific tools. The representative interface in the paper includes get_schema(), get_object(o), and get_value(col, key, k) for context retrieval; select(sql), insert(sql), and update(sql) for SQL execution; begin(), commit(), and rollback() for transaction management; and proxy(target_tool, tool_args) for data transmission and orchestration. This decomposition is intended to lower cognitive load for the model by making the action space semantically explicit, and it also narrows the control surface exposed to any particular deployment.

A notable design choice concerns schema retrieval. If the number of named database objects is below a user-defined threshold $n$, get_schema() returns standardized representations of all objects. Otherwise, the system adopts a hierarchical strategy in which get_schema() returns only top-level object names and get_object(o) is used to recover details such as columns, indexes, constraints, and dependencies for a selected object. This is presented as a token-management device for large databases.

The get_value(col, key, k) tool addresses a different failure mode: predicate hallucination. Instead of enumerating all values in a column domain, it returns the top-$k$ semantically relevant values with respect to a task-specific key. The paper’s example is that a request about “women’s clothes” can be grounded to actual values present in the database rather than to a hallucinated surface form.

Explicit transaction tools are another architectural distinction. By surfacing begin, commit, and rollback as first-class actions, BridgeScope exposes ACID boundaries directly to the planner. The database engine still provides ACID guarantees, but the toolkit changes the agent’s planning space so that atomic multi-step modifications can be represented explicitly rather than inferred implicitly from unrestricted SQL calls.

3. Privilege alignment and security policy integration

A central formalism in BridgeScope is the representation of a user’s privileges as

$$\mathcal{P}_u \subseteq \mathcal{A} \times \mathcal{O},$$

where $\mathcal{A}$ is the set of database actions and $\mathcal{O}$ is the set of database objects. For each action $a$, BridgeScope defines a dedicated tool $T_a$, and the user’s agent is given access to $T_a$ only if

$(a,o) \in \mathcal{P}_u$

for some object $o$. This makes tool exposure action-aware and object-aware rather than purely prompt-driven.

The paper describes two layers of restriction. The first is database-side privilege alignment: BridgeScope respects the privileges already granted by the DBMS over tables, views, and columns. The second is user-side security policy alignment: administrators can impose white-lists and black-lists that further restrict what the LLM can see or do, even when the underlying user account has broader rights. The examples given include hiding sensitive tables from schema retrieval, blocking destructive actions such as DROP, and limiting the LLM to a safe subset of the user’s own rights.

This reshapes planning rather than merely filtering execution. The LLM sees only the tools it is allowed to call, the objects it is permitted to know about, and schema outputs annotated with privilege metadata. The result is that infeasible workflows are less likely to be generated in the first place. In a read-only setting, for example, the agent may see get_schema, get_object, get_value, and select, but not insert, update, delete, or write-oriented transaction controls.

BridgeScope also performs object-level verification at execution time. Even if the model hallucinates an object name or is induced to attempt an unsafe action, the toolkit checks whether the user has privileges on the target object and whether the action passes user security policy checks. The paper presents this as a rule-based front line that sits before the DBMS’s own eventual rejection, thereby reducing futile reasoning and token expenditure.

4. Proxy-based dataflow and large-workflow support

The third major innovation is the proxy mechanism, which addresses the inefficiency of routing large tool outputs back through the LLM so that they can be forwarded to another tool. BridgeScope formalizes a proxy unit as

$k$0

where $k$1 denotes one or more data producers, $k$2 denotes a data consumer, and $k$3 is an adaptation function that transforms producer outputs into the format expected by the consumer.

This abstraction is recursive. A proxy unit can itself be treated as a producer for a higher-level proxy unit. The paper gives the example

$k$4

followed by

$k$5

Execution is bottom-up: run leaf producers first, apply the adaptation function, send transformed output directly to the consumer, and propagate the consumer’s output upward until the composed workflow finishes and only the final result returns to the LLM.

The implemented API is proxy(target_tool, tool_args). The LLM specifies a downstream consumer tool and, for each of its inputs, which producer tool or tools should generate the required data and how the outputs should be transformed. The proxy tool then invokes producers, gathers outputs, applies transformations if necessary, passes the data directly to the consumer, and returns the consumer’s output.

This design is especially important for data-intensive workflows. The paper argues that it mitigates context-window exhaustion, token blow-up, latency from repeated LLM-mediated transfers, and corruption or hallucination introduced when the model relays structured data. It also enables parallel execution of multiple producers. At the same time, the paper is explicit that the proxy is described at the API and abstraction level rather than as a low-level storage substrate: it does not specify persistent handles, serialization protocols, retention policies, or object-lifecycle management (Weng et al., 6 Aug 2025).

5. Implementation, benchmarks, and empirical findings

BridgeScope is presented as database-agnostic in design, but the released implementation targets PostgreSQL. In evaluation, it is integrated into two prototype ReAct-based agents using GPT-4o and Claude-4. The main baseline is PG-MCP, adapted from the official PostgreSQL MCP server and equipped with two tools, get_schema and execute_sql. Additional variants are used to isolate specific effects, including a reduced-data proxy baseline on a 20-row table.

The paper evaluates the system on two new benchmarks. BIRD-Ext extends the read-only BIRD benchmark with synthesized INSERT, UPDATE, and DELETE tasks. It contains 150 randomly sampled original SELECT tasks and 150 synthesized modification tasks, for a total of 300. NL2ML targets data-intensive end-to-end machine-learning workflows on the California Housing dataset, which contains one house table with 10 columns and 20,000 rows; it includes 30 natural-language tasks organized into three complexity levels corresponding to one, two, and three layers of proxy-unit abstraction.

The reported metrics are task completion rate, accuracy, average number of LLM calls, token usage, and transaction initiation correctness. On BIRD-Ext, BridgeScope reduces average LLM calls by over 30% relative to a variant without explicit context tools, approaching the best-achievable value of three calls: context retrieval, SQL execution, and result finalization. Its action-specific SQL tools achieve comparable task accuracy to the baseline’s single execute_sql tool on feasible tasks. For transaction handling, agents with BridgeScope always initiate transactions correctly when needed, whereas agents with PG-MCP rarely recognize the need for transaction management.

Privilege-aware tooling is reported to reduce reasoning cost sharply on infeasible tasks. Across simulated roles—Administrator, Normal User, and Irrelevant User—BridgeScope reduces LLM reasoning steps by 23%–71% and token costs by 30%–82% on infeasible tasks, with the paper emphasizing up to 80% token reduction through improved security awareness and early abortion of infeasible workflows.

The proxy mechanism produces the strongest capability contrast. On NL2ML, task completion rate is 1.0 for BridgeScope with both GPT-4o and Claude-4, while PG-MCP records 0.0 on the realistic large-data setting; a reduced-data baseline works only on a tiny 20-row table. Average token usage is 13,449.7 for GPT-4o and 15,622.3 for Claude-4 with BridgeScope, compared with 21,047.6 and 22,353.1 respectively for the reduced-data baseline. The paper further estimates that an idealized unlimited-context PG-MCP agent would still require at least two transfers of the full table, totaling no less than 1,500,000 tokens. Average LLM calls are 3.37 for GPT-4o and 3.40 for Claude-4, close to the minimum workflow of context retrieval, proxy execution, and result finalization (Weng et al., 6 Aug 2025).

6. Scope, misconceptions, and limitations

BridgeScope is broader than text-to-SQL. Its design target is general data-related workflow orchestration, including CRUD, transactionality, and routing to downstream analytical tools. A common misconception is therefore to read it as merely a safer execute_sql wrapper. The paper argues instead that the database tool interface layer is itself a first-class systems problem.

A second misconception would be to treat the proxy mechanism as a complete storage and reference-management substrate. The paper does not make that claim. The proxy abstraction is explicit and formalized, but it is specified as an execution contract rather than as a persistent object system. No substantial systems detail is given about handles, serialization formats, cleanup policies, or distributed execution semantics.

The design is also not presented as a fully quantified security solution. The paper states that privilege and policy violations were successfully intercepted by rule-based controls, and on that basis omits a separate detailed security experiment. This suggests that the security argument is supported primarily by architecture and by the efficiency gains on infeasible tasks rather than by an extensive red-team evaluation.

Several further limits are visible. The implementation includes a carefully crafted prompt, which implies some dependence on prompt quality and model capability. Although the toolkit is described as database-agnostic, only PostgreSQL is demonstrated in evaluation. The mathematical formalism is intentionally light, centered mainly on the privilege set $k$6, the tool-exposure condition, and the proxy-unit abstraction $k$7. The paper is therefore principally a systems-design contribution rather than a theory-heavy one.

Within those bounds, BridgeScope’s significance lies in reframing LLM–database interaction around controllable, privilege-aware, ACID-aware, and data-efficient tooling. Its practical claim is not that database reasoning should be delegated wholesale to a LLM, but that the action space presented to the model should encode database semantics, privilege structure, and inter-tool dataflow explicitly.