Skip to main content
Glama

simulate_transaction

Simulate unsigned Xahau transactions by executing hook bytecode against live ledger state. Reports per-hook results, state writes, and scam score to predict outcomes before signing.

Instructions

THE PRE-SIGN FLIGHT SIMULATOR — predict what Xahau will do with an UNSIGNED transaction before you sign it. Every hook the tx would trigger (originator chain first, then strong/weak transactional stakeholders — order canonical from xahaud Transactor.cpp/applyHook.cpp) runs as REAL bytecode against LIVE ledger state in the local VM (measured 100% agreement on 30 real mainnet hook executions — all accept-direction; rollback direction proven separately on real genesis bytecode). Reports per-hook accept/rollback + return strings, simulated state writes, decoded emitted transactions, labeled STATIC engine preflights (sequence/balance/destination/expiry), an APPROXIMATE transactor prediction (the stand-in for Xahau's missing simulate RPC — predicted engine_result + balance/reserve/trustline deltas for Payment/TrustSet against live state, labeled APPROXIMATE; other tx types UNSUPPORTED), and a scam score. Never signs, never submits. Slow but thorough (iterative state resolution, ~1.1s per read).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
txYesunsigned transaction JSON (TransactionType, Account, ...)
networkNomainnet

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
notesNo
caveatNo
summaryNo
verdictNo
hookRunsNo
scamScoreNo
baseTxHashNo
historicalNo
transactorNo
ledgerIndexNo
staticChecksNo
overriddenFieldsNo
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden and fully discloses safe behavior ('Never signs, never submits'), performance limitations (~1.1s per read), approximate nature of predictions (only Payment/TrustSet supported), and scam score. This exceeds expectations for transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph with excessive technical detail (e.g., hook execution order, agreement percentages). It is not concise and could be better structured with bullet points or sections. Every sentence does not earn its place; some details are too granular for a tool description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (nested objects, output schema exists), the description covers main output areas (per-hook results, simulated state writes, predictions) and complements the output schema. However, missing usage guidelines and concise structure reduce completeness slightly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (one parameter has description). The description adds that tx must be 'unsigned' and lists typical fields (TransactionType, Account), but does not elaborate on structure beyond what the schema provides. It clarifies that other transaction types are unsupported for approximate predictions, adding moderate value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a pre-sign flight simulator that predicts Xahau's behavior with an unsigned transaction, explicitly distinguishing from signing/submitting and listing specific outputs. It differentiates from siblings like simulate_hook_trigger by its scope and approximation details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage before signing to predict outcome but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives (e.g., simulate_hook_trigger). No exclusions or tradeoffs are discussed beyond mentioning slowness.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hugegreencandle/xahau-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server