🐴 Gulltoppr

Prepare an unsigned transaction (hand-off)

prepare_tx

Prepare a contract WRITE for the user to sign. Returns an UNSIGNED transaction, its simulation, a human-readable summary, safety metadata, warnings, a configured signing deeplink, and an EIP-1193 wallet request when signing is recommended. IMPORTANT: this tool NEVER signs or broadcasts. Present the summary + simulation + warnings to the user. Only hand them the deeplink or wallet_request when safety.signing_recommended is true. If safety.risk_level is high or blocked, make that explicit; blocked means do not send.

Input Schema

TableJSON Schema

Name	Required	Description
`args`	No	Function arguments, in order. Pass uint values as decimal strings.
`from`	Yes	The sender address (the user's wallet). No key is needed — nothing is signed.
`chain`	Yes	Chain alias from GET /v1/chains (for example "ethereum", "base", "monad", "bsc") or numeric EIP-155 chain id.
`value`	No	Native value in wei (decimal string), for payable functions.
`address`	Yes	0x contract address.
`rpc_url`	No	Override HTTP(S) RPC URL. Required for chains with no default (e.g. local/31337) or custom EVM chain ids.
`function`	Yes	Function name, or full signature like "transfer(address,uint256)" if overloaded.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`safety`	Yes
`deeplink`	Yes
`warnings`	Yes
`simulation`	Yes
`unsigned_tx`	Yes
`human_summary`	Yes
`wallet_request`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=false (write-prep), openWorldHint=true, destructiveHint=false. The description adds key behavioral traits: never signs/broadcasts, returns safety metadata with risk levels, and warns about blocked/high risk. No contradiction with annotations.

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

Conciseness5/5

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

Description is a single paragraph, front-loaded with key purpose and components. Every sentence adds value: never signs, returns list, safety guidelines. No fluff.

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?

Given 7 parameters, full schema coverage, output schema present, and annotations, the description covers all essential context: what the tool does, what it returns, safety metadata and risk handling. It is complete for an agent to select and use correctly.

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

Parameters4/5

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

Schema coverage is 100% with good descriptions. The description adds extra meaning: 'from' requires no key (nothing signed), 'args' requires uint as decimal strings, and 'chain' can be alias or numeric id. This goes beyond the schema's basic descriptions.

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 the tool prepares a contract write for signing, listing all returned components (unsigned tx, simulation, summary, etc.). It distinguishes from siblings like simulate (simulation of signed txs) and read_contract (reads).

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

Usage Guidelines4/5

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

Explicitly states 'NEVER signs or broadcasts' and provides conditional logic on when to use deeplink/wallet_request based on signing_recommended. It also instructs to present summary+simulation+warnings to user and to highlight high/blocked risk. It does not mention alternative tools for signing, but context is clear.

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

All 🐴 Gulltoppr tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: decode vs encode, prepare vs simulate, resolve ABI vs selector, etc. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., decode_tx, list_chains, resolve_abi, runtime_metrics). The only exception is 'simulate', which is a single verb but still clear and consistent with the style.

Tool Count5/5

12 tools is an ideal count for a blockchain interaction server. Each tool covers a necessary step in the workflow without being overwhelming or sparse.

Completeness5/5

The tool set covers the full lifecycle of contract interaction: resolve ABI, encode/decode, simulate, prepare unsigned transactions, look up selectors, resolve names, and list chains. No obvious gaps given the server's purpose of preparing actions for external signing.

Prepare an unsigned transaction (hand-off)

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources