Stored Procedures as MCP Tools

Any stored procedure you have exposed can be published to AI agents as its own named tool, rather than being reachable only through the generic “execute a procedure” tool. An agent connected to your lake then sees the procedure by name in its tool list — get_order_summary alongside the standard read/write tools — and decides to call it from the description you write.

This is the right treatment for the handful of procedures you want an agent to reach for: a report, a lookup that spans several tables, an atomic write. Leave it off for the rest — a short list of well-described tools is what makes an agent pick the right one.

How to expose one

1. DAB Config → Global Scope — tick the procedure so it is exposed, as you would for any entity.
2. Open the procedure’s gear and switch on Expose as MCP tool (off by default). Only stored procedures offer this — tables and views are already covered by the standard tools, and the setting is refused on them.
3. Fill in Description in the same dialog (see below — this is the important part).
4. Save the scope, then click Restart DAB when you are ready. As everywhere else on this page, nothing restarts the engine behind your back; batch your changes and apply them in one restart.

The tool name is your procedure name in snake_case. GetProductById becomes get_product_by_id; usp_CreateOrder becomes usp_create_order. The gear dialog shows you the derived name as soon as you switch the toggle on, so there is no guessing about what agents will see. If you care how the tool reads, name the procedure accordingly.

Write the description as an instruction. A named tool carries no parameter list of its own, so the description is the only thing an agent has when it decides whether this is the tool for the job. “Order summary” tells it almost nothing. This does:

Returns order totals, line count and last order date for one customer. Needs the customer id. Use for “how much has this customer bought” questions; not for line-level detail.

Agents work in two steps — they call describe_entities to learn the procedure’s parameters, then call the tool. So the description gets the tool chosen, and describe_entities tells the agent what to send. The column meanings you set on your tables feed the same discovery step, which is why filling those in makes agents noticeably better at using your lake.

It changes what agents can find, not what they can do. The tool is listed only for callers that already hold execute rights on that procedure — the standard data-plane role, or an API key scoped to it. A key without execute never sees the tool. The procedure runs under the platform’s session identity exactly as it does over REST, so row-level security and any checks inside the procedure apply unchanged.

Tell connected agents to reconnect. MCP clients read the tool list once when they connect and cache it for the session. After Restart DAB the new tool is live, but a client that was already connected keeps showing the old list — disconnect and reconnect the connector (or restart the client) to pick it up. The same applies when you rename or remove one.

Turning it off removes the named tool at the next Restart DAB. The procedure stays exposed and still works over REST and the generic procedure tool; untick it in the Global Scope to remove it altogether.