# RadixScan Agent Layer — full reference

> Detailed, machine-oriented description of the RadixScan agent layer for Radix.
> Status: discovery online (v0). The Read+Build MCP server described below is
> built and tested; the public endpoint is in preparation. Tool names and shapes
> are stable but may still change before the public launch.

## What this is

A focused set of tools that let AI agents read the Radix ledger, build and
simulate transaction manifests, and (later) hand a transaction to a human for
signing. It reuses the same battle-tested manifest engine that powers the
RadixScan developer console, so an agent builds exactly the manifests a human
tool would.

## Why Radix is structurally agent-friendly

- Transactions are expressed as readable, typed "manifests", so an agent can
  parse, verify and explain intent.
- Manifests can be statically analyzed (worktop simulation, type checks) before
  signing.
- The Gateway offers a free transaction preview: fee estimate, balance changes,
  success/failure — an agent never acts blind.
- Tokens are native ledger resources, not bespoke contracts — fewer edge cases.

## Interface

- Protocol: MCP (Model Context Protocol) over Streamable HTTP.
- Endpoint (coming): https://mcp.ai.radixscan.io
- Auth: none for read & build (keyless). Signing (later phase) is a
  human-in-the-loop handoff to the Radix Wallet — keys never reach the agent.

## Conventions (all tools)

- Every response includes a `network` field (mainnet | stokenet). Mainnet
  responses carry a `risk`/`warning` field.
- `response_format`: `concise` (default) | `detailed`. Granular opt-in flags
  where useful (e.g. `include_events` on radix_get_transaction).
- Responses are structured JSON of hard facts — not prose. The consuming agent
  writes any natural-language summary itself. The one exception is
  radix_explain_manifest, whose job is a plain-language explanation.
- Lists are paginated (cursor/limit) with a truncation hint.
- Errors are structured with a cause AND an actionable next step.

## Read tools

- radix_resolve_address — any address -> type (account/resource/component/
  validator/package/…) + core metadata. The network is inferred from the address.
- radix_get_account — balances, fungibles, NFTs of an account. Zero-balance
  entries are hidden by default (hide_zero).
- radix_get_resource — token/NFT metadata, supply, divisibility.
- radix_get_transaction — structured "data triptych": core metadata
  (status, timestamp, fee, manifest classification) + aggregated net
  account-level balance changes + the decompiled (readable) manifest.
  Events are opt-in via include_events. Committed transactions are immutable,
  so results are cached permanently.
- radix_get_validator — stake, uptime, fee, owner.
- radix_get_validator_list — the active validator set for a network, with rank,
  fee percentage and uptime — for picking or comparing validators.

Note: an RNS/domain entry-point search (radix_search) is deferred until Radix
Name Service data is available on-ledger.

## Build tools (keyless)

- radix_build_transfer — goal-oriented: build a token-transfer manifest
  (lock_fee, withdraw, deposit) for fungibles and/or NFTs in one call.
- radix_build_manifest — takes a strict typed step array (no raw text) and
  returns a canonical, RET-validated manifest + diagnostics. The backend
  generates the syntax, so the agent never hand-writes manifest text.
- radix_validate_manifest — parse + static checks of a given (possibly
  external) manifest via the Radix Engine Toolkit. Accepts raw text, read-only.
- radix_preview_transaction — real Gateway preview (free, no signing): fee
  estimate, net balance changes, success/failure. Carries a `simulated_at`
  timestamp and epoch validity window.
- radix_explain_manifest — manifest -> plain-language, step-by-step reading;
  the one prose tool, the basis for a human signature confirmation.

## Manifest documentation tools

A self-describing manual for writing manifests, also exposed as radix://manifest/*
resources (same content).

- radix_manifest_workflow — orientation: networks, address structure, the
  build -> validate -> preview -> sign -> submit lifecycle.
- radix_manifest_instructions — list every manifest instruction with a summary.
- radix_manifest_instruction — one instruction in depth (syntax, args, examples).
- radix_manifest_templates — ready-made templates (transfer, stake, unstake,
  claim, mint, burn, swap) plus the placeholder convention.
- radix_manifest_template — one template body with {PLACEHOLDER} slots.

## Ecosystem discovery

- radix_list_ecosystem_services — directory of other agent-facing Radix services
  (e.g. DEX-aggregator MCP servers) for capabilities this server does not cover,
  such as resolving a token swap. Each entry lists the networks it supports;
  optionally filter by category and/or network. Informational only — a listing
  is not an endorsement. Also exposed as radix://ecosystem/* resources.

## Resources

- radix://manifest/workflow, radix://manifest/instructions,
  radix://manifest/instruction/{name}, radix://manifest/templates,
  radix://manifest/template/{name}
- radix://ecosystem/services, radix://ecosystem/service/{slug}

## Signing (later phase, non-custodial)

- radix_request_signature — returns a Radix Connect deep link / QR; the human
  signs in the Radix Wallet; the agent polls status. Keys never reach the agent.
- radix_authenticate — ROLA challenge/verify (off-ledger proof of ownership),
  no transaction required.

## Source

- RadixScan: https://radixscan.io