Generate unsigned vault deposit calldata for a host wallet to sign and broadcast; API keys alone cannot move funds.
Prepare unsigned vault deposit steps. Returns calldata only — the host must sign/broadcast with a wallet private key. API key alone cannot move funds.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Human-readable amount | |
| symbol | Yes | Deposit symbol (ETH or allowlisted ERC-20) |
Changes observed during successful MCP inspections.
v0.1.16Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does well: it discloses that only calldata is returned, that signing/broadcasting is the caller's responsibility, and that an API key alone cannot move funds — a key safety boundary. It leaves out failure modes, validation behavior, and whether any server-side state is created, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero filler, with the core action front-loaded and the critical signing caveat immediately after. Every sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description usefully covers both what is produced (calldata) and the required follow-up (external signing), which is the essential context for a prepare-type tool. It is only slightly thin on preconditions such as authentication requirements or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (symbol, amount) are already documented in the schema, including the ETH/allowlisted-ERC-20 constraint. The description adds no format or constraint detail beyond that, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Prepare unsigned vault deposit steps.' Combined with 'Returns calldata only,' an agent immediately knows this builds a deposit transaction rather than executing one. It does not explicitly contrast with the sibling aureon_prepare_vault_withdraw, but the deposit framing makes the distinction reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its place in a workflow ('the host must sign/broadcast with a wallet private key'), which tells the agent this is a pre-signing step. However, it never states when to use this versus alternatives like aureon_prepare_vault_withdraw, nor any prerequisite conditions beyond the signing note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.