> ## Documentation Index > Fetch the complete documentation index at: https://docs.usenexio.com/llms.txt > Use this file to discover all available pages before exploring further. # Platform tools > Know which tools the assistant runs on the server, what they can read or change, and how writes are audited. **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](/conversations/configuration#data_sources). 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. | Tool | Returns | Capability | Data-access key | | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ----------------- | --------------- | | `engines.list`, `engines.get` | Engines and their details | `engines:read` | `engines` | | `engine.versions.list` | An engine's released versions | `engines:read` | `engines` | | `runs.list`, `runs.get` | Runs and their status | `runs:read` | `runs` | | `run.input.get`, `run.output.get` | A run's input and output, bounded | `runs:read` | `run_payloads` | | `catalog.search`, `catalog.resolve` | Search the records the organization's data connection serves, or resolve free text against the taxonomy they use | `catalog:read` | `catalog` | | `graph.overview`, `graph.list`, `graph.get`, `graph.related`, `graph.provenance`, `graph.find` | The graph over served data | `graph:read` | `catalog` | | `webhooks.list` | Webhook endpoints | `webhooks:manage` | `webhooks` | ## `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. | Tool | Does | Capability | Data-access key | Effect | | -------------------- | ---------------------------------------------------------- | ----------------- | --------------- | ----------- | | `runs.submit` | Submits a run | `runs:write` | `runs` | write | | `run.cancel` | Requests cancellation of a queued or running run | `runs:write` | `runs` | write | | `runs.annotate` | Adds an annotation to a run | `runs:write` | `runs` | write | | `webhooks.update` | Updates a webhook endpoint | `webhooks:manage` | `webhooks` | write | | `webhooks.test_send` | Sends a test delivery to an endpoint | `webhooks:manage` | `webhooks` | outbound | | `webhooks.delete` | Deactivates a webhook endpoint, which stops its deliveries | `webhooks:manage` | `webhooks` | destructive | ## 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](/conversations/client-tools#handle-a-confirmation). 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": "", "note": "eval execution: validated shape only, no side effect"}`. Read tools run for real against your org's data. See [Evaluation](/conversations/evaluation). Approve or deny a paused action. Refuse, escalate, or withhold answers by policy.