Skip to main content
Platform tools are tools Nexio provides and runs on the server during a turn. They let the assistant read your workspace (engines, runs, served data, webhooks) and, when you allow it, make changes (submit a run, cancel a run, update a webhook). They come in two packs, platform.read and platform.write, which you enable in the instance config. Every write pauses for a confirmation and is recorded in a write ledger before it runs. Each tool acts on your organization’s own resources: its engines, its runs, its webhooks, and the records its data connection serves. The tool names are fixed; what they return depends on what your organization has.

​
How the tool list for a turn is built

For each turn request the platform offers the model only the tools that pass all of these checks:
  1. The tool’s pack is listed in tools.platform_packs.
  2. The tool’s data-access key is enabled by data_sources. See Instance configuration. A tool that fails this check is absent, and the system prompt tells the model which data is not enabled.
  3. The caller may use the tool. An organization API key may use every tool below that admits API keys. A scoped key may use a tool only if it holds the capability in the table.
The platform checks the capability again when the tool runs. Engine-scoped reads and writes are also bounded when they run: when the instance’s engines setting lists engines, a tool reaches only those engines, and a scoped key reaches only the engines it is bound to.

​
platform.read

These run without a pause.

​
platform.write

platform.write requires platform.read in the same config. Every tool in the table below pauses for a confirmation; there is no setting that removes the pause.

​
Portal-only tools

The portal’s chat runs as a signed-in portal user, not an API key, and offers more tools to it: metrics, run traces, indexing status, connections and connection validation, sync status, the user’s team, assistant feedback and usage, and provisioning (creating and updating engines, engine configs and versions, instances, and environments). API-key conversations never receive these tools.

​
The write ledger

Every platform write goes through the same steps:
  1. The turn pauses with a pending_confirmation frame whose execution is platform.
  2. You post confirmations with approved: true. See Client tools and confirmations.
  3. The platform checks that the action targets exactly one environment. A write proposed against no environment, or against the portal’s all-environments view, is refused to the model with environment_not_concrete.
  4. The platform writes a ledger row keyed by your org and the tool call id, with the tool name, the acting key or user, and a hash of the input. The row is written before the side effect.
  5. The platform runs the action and settles the row as succeeded, with a reference to the resource it changed, or failed.
If the same approved call is replayed, the ledger row already exists and the platform refuses the second attempt with already_executed, telling the model to check the resource’s current state. If the ledger row cannot be written, the action does not run. Refusals and failures of platform tools reach the model as tool errors, and the turn continues.

​
Writes in evaluation runs

Eval scenarios run turns with real model calls, but platform.write tools run as a dry run: no ledger row, no side effect, and the model sees {"dry_run": true, "tool": "<name>", "note": "eval execution: validated shape only, no side effect"}. Read tools run for real against your org’s data. See Evaluation.

Client tools and confirmations

Approve or deny a paused action.

Guardrails

Refuse, escalate, or withhold answers by policy.
Last modified on September 25, 2026