Skip to main content
Glama

未署名トランザクションを組み立てる

prepare_unsigned_transaction
Read-only

Builds an unsigned EIP-1559 transaction with nonce, gas estimate, and fees already included, so you can safely review and sign it in MetaMask or a hardware wallet without exposing private keys.

Instructions

nonce・ガス見積もり・手数料を埋めた EIP-1559 形式のトランザクションを組み立てて返す。【重要】このサーバは署名も送信もしない。返るのは人間が MetaMask やハードウェアウォレットで内容を確認してから署名するための JSON。LLM に鍵を渡さないという境界を、実際に動く形で示すためのツール。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYes宛先アドレス
argsNo関数の引数
fromYes送信元アドレス(nonce とガス見積もりに使うだけで、鍵は不要)
networkNo対象ネットワーク。mainnet / sepolia / holesky / local か http(s) の URL。既定は mainnet
signatureNo呼び出す関数の署名。例: "transfer(address,uint256)"
value_ethNo送金額を ETH 単位の文字列で。既定は "0"
Behavior5/5

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

readOnlyHint=trueとdestructiveHint=falseのアノテーションと整合し、説明では「署名も送信もしない」と明記。さらに「LLMに鍵を渡さないという境界」という重要な設計意図が追加されており、単に安全操作であるだけでなく、その目的まで伝わる。これはアノテーション以上の価値を提供している。

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?

2文で構成され、最初の文でツールの機能を明確に述べ、2文目で重要な注意点と目的を説明している。冗長な情報は一切なく、必要な情報が効率的に配置されている。

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?

出力スキーマがないため、返り値の詳細は説明されていないが、説明に「人間がMetaMaskやハードウェアウォレットで内容を確認してから署名するためのJSON」とあり、利用目的が明確で出力の概要は伝わる。パラメータも6つで複雑さは中程度であり、説明が十分に補完している。ただし、完全な出力形式の例があればさらに良かった。

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

Parameters5/5

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

パラメータのスキーマ説明は100%網羅されているが、説明はそれを超える情報を加えている。特に「from」アドレスがnonceとガス見積もりにのみ使用され鍵が不要、という重要なセマンティクスが説明文に含まれており、スキーマだけでは得られない情報がある。さらに「value_eth」の既定値や「network」の既定値などもスキーマにない補足がある(ただしスキーマにも既定値はある)。

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?

説明には具体的な動詞(組み立てて返す)、具体的なリソース(EIP-1559形式のトランザクション)、そして結果が人間の確認用JSONであることが明記されている。さらに送信/署名しないと明確な境界が述べられており、read系の兄弟ツールとの差別化にもつながっている。

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?

「署名も送信もしない」という明示的な使用制限があり、返り値が人間の確認用であると書かれている。ただし、いつ使うべきかに関する明確な指示や、代わりに使うべきツール(例: 署名が必要な場合は別のツール)への言及はない。

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/nakamura196/chain-reader-mcp'

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