Strong foundation with consistent naming conventions, comprehensive parameter schemas, and clear descriptions for most tools. The server demonstrates good adherence to agentic tool patterns with explicit risk markers (READ_ONLY vs IRREVERSIBLE) and sensible tool composition. However, output schemas are largely undocumented in the source, and several tools lack depth in parameter descriptions. The codebase uses rust-mcp-sdk with proper JsonSchema derivation, but actual response structures are not visible in the provided sample. Error handling patterns are present but recovery guidance is minimal.
[IRREVERSIBLE] Approve a delegate to spend tokens from your token account. Required for DEX and lending protocol interactions. The delegate can transfer up to the approved amount. Revoke with revoke_token when no longer needed.
[IRREVERSIBLE] Close a token account and recover remaining SOL rent deposit. Account must have zero balance.
[IRREVERSIBLE] Create an Associated Token Account (ATA) for a specific token and owner. Required before transferring tokens to a new address.
Get detailed information about a Solana account including owner, lamports, executable status, and data
Get the SOL balance of a wallet address
Get information for multiple Solana accounts in a single request
Output schemas are not documented in the source code. While input parameters are properly schematized via JsonSchema derives, the CallToolResult return types are not visible, only the tools' input interfaces are clear.
Descriptions for read-only tools (get_balance, get_account_info, get_slot, get_program_accounts) lack context on WHEN to use them vs similar tools and WHY the user would call them. For example, 'Get the SOL balance' does not explain whether to call get_balance or get_account_info for SOL balance queries.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | <=2025-11-25 | v2 |
Get all accounts owned by a specific Solana program
Get MCP server configuration and capabilities. Returns network info, write capability, and wallet address if configured. Use this to discover what network you're on and whether write operations are available.
Get the confirmation status of a transaction by signature
Get transaction signatures for a specific address
Get the current slot number on the Solana network
Get all token accounts owned by a wallet address
Get detailed information about a Solana transaction by signature
Inspect a transaction in human-readable format with decoded instructions
Inspect a transaction in raw format with instruction details
Query transaction history for an address with filtering and sorting options
[IRREVERSIBLE] Revoke all delegate approvals on a token account. Use this to remove spending permissions granted with approve_token.
Simulate a transaction without submitting it to the network
[IRREVERSIBLE] Transfer SOL from your wallet to another address. Actual funds will be transferred immediately.
[IRREVERSIBLE] Transfer tokens from your token account to another token account. Actual tokens will be transferred immediately.
Pagination is not explicitly documented. Tools like get_token_accounts_by_owner, get_program_accounts, get_signatures_for_address accept a 'limit' parameter but do not document whether results are paginated, whether a next_cursor is returned, or how to iterate large result sets.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present in the tool definitions. While risk metadata is provided inline (READ_ONLY vs IRREVERSIBLE), structured tool annotations would improve client-side safety guardrails and prevent accidental misuse.
Error handling and recovery guidance are minimal. For example, if transfer_sol fails, there is no documented next action (check balance? retry? contact support?). Error responses should include category (retryable vs user-fixable) and actionable guidance.