Skip to main content
Glama
Sign In
Preflight

Preflight

by dainidude
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

preflight_sim

Simulate a smart-contract transaction to get revert reasons, gas used, balance deltas, and severity-scored findings before executing it.

Instructions

Simulate a transaction against a contract and return revert reason, gas used, balance deltas, and severity-scored findings. mode='quick' costs $0.05 (eth_call); mode='deep' costs $0.25 (anvil local fork with gas, balance_delta_wei, and internal_calls). Paid in USDC on Base mainnet via x402; DEV_MODE=1 skips payment.

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": {
      "to": "<to>"
    },
    "name": "preflight_sim"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYes
dataNo
modeNoquick
value_weiNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses the payment rail (USDC on Base mainnet via x402), per-mode cost, and the DEV_MODE=1 bypass, plus what each mode executes under the hood. It stops short of stating explicitly that no on-chain state is mutated, and says nothing about rate limits or failure behavior.

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?

Two dense sentences with no filler; the capabrequired output list is front-loaded before the cost/auth detail. It is information-rich but somewhat compressed—mixing mode mechanics, pricing, and payment rails into one stream.

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?

For a paid simulation tool with a declared output schema, the definition covers what an agent needs before calling: cost per path, payment method, the dev bypass, and the depth difference between modes. Undocumented call-shape parameters are the only real hole, and the output contract is already structured elsewhere.

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 0%, so the description must compensate and only partly does. 'mode' is given real semantics ('quick' vs 'deep') with cost and output differences, but 'to' (the sole required param), 'data', and 'value_wei' are never explained beyond what the surrounding sentence implies about contracts and transactions.

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?

Opens with a specific verb+resource ('Simulate a transaction against a contract') and enumerates what comes back (revert reason, gas used, balance deltas, severity-scored findings). It is clearly distinguishable in kind from pricing/token-risk siblings, though it never names preflight_check to draw the boundary with the closest-looking tool.

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 two modes carry implicit selection guidance: quick is an eth_call for $0.05, deep is an anvil local fork for $0.25 with gas, balance_delta_wei and internal_calls. That helps pick a mode, but the framing is pricing-led rather than decision-led, and there is no statement of when to use this tool instead of preflight_check or the other siblings.

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