Look up in table

Let the LLM query a database table by filtering on column values. When requiresApproval is true, both the lookup AND its distinct-values companion require approval.

Ingredient Family: llmQueryToolIngredients

Outline Display: Allow LLM to look up data from {{lookupTable}}: {{toolDescription}}
Max results: {{maxResults}}
Require filter: {{requireScope}}{{rowFilters:
Row filters: {{rowFilters}}}}{{guards:
Guards: {{guards}}}}{{advisory:
Not enforced by the server: {{advisory}}}}

Details

guards run once per row the lookup is about to return, over every column of the table – the ones hidden from the LLM included, since the row is the table’s and not the LLM’s argument list. One refusal returns no rows at all and tells the model the guard’s message, so a rule states what may be read, where rowFilters states which rows exist to be read at all. The distinct-values companion enumerates a column rather than surfacing rows, so guards do not run on it – which means a guard cannot keep a column confidential: the companion lists that column’s values whatever the guard would have said. Hide such a column from the tool (lookupTableColumns) or filter the rows away (rowFilters).

Local scope

Names introduced within this component’s knobs:

• lookupTable – table chosen from the app’s schema (via lookupTable knob)
• guardScope – empty table populated by ingredients

Settings

Required

• lookupTable : table
  The table the LLM can query. By default the LLM sees every column; restrict which columns are visible to it with the companion lookupTableColumns setting (a list of column names). Columns you omit are hidden from the LLM entirely – it never sees their values. This is the column-level counterpart to rowFilters, which restricts rows.

• toolDescription : constant value (type: text; required, non-nullable)
  A description of what this table contains, to help the LLM decide when to use it

Optional

• toolTitle : constant value (type: text; optional)
  The human-readable name an MCP client shows for this tool (MCP’s title), never read by a model. Omitted, it is derived from the wire name: search_open_orders becomes “Search Open Orders”. Two tools in one module cannot share a title, derived or authored.

• advisory : constant value (type: text; optional)
  A rule the server does NOT enforce, sent to the model as guidance under an explicit ‘not enforced’ header; use only when no deterministic form (Require, parameter constraints, allowedRecipients…) exists. The checker warns and the dashboard shows it as not guaranteed.

• maxResults : constant value (type: integer; required, non-nullable)
  Maximum number of rows a single lookup call may return. Caps result size so a broad query cannot dump the whole table.

• requireScope : constant value (type: bool; required, non-nullable)
  When true, the LLM must provide at least one column filter on each call; calls with no filter are rejected so the whole table cannot be dumped.

• requiresApproval : constant value (type: bool; required, non-nullable)
  Require the user to approve each invocation of this tool before it runs. Only honored inside a Chat concept, where the agent pauses mid-turn and shows Approve/Reject buttons; rejecting tells the LLM the call was denied and ends the turn. Setting it true on a tool used by any other agent (e.g. a row-action AskAnLLM triggered by a button) is rejected by the NectryCore typechecker – except under MCP Server, which only warns. When unset, the tool is gated exactly when its steps make it anything but read-only – the same reading its MCP category comes from, so a tool that annotates itself read-only is not gated – and only where a pause is honored: an unattended surface never invents a gate it cannot keep.

• guards : ingredient slot of rowActionsIngredients(guardScope) (many)
  Rules to enforce before this tool acts, written as row-action steps – normally one Require per rule. The steps run in order over the row named in this tool’s details, and the first refusal ends the call: nothing is written, read or sent, the model is told the refusal’s own message, and that message is also appended to the tool’s description and listed as a rule on the tool’s card. Omit it to enforce nothing.

• rowFilters : row filters on lookupTable
  Restrict which rows the LLM can see when querying this table, using filter operators like eq, neq, gt, lt, in, currentUser, etc. Each filter is a list item with a kind (the operator) and settings.
  Operators: eq, neq, gt/gte/lt/lte (column/value), in (column/values list), after/before (column/days), currentUser (column only).