get_tool_details → run_tool), and Live Data
tools are always reached through a dispatcher (discover_live_tools → run_live_tool). Both are
explained below; the tools themselves are fully available either way.
Have skills, automations, or saved prompts that call Nekt tools by name? Several tools were
merged into generic versions that take a
kind argument, and the old names no longer exist. See
Changed tool names at the bottom of this page.Asking about Nekt
ask_nekt
Your guide to Nekt: how the platform works and what to build with it. With a question, it answers
from Nekt’s documentation and returns matching playbooks from Nekt Academy (real use cases proven by
Nekt customers) together. focus narrows it: product for how Nekt works only, playbooks for
what to build only. If one of the two lookups fails, the other still comes back.
Without a question, it returns the playbook catalog, filterable by goal, stage, and content type.
With an item_id from a previous result, it returns that full playbook or guide.
Each playbook is matched against the sources your workspace has already connected: ready means
you can build it today, while one_source_away and not_yet list what’s missing. To build one,
your agent creates it one item at a time (source, Query, Notebook, destination, alert, context
document) and asks you to confirm each.
This tool does not query your data. For questions about your own numbers, your agent uses
get_semantic_context and generate_sql.
SQL inside a playbook uses example table names. Your agent maps it to your real tables before
generating and running anything.
Querying data
The path is: read the business context, find the right tables, generate SQL, run it.get_semantic_context
Retrieves the most relevant context-layer documents for a question using vector search over your
business knowledge. Returns curated documentation that explains the business meaning of tables,
fields, and metrics, with each document’s referenced warehouse resources already resolved. This is
the first step of the query workflow: the context it returns grounds generate_sql in your
organization’s own definitions and rules. It is also what decides whether a question should be
answered from the warehouse or from a Live Data connection. For creating semantic
context, see Adding context.
Results are filtered by permission. The context layer is organized into folders, each with
its own access rules, and on Growth and Custom plans this tool returns only the documents the
token’s user is allowed to read. So an empty result has two different causes: the question matched
nothing, or there is documentation the caller cannot see. Your agent handles them differently: it
rephrases into narrower sub-questions for the first, and for the second it tells you there may be
documentation you don’t have access to rather than retrying. See
Permissions.
get_relevant_tables_ddl
Discovers which tables are relevant to a given question using semantic search. Returns the full
schema (CREATE TABLE DDL) for each matched table, useful for understanding available columns and
types before generating SQL.
generate_sql
Converts a natural language question into a SQL query based on your table schemas and the business
context retrieved above. The generated query is scoped to the tables accessible by the token. You can
then execute it using the execute_sql tool.
execute_sql
Executes a SQL query against your data warehouse and returns the results as structured data. Supports
pagination for large result sets (up to 1,000 rows per page). The SQL dialect adapts automatically to
your cloud: BigQuery for GCP and Nekt Express, Athena for AWS.
When a query fails, the error comes back with a likely explanation rather than the raw engine text
alone: in particular it distinguishes a table that exists in your Catalog but has not been
materialized yet (the pipeline that writes it hasn’t produced data) from a table name that is simply
wrong, so your agent stops guessing at names that were already correct.
get_table_preview
Returns a small sample (10 rows) from a table to help understand its contents. Useful for inspecting
column values, data formats, and categorical fields before writing queries.
list_tables
Lists tables in the Catalog one page at a time (100 tables per page). Use this when you need a
deterministic, complete enumeration of available tables: for example, when browsing the Catalog
without a specific question, or when you need a table’s id. For question-driven discovery, prefer
get_relevant_tables_ddl.
Browsing what’s connected
Two tools cover everything in your workspace: sources, destinations, Queries, and Notebooks. Both take akind argument.
list_resources
The single browse tool over all resource types. kind accepts:
Supports free-text
search, plus status, tag, connector_slug, and output_table_name filters
and pagination (100 per page). Pass include_trigger=True to also project each row’s current
trigger: that’s how you review existing schedules, and how your agent discovers the pipeline slugs
available to an event trigger. For transformations, each row also carries the GitHub repo the code is
mirrored to, if any.
get_resource
Returns the full detail of a single source or destination by slug, including its streams and
triggers for a source. Configuration values are redacted for security. For a transformation’s code,
use get_code instead.
Data layers
A layer (lakehouse) is the container every table and pipeline writes into. Nothing can be published without one: a source needs an output layer, and so does a Query or a Notebook.list_layers
Lists all data layers that your token has access to. Returns each layer’s ID, name, slug, and
description. It is the starting point for choosing where a pipeline writes, and for browsing
files in volumes. When your workspace has no layers yet, the result
says so explicitly and points at create_layer, so your agent offers to create the first one
instead of reporting “nothing found”.
With a scoped token, layer and volume browsing is available only when scoped-token browsing has
been enabled for your workspace by Nekt support. See
What a scoped token can reach.
create_layer
Creates a new data layer. Your agent will raise this on its own in two situations: when
list_layers comes back empty (nothing can be published yet), and when you are setting up a
source or a transformation and none of the existing layers fit what you’re building.
It is two-phase: the first call returns a preview (the layers you already have, any name
collision, and a reminder that the name is permanent) and creates nothing. Only a second call
with confirm=True creates the layer.
Ask for a name that will still be right in a year, and favour the role the data plays over a
project, team, or tool name. If you have no convention yet, your agent will suggest the common
stage-based one: Raw (landed as the source produced it), Trusted or Silver (cleaned, typed,
deduplicated), Service or Gold (modelled for consumption), though organizing by domain
(Finance, Marketing) is equally valid.
Creating a layer needs a full access token created by an Owner or an Admin. Other tokens get
a clear message saying so, and layers can always be created in the Nekt web app instead.
Connecting sources
Sources pull data into Nekt from external systems: Shopify, HubSpot, Postgres, and more. New sources are created through a draft → publish flow: create a draft, hand the user a secure browser link to complete OAuth or enter secrets (credentials never pass through the chat), validate the live connection, then finalize. Every step is a cross-kind tool called withkind="source":
list_connectors(kind="source")/get_connector(kind="source"): find the connector and read its config schema to see required and secret fields.create_draft(kind="source"): create a draft (connector slug and a description are required; no tables or pipeline yet).get_setup_link(kind="source"): for OAuth/secret connectors, hand the user a deeplink to finish setup in the browser.validate_source_connector_config: test the real connection.check_connector_validation: poll until validation succeeds and the available streams come back.complete_pipeline(kind="source"): finalize the draft: choose streams, output layer, and trigger. Tables are provisioned and the pipeline is deployed.
Connectors with no secret fields can skip step 3: pass the full config directly at
create_draft.list_connectors
Lists the connector types you can connect, returning each one’s slug and metadata. Use it to discover
the slug needed to start a draft. Pass kind="source" or kind="destination".
get_connector
Returns a connector’s configuration schema (config_template): every field, which are required, and
which are secret, plus a convenience split so your agent can decide the flow. Connectors with secret
fields (OAuth, API keys, passwords) go through the browser deeplink; connectors without secrets can
be configured entirely in chat. Pass kind="source" or kind="destination".
create_draft
Creates a draft source or destination: the first step of connecting one. A draft has no provisioned
tables and no deployed pipeline; the connector slug and a description are required, so you can start
the connection before any secrets exist. For no-secret connectors, you can pass the full config here
directly.
get_setup_link
Mints a time-limited (24h) deeplink for a draft so the user can complete OAuth or enter secret values
in the browser: secrets never pass through the chat. Present the link and wait for the user to
finish before continuing; the token auto-invalidates once the resource leaves draft. The page fills
only the connector config, not streams, tables, or triggers.
validate_source_connector_config
Tests the connector configuration by actually connecting to the external system, catching bad
credentials or wrong hosts before the source is finalized. For drafts set up via the deeplink, it
re-validates against the config stored on the backend, so secrets never round-trip through the chat.
Returns a validation ID to poll. This step is source-only: destinations publish directly.
check_connector_validation
Polls a validation job until it finishes. On success, it returns the available streams: the
tables/objects the source can pull, each with its supported sync types, fields, primary keys, and
replication keys. Present these so the user can choose which streams to sync before completing the
source.
complete_pipeline
Finalizes a draft. For a source (kind="source"), it requires a description, an output layer, at
least one stream, and a trigger (manual, cron, or event); each stream specifies a destination
table name and a sync type: INCREMENTAL (append new/changed rows) or FULL_SYNC (replace all).
For a destination (kind="destination"), it takes the tables to deliver and a trigger.
Completion is one-way: it provisions warehouse tables and deploys the pipeline.
For a source, the destination table names are prefixed with the connector’s name automatically
(hubspot_deals, hubspot_contacts), matching what the web app does. That is what keeps a second
source from colliding with the first over generic stream names like users or contacts, and a
table name cannot be changed after it is created. The final names come back in the result, so your
agent reports the tables you actually got.
Managing a live source
Once a source is published, these change it in place.update_source_streams
Adds new streams or edits which streams a live source pulls, applied in place without a redeploy. It
is non-destructive: it never removes streams or drops tables; to stop a stream, disable it. Removing
streams and dropping tables is deliberately left to the web app.
update_trigger
Changes the trigger of an already-live source: manual, cron (a schedule), or event (run when
upstream pipelines finish). Use kind="source". The same tool handles transformation triggers; see
Creating and editing pipelines.
run_pipeline
Triggers an extraction run of a live source on demand, optionally as a full sync or for selected
streams. Use kind="source". This consumes credits, so the assistant confirms before running.
Connecting destinations
Destinations deliver data out of Nekt to external systems: Slack, Google Sheets, Postgres, webhooks, ad platforms, and more. The flow is the same shape as a source, withkind="destination",
and one difference: destinations have no validation step; they publish directly.
list_connectors(kind="destination")/get_connector(kind="destination"): find the connector and read its config schema.create_draft(kind="destination"): create a draft (connector slug and a description; input tables optional here).get_setup_link(kind="destination"): for OAuth/secret connectors, hand the user a deeplink to finish setup in the browser.complete_pipeline(kind="destination"): finalize: choose the tables to deliver (each with its fields, and optional primary keys or field renames) and a trigger. The delivery pipeline is deployed.
list_resources(kind="destination") and get_resource(kind="destination");
running one on demand is run_pipeline(kind="destination"): fire-and-forget, with the assistant
confirming first. Run history comes from list_pipeline_runs and get_pipeline_run_logs.
Creating and editing pipelines
create_query
Deploys a SQL Query as a pipeline in Nekt. Accepts the SQL code, a description, the output layer and
table name, and an optional trigger: either a cron schedule or an event trigger that runs the Query
when one or more upstream pipelines finish.
It is two-phase: the first call returns an authoring guide and a preview of exactly what will be
created, without creating anything; your agent shows you that and only creates the pipeline on a
second call with confirm=True. The pipeline then starts in preparing status; poll
get_pipeline_status until it leaves preparing, then trigger execution with run_pipeline once
you confirm.
Optionally, the Query can be created already connected to a GitHub repo: pass the repository full
name (and optionally a branch), and Nekt creates, connects, and pushes the first commit in one step.
The folder in the repo is always the generated pipeline slug. See
Syncing transformation code to GitHub.
create_notebook
Deploys a Python or PySpark Notebook as a pipeline in Nekt. Accepts the notebook code, a description,
the runtime type (python-base, pyspark, or python-browser), optional pip dependencies, and an
optional trigger. For PySpark notebooks, Spark driver and executor sizing can also be configured.
Inputs and outputs are extracted automatically from nekt.load_table and nekt.save_table calls in
the code, so the notebook must use the Nekt SDK for all table I/O.
Like create_query, it is two-phase (preview first, then confirm=True), follows the same
deploy-then-run lifecycle, and can be created already connected to a GitHub repo.
get_code
Returns the current code of a Query or Notebook by slug, along with its configuration and whether it
is connected to a GitHub repo. Use it before editing so changes are made against what is actually
deployed.
update_transformation
Edits an existing transformation, a Query or a Notebook, with no kind argument; it infers the
type. Updates the code, description, dependencies (Notebooks only), active state, and retry settings.
If the transformation is connected to GitHub, changing its code auto-commits the change; no extra
parameters are needed.
update_trigger
Replaces the trigger of an existing pipeline. Supports three trigger types: manual (runs only on
demand), cron (runs on a schedule, with a cron expression and timezone), and event (runs whenever
upstream pipelines finish). For event triggers, provide the triggering pipeline slugs and an optional
rule: any runs it when any of them completes, all waits for all of them. Use
list_resources(kind=..., include_trigger=True) to discover the available slugs. Defaults to
kind="transformation"; pass kind="source" for a source.
Running and monitoring pipelines
run_pipeline
Triggers execution of a deployed pipeline by slug. Defaults to kind="transformation" (Queries and
Notebooks); pass kind="source" to trigger an extraction or kind="destination" to trigger a
delivery. Returns immediately without waiting for the run to finish: use get_pipeline_status to
track progress.
get_pipeline_status
Returns the current status of any pipeline by slug: Sources, Queries, Notebooks, or Destinations.
Used to track deployment progress after create_query or create_notebook (until status leaves
preparing), and to monitor execution after run_pipeline until it reaches a terminal state
(success or failed).
list_pipeline_runs
Lists recent runs of any pipeline by slug. Returns a summary for each run including its id,
status, start and end times, and trigger_type. Paginated (25 per page by default, up to 100).
Use this to inspect a pipeline’s execution history, such as checking for recent failures or
confirming that a trigger fired.
get_pipeline_run_logs
Fetches the logs of a specific run, or of the most recent run when only a pipeline slug is given.
Returns the ERROR-level entries and, when available, Nekt’s AI analysis of the failure: a summary
of what happened, the technical details, and a suggested fix. Use this to diagnose a failed run
without reading the full log.
update_alerts
Turns failure alerts on or off for one source, destination, or transformation, by slug. While
subscribed, every failed run of that pipeline emails you. Pass kind to say which resource
type the slug belongs to: "source", "destination", or "transformation" ("query" and
"notebook" are accepted too, since that’s how list_resources names them).
Alerts are per user and failure-only. Subscribing emails the Nekt account this connection
authenticated as: it is not a workspace-wide switch, and it doesn’t touch the workspace’s global
alert emails configured in the app. Unsubscribing stops your emails and nobody else’s.
get_resource (sources and destinations) and get_code (transformations)
already carry it; no extra call needed.
Alert subscriptions are tied to a real user account, so this needs a full access token; a
table-scoped token has no user to email and is refused with a message saying so.
Adding context
The context layer is the curated business knowledge your agent reads before writing SQL: what tables and fields mean, how metrics are defined, and which source to prefer for which question.get_semantic_context (above) reads it; these tools curate it.
update_resource_description
Updates the Description of a resource in your Catalog. Supported resource_type values are layer,
table, field, folder, volume_file, and derived_field. Returns a preview by default: pass
confirm=True to apply the change.
When resource_type is derived_field, the tool first identifies the Query or Notebook that
produced the target table (via list_resources(kind="transformation")), then enriches the field
Description with structured tags inferred from the transformation code: @pk, @fk <table>.<column>,
@measure additive|non-additive, @attribute, and @grain=<period>. Use this when annotating fact,
aggregated, or dimension tables so downstream consumers and AI agents can interpret each column’s
role.
list_semantic_layer_folders
Lists the folders of the context layer, so a document can be filed in the right one. On Growth and
Custom plans each folder has its own access rules, so where a document goes is a real decision:
a document filed in the wrong place is invisible to the people who needed it, and creating one
without a folder targets the root, which most users cannot write to.
Returns each folder’s ID, name, readable path (Marketing / Metrics) and your permission level on
it. Pass writable_only=True to see only the folders you can actually save into: your agent calls
it that way before creating a document, not after being denied. When several folders plausibly
fit, it will ask you which one rather than guessing.
create_semantic_layer_folder
Creates a folder in the context layer, at the root or inside an existing folder. Your agent offers
it when list_semantic_layer_folders comes back empty, or when no existing folder fits the document
you are filing. It is two-phase: the first call checks the name against the folders that
already exist at that level and creates nothing; a second call with confirm=True creates the
folder.
A subfolder needs Editor on its parent folder, and a top-level folder needs Editor on the root of
the context layer, which Owners and Admins hold by default. On Free and Starter, where
context-layer permissions are not enforced, every member can create folders.
create_context_document
Creates a new context-layer context document: reusable business knowledge such as metric
definitions, segment logic, or table interpretations that should inform future analyses. Documents
support annotations (@table, @field, @layer, @measure, @transformation, @source,
@destination, @context) that link the prose to specific warehouse resources. Returns a preview by
default: pass confirm=True to save the document after reviewing it.
It also takes the folder to file the document in. Pick that first with
list_semantic_layer_folders: a document created without a folder
lands at the root of the context layer, which most users are not allowed to write to, and needs
editor or manager access on the folder that receives it.
Context documents are also how you steer Live Data routing: a document that says which
questions should be answered from a connected app rather than the warehouse makes that routing
automatic next time.
update_context_document
Updates an existing context-layer context document when a definition is refined, a segment is added,
or business rules change. The full name and content are replaced, so the saved version always
reflects the complete document. Returns a preview showing the current versus new content by default:
pass confirm=True to apply the change.
On Growth and Custom plans, editing a document needs Editor on it (a grant on its folder counts),
and the tool is available only to people who hold Editor on at least one document.
delete_context_document
Reached through the dispatcher: see More tools.
update_context_document when a document is merely out of date. Returns a preview of the document to
be removed by default: pass confirm=True to delete it (there is no undo).
On Growth and Custom plans, deleting a document needs Manager on it, one level above what creating
and editing need.
resolve_references
Reached through the dispatcher: see More tools.
Live Data
Live Data tools read from and write to your connected apps in real time, such as HubSpot, Slack, Grafana, or an ad platform, rather than reading the copy of that data in your warehouse. Because the set of live tools grows with every connector you attach, they are not listed individually in your agent’s tool list. Two tools cover all of them. Find the list of MCP connectors, with the tools each one exposes, in MCP connectors.discover_live_tools
Lists your organization’s connected Live Data tools, grouped by connection: the connector, its
namespace, and for each tool its exact name, description, input schema, and whether it writes. It
refreshes on demand, so a connector you linked after your client connected shows up without
reconnecting.
run_live_tool
Calls a live tool by name, passing arguments built from its input schema. Since live tools aren’t
listed individually, this is how every one of them is invoked.
The call order is:
Why discovery comes first. Live tool names are specific to your organization and can change, so
an agent should resolve them at run time rather than hardcoding them into a skill or automation.
Discovery also disambiguates two connections of the same app: a Marketing HubSpot and a CS
HubSpot show up as separate entries, so your agent can ask which one you mean.
A full access token sees every live connection its user can use. A scoped token sees only the live
connections (and, within each, the tools) selected on it; a token scoped only to tables sees none.
If your organization has no Live Data connections, these tools simply return nothing and the
routing guidance is omitted from your agent’s tool list entirely.
Browsing files in volumes
Volumes are file stores that live inside a layer, so browsing starts fromlist_layers. The file tools below, including the two that upload a file, are
reached through the dispatcher: see More tools.
list_volumes
Reached through the dispatcher: see More tools.
list_layers to discover available file
containers.
list_files
Reached through the dispatcher: see More tools.
read_file
Reached through the dispatcher: see More tools.
download parameter returns a presigned URL, a base64 string, or an MCP resource blob instead (up to
10 MB).
create_volume_upload_url
Reached through the dispatcher: see More tools.
curl) on the machine holding the file; in a chat client without a filesystem, use the
upload button on the volume page instead. Uploading a name that already exists in the volume
replaces that file. Needs Editor access on the volume.
complete_volume_upload
Reached through the dispatcher: see More tools.
create_volume_upload_url, using the ETag returned for each uploaded
part. Until it runs, the file appears in list_files but cannot be read. Your agent calls it right
after the parts are uploaded.
Syncing transformation code to GitHub
Query and Notebook code can be mirrored into your own GitHub repository (one GitHub App installation per organization). The repo is a code mirror: a transformation’s trigger, output layer, and settings still live in Nekt. There are two paths: create a transformation already connected to a repo (viacreate_query / create_notebook), or connect transformations that already exist. Once a
transformation is connected, editing its code with update_transformation auto-commits the change:
no extra parameters needed.
To see which transformations are already connected and where, use
list_resources(kind="transformation"): each row carries its GitHub repo.
list_github_repositories
Reached through the dispatcher: see More tools.
my-org/analytics) needed when creating or connecting
transformations.
connect_transformations_to_github
Reached through the dispatcher: see More tools.
Managing permissions
These tools read and change who can access what, on the three permission axes:catalog (layers,
folders, tables, and volumes), others (secrets and live connections), and semantic_layer
(context-layer folders and documents). Pass the axis as axis; it defaults to catalog.
The ceiling is always the person behind the token: an agent can grant only what that person could
grant in the app. A Member holding Manager on a resource can grant, change, or revoke Viewer and
Editor there; only Owners and Admins can create or remove Manager grants. Grants are enforced on
Growth and Custom plans. All of these tools need a full access token; a scoped token is refused.
See Permissions for the model itself.
list_permissions
Lists the grants on one axis, optionally narrowed to one resource. Owners and Admins see every grant
in the workspace; a Member sees their own, the ones their groups carry, and every grant on a
resource they manage.
list_permission_recipients
Lists the people and groups that can still be added to a resource, so your agent can turn a name
into an id before granting. It leaves out Owners and Admins, who already have access to everything,
and anyone who already holds a grant on that resource.
list_permission_groups
Lists the workspace’s permission groups and their members, with optional filters by name or by
person. Use it to explain access a person has through a group rather than a grant of their own. The
built-in All group contains every member automatically and cannot be edited or deleted.
grant_permission
Grants a user or a group viewer, editor, or manager access to a resource. It is
two-phase: the first call returns exactly what would be written; a second call with
confirm=True applies it.
update_permission_level
Changes the level of an existing grant in place. Prefer it over revoking and granting again:
revoking removes the resource from any scoped MCP token that relied on that access, and granting it
again does not put it back. Two-phase, like grant_permission.
revoke_permission
Removes a grant. The resource is also removed from any scoped MCP token that relied on it, and
re-granting later does not restore those tokens; their owners have to select the resource again.
Two-phase.
manage_permission_group
Creates, renames, or deletes a permission group, or adds and removes its members. Adding a person to
a group gives them everything the group can reach, on all three axes. Owners and Admins only, and
two-phase. The All group cannot be changed.
Managing MCP tokens
These tools let an agent create and maintain MCP tokens for other agents and automations. They need a full access token, so a scoped token can never widen itself or mint a wider one, and they only see tokens created by the person behind the current token. A new token can never reach more than that person.get_mcp_token_available_scopes
Lists the tools and live connections a new token can be scoped to, for your organization’s MCP
Server version. Tables, volumes, secrets, and documents come from their own listing tools.
list_mcp_tokens
Lists the tokens created by the person behind the current token, with each one’s description,
expiration, and scopes. The token secret is never included.
create_mcp_token
Creates a token, scoped per resource type and per tool. It is two-phase: the first call
previews the scope and creates nothing. The result never contains the secret: it carries a one-time
link, valid for 15 minutes, that opens only in the creator’s own browser session. Open it yourself
and paste the token into the tool that will use it. Tokens last one year.
update_mcp_token_scopes
Changes what an existing scoped token can reach, one resource type at a time. Each value you pass
replaces that axis entirely; axes you omit stay as they are. A full access token takes no scope.
Two-phase.
rotate_mcp_token
Replaces a token’s secret and keeps its description, scopes, and expiration date. Everything still
using the old secret stops working immediately, including OAuth connections built on it. Like
creation, it returns a one-time link instead of the secret. A token cannot rotate itself. Two-phase.
Token access log
Every request made with an API key or an MCP token is recorded in the token access log: which token, who created it, which action, which endpoint, the status, and the request content. Because a query’s SQL is part of the request, this is where you find out which tables an AI agent queried. You can browse it in the app under Settings → Audit logs, and the same log is available through the Platform API. To report on a whole period at once, with each log’s full detail and what its Athena queries scanned and cost, export it as a Parquet file through the Platform API. Every tool an MCP token calls is recorded as its own entry, named after the tool (for example,execute_sql, generate_sql, get_table_preview), so you see which tool an agent called, not
just which endpoint it hit. This includes tools that never reach the API, such as generate_sql,
get_semantic_context, and the Live Data tools, as well as calls the token’s scope
refused. Opening an entry shows the tool’s arguments and the requests that tool triggered.
Owners and Admins see every token in the workspace; other members see only the tokens they created.
The log is not available on the Free plan, and it covers the last 7 days on Starter, 30 on Growth,
and 90 on Custom. Both tools need a full access token.
list_token_access_logs
Lists the log newest first, filtered by date range, token, token kind (API token or MCP token),
token creator, action, transport (HTTP or WebSocket), or status code. Without a start date it
covers the last 30 days. Results are paginated; to sync incrementally, pass the newest
created_at you already have as the lower bound.
get_token_access_log
Returns one log line together with the recorded request content: the request body (including the
SQL of a query), the query string, and a short list of headers. Credentials are masked. The content
can occasionally be unavailable while the line itself is intact.
More tools
A long tool list measurably degrades how accurately an agent picks the right tool, so nine rarely-used tools are kept off the main list. They remain fully available through two dispatcher tools, and they are documented in their own sections above.get_tool_details
With no argument, returns a catalog of every tool kept off the main list. With a tool name, returns
that tool’s full documentation and input schema, plus whether it writes or is destructive, so your
agent can confirm with you before firing a write.
run_tool
Runs one of those tools by name, passing the arguments built from its schema. Two-phase tools behave
exactly as documented: call again with confirm: true in the arguments to commit.
The tools reached this way:
These tools stay off the main list for every session, so each use goes through
get_tool_details → run_tool. Nothing changes about what they do or what they accept, only
how they’re reached.Changed tool names
Several tools were merged into generic versions that take akind argument. The old names no
longer exist. If you have saved skills, automations, or prompts that call them, update them using
this table: the arguments are otherwise unchanged.
list_pipeline_options is the one tool that was removed rather than renamed. It returned every
pipeline in a single unpaginated response; list_resources is paginated and filtered by kind, so
an automation that relied on getting everything at once needs its logic adjusted, not just its name
swapped.Ask your agent to do the migration for you: point it at your skill or automation files and give it
this table. It can find and update every reference in one pass.