Skip to main content
Glama
Sign In
Agent Kiosk

Agent Kiosk

by ralf9090
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

evm_tx_simulator

Read-onlyIdempotent

Simulate EVM transactions before signing to estimate gas, decode revert reasons, check ERC-20 allowances, and detect EIP-1967 proxies across Base, Ethereum, Arbitrum, Optimism, and Polygon.

Instructions

Pre-flight EVM Transaction Simulator, Gas Estimator, Revert Reason Decoder, ERC-20 Allowance Checker & EIP-1967 Proxy Detector ($0.005 USDC). Simulates any transaction via eth_call & eth_estimateGas across Base, Ethereum, Arbitrum, Optimism, and Polygon before signing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "evm_tx_simulator"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNo0x target smart contract or recipient address
dataNo0x hex calldata to simulate (default: '0x18160ddd')
fromNo0x sender wallet address
chainNoTarget EVM blockchain (default: 'base')
tokenNoOptional 0x ERC-20 token address to verify allowance
valueNoOptional native ETH value in wei or 0x hex
spenderNoOptional 0x spender contract address to verify ERC-20 allowance
tx_hashNoOptional 0x transaction hash to decode receipt

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.6.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds real value beyond that: it discloses the underlying read-only RPC mechanism (eth_call / eth_estimateGas), the supported chains, and a concrete per-call cost of $0.005 USDC. It omits rate limits, auth requirements, and return shape, so not a 5.

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

Conciseness3/5

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

Only two sentences and the purpose is front-loaded, which is good, but the first sentence is a run-on list of five advertised capabilities plus a price tag that reads as marketing copy. It earns its place for discoverability yet is less economical than a clean single-purpose statement.

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?

For an 8-parameter read-only tool with no output schema, the description covers the mechanism, supported chains, cost, and the multi-function surface (simulate, gas estimate, revert decode, allowance check, proxy detect). An agent has enough to call it correctly; the only gap is that no return-value expectations are set.

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 description coverage is 100%, so every one of the 8 parameters is already documented in the schema with format and defaults. The description adds no parameter-level syntax or semantics beyond that, making the baseline 3 correct.

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

Purpose4/5

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

The second sentence gives a concrete verb+resource: 'Simulates any transaction via eth_call & eth_estimateGas' before signing. The opening keyword-stuffed list (Simulator, Gas Estimator, Revert Decoder, Allowance Checker, Proxy Detector) muddles rather than sharpens the single core purpose, but the tool is still clearly distinguishable from siblings like defi_swap_quote or security_audit.

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 phrase 'before signing' implies the usage context (pre-flight validation of a pending tx), but there is no explicit when-to-use vs when-not guidance and no named alternative tools. Usage must be inferred from the purpose statement.

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

Deploy Server

Other Tools