Skip to main content
Glama

prepare_marginfi_init

DestructiveIdempotent

Initialize a deterministic MarginfiAccount PDA under your wallet on MarginFi mainnet. This one-time setup enables subsequent supply, withdraw, borrow, and repay operations.

Instructions

One-time setup: build a tx that creates a deterministic MarginfiAccount PDA under the user's wallet on MarginFi mainnet. Uses marginfi_account_initialize_pda so only the wallet (authority + fee_payer) signs — no ephemeral keypair required, Ledger-compatible. PDA seeds are ["marginfi_account", group, wallet, accountIndex, 0], with accountIndex defaulting to 0. After broadcast, prepare_marginfi_supply / withdraw / borrow / repay for this wallet will use this MarginfiAccount automatically. COST: ~0.01698 SOL rent-exempt minimum (for the 2312-byte PDA) + ~0.000005 SOL tx fee. The rent is PAID FROM THE USER WALLET DIRECTLY (not via an ephemeral keypair) and is reclaimable when the MarginfiAccount is closed. Surface this cost to the user before they approve on Ledger — the blind-sign screen only shows a Message Hash, so the user has no on-device check of the balance delta. DURABLE NONCE REQUIRED: this tx carries ix[0] = nonceAdvance (same pattern as every other Solana send in this server), so the wallet must have run prepare_solana_nonce_init first; otherwise this tool errors with a clear pointer. BLIND-SIGN on Ledger (MarginFi's program ID is not in the Solana app's clear-sign registry) — the user matches the Message Hash on-device after preview_solana_send. Refuses if a MarginfiAccount already exists at the derived PDA.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletYesSolana wallet that will own the MarginfiAccount PDA. The account is deterministic — seeds (marginfi_account, group, authority, accountIndex, third_party_id=0) produce the same PDA every time. Only the user (authority + fee_payer) signs; no rent-exempt seed is moved (this is a PDA, not a fresh account).
accountIndexNoAccount slot (default 0). Pass a different index to init a second MarginfiAccount under the same wallet.
Behavior5/5

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

Beyond annotations (destructiveHint, idempotentHint), the description details cost (~0.01698 SOL rent + fee), that rent is paid from user wallet and reclaimable, durable nonce requirement, blind-sign on Ledger, and error condition for existing account. 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.

Conciseness4/5

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

The description is substantial but every sentence adds value. It is front-loaded with the core purpose. Could be slightly condensed, but it remains clear and well-structured without unnecessary verbosity.

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?

With no output schema, the description covers prerequisites, cost, error conditions, and after-effects. It implies the output is a transaction to be signed and sent. The context is sufficient for an agent to understand the tool's role and dependencies.

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 descriptions. The description adds semantic context: wallet is authority/fee_payer, PDA seeds are deterministic, accountIndex for multiple accounts. This reinforces schema but does not add entirely new information.

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 it is a one-time setup that builds a transaction to create a deterministic MarginfiAccount PDA under the user's wallet. It uses specific verbs ('build a tx that creates') and identifies the resource ('MarginfiAccount PDA'), distinguishing it from siblings like 'prepare_marginfi_supply' which depend on this init.

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?

The description specifies when to use (one-time setup before other marginfi actions), prerequisites (durable nonce from 'prepare_solana_nonce_init'), and behavior if not met (errors with pointer). It also warns about Ledger blind-sign and cost, and states it refuses if PDA already exists.

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/szhygulin/vaultpilot-mcp'

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