Skip to main content
Glama
Sign In

chaink9

by com.chaink9
OverviewDiscussionsAdmin

transaction-preview

Read-only

Execute an EOA transaction on a disposable fork of BNB Smart Chain, Ethereum, Base or Arc. Supply target, calldata, optional native-coin value and up to ten ERC-20 assets to track. Returns receipt status, native-coin balance delta including gas, requested token deltas and direct approve allowance reads when available. Other assets, internal approvals and signatures are not inventoried; nothing is broadcast live. Costs $0.02 per successful call in USDC on Base, Polygon, Arbitrum, Avalanche, BNB Smart Chain (USDT) or Solana, paid with x402 in the call's _meta; failed calls are free.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "wallet": "<wallet>",
      "to": "<to>",
      "data": "<data>"
    },
    "name": "transaction-preview"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesTransaction target
gasNoOptional gas limit, 21000 to 3000000
dataYesTransaction calldata, 0x for native transfer
chainNobsc (BNB Smart Chain, the default), eth (Ethereum) or base (Base)
valueNoNative coin wei (BNB or ETH), default zero
tokensNoOptional comma-separated ERC-20 assets to track, maximum ten
walletYesSending EOA

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses that execution happens on a disposable fork, nothing is broadcast live, and the response includes receipt status plus balance deltas. It also bounds the behavior honestly ('Other assets, internal approvals and signatures are not inventoried') and states the pricing model ($0.02 per successful call via x402 in _meta, failed calls free). 'Execute' alongside readOnlyHint is not a contradiction because fork-only, no-broadcast is stated explicitly.

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

Conciseness4/5

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

Behavior is front-loaded (what runs, where, that nothing is broadcast) before the return values and pricing. Sentences are dense but each carries distinct information; the pricing sentence is long and lists six payment chains, which is the only place the prose could be tightened.

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

Completeness5/5

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

With no output schema, the description carries return-value duty and does so: receipt status, native delta including gas, requested token deltas, and approve allowance reads where available. It also covers cost, supported chains, and explicit coverage limits, leaving nothing material an agent needs before calling.

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 the schema already documents every field including the chain enum and the 'maximum ten' token limit. The description's paraphrase ('target, calldata, optional native-coin value and up to ten ERC-20 assets') adds no format, ordering, or interpretation detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('Execute an EOA transaction') plus the execution context ('disposable fork'), and enumerates the supported chains (BNB Smart Chain, Ethereum, Base, Arc). It does not name a sibling tool or explicitly contrast itself with simulate-trade or scan, which keeps it short of a 5.

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 by telling the agent what to supply (target, calldata, optional value, up to ten ERC-20 assets to track), which sketches the calling scenario. It never states when to prefer this over simulate-trade, scan, or trace, nor any prerequisite for obtaining calldata, so guidance is implied rather than explicit.

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

All chaink9 toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources