AgentTrust

Overview Schema Source Related Servers Discussions Admin

Create Agent Wallet

create_agent_wallet

Generate a new XRPL keypair to create a disposable wallet for development or demos, returning the seed in plaintext. Fund the address with at least 1 XRP to activate it before use.

Instructions

Convenience tool: generate a new XRPL keypair and return the seed.

⚠ NOT RECOMMENDED FOR PRODUCTION. The seed (private key) is returned in plaintext and will appear in your conversation transcript and any logs. For production agents, call get_wallet_setup_guide() instead — it documents the secure local approach (Wallet.generate() + seed in .env) where the seed never leaves your environment.

Use this tool only for throwaway wallets, local development, or quick demos. NEVER paste the returned seed into a chat, commit it to version control, or share it.

The wallet is NOT yet active on the ledger — fund it before use. XRPL requires 1 XRP minimum to activate a wallet (base reserve). Until funded:

You cannot sign or submit transactions
You cannot be the destination of an EscrowCreate (buyer's tx will fail)
Your trust score will show as 0 / "not found"

Funding options:

Call fund_xrpl_wallet_via_coinbase(address, usd_amount=5.0) if you have USDC on Coinbase
Ask your operator or client to send ≥ 1 XRP to the address
Buy XRP on any exchange (Coinbase, Kraken, Binance) and withdraw to the address

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and succeeds: it discloses plaintext seed exposure, transcript/log persistence, ledger-inactive status, inability to sign/submit transactions, EscrowCreate destination failure, trust score showing 0, and funding requirements. This is far beyond what the empty schema provides.

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?

The description is long, but its length is largely justified by critical security warnings and activation constraints that would otherwise be absent. It is front-loaded with the core purpose and warning, uses bullets for scanability, and while some warning redundancy exists, it does not significantly hinder clarity.

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 zero-input tool with an output schema, the description is exceptionally complete: it covers production alternatives, safe use cases, funding options, ledger activation constraints, and downstream limitations. An agent has enough context to call it correctly and to explain the risks to a user.

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?

The tool has zero parameters and an empty input schema, so there is no parameter semantic gap to fill. The description still adds useful meaning about what is returned (the seed) and the security consequences, matching the zero-param baseline.

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 opens with a specific verb+resource: 'generate a new XRPL keypair and return the seed.' It also clarifies what the tool does NOT do (it does not create an active ledger wallet), which distinguishes it from related wallet tools and removes ambiguity.

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

Usage Guidelines5/5

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

It explicitly says when NOT to use the tool (production), names the exact alternative (get_wallet_setup_guide), and scopes appropriate use to throwaway wallets, local development, or demos. It also gives concrete post-call guidance on funding the wallet, including a named sibling tool, fund_xrpl_wallet_via_coinbase.

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