The server provides 12 tools with basic schema definitions and descriptions. However, critical gaps limit production readiness: (1) Naming violates single-responsibility principle, stellar_create_claimable_balance and stellar_claim_claimable_balance mix two distinct operations; (2) Many parameter descriptions are minimal (under 50 chars) and lack actionable constraints; (3) Output schemas are entirely undocumented, LLMs cannot infer what fields to expect from responses; (4) Error handling is generic ('Error: ' prefix only), providing no recovery guidance; (5) Secret key parameters appear in tool signatures (stellar_payment, stellar_create_asset, etc.), violating secret-injection pattern; (6) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear read vs. write distinction; (7) Missing enum constraints on network parameter (soroban_deploy); (8) No pagination or result limit documentation despite tools that may return multiple items (stellar_transactions). These are foundational gaps that prevent confident LLM usage.
Tools (12)
soroban_build_and_optimizeread only50/100
Build and optimize a Soroban smart contract
soroban_deploywriteauth50/100
Deploy a Soroban smart contract to the Stellar network
soroban_retrieve_contract_methodsread only50/100
Retrieve the methods and interface of a deployed Soroban smart contract
stellar_balanceread only50/100
Get the balance of a Stellar account
stellar_change_trustwriteauth50/100
Create or modify a trustline for an asset on the Stellar network
stellar_claim_claimable_balancewriteauth50/100
Claim a claimable balance on the Stellar network
stellar_create_accountread only50/100
Create a new Stellar account with a random keypair
Secret keys exposed as tool parameters (stellar_payment, stellar_create_asset, stellar_change_trust, stellar_fund_account, stellar_create_claimable_balance, stellar_claim_claimable_balance, soroban_deploy). This violates the secret-injection pattern, credentials in parameters are logged in agent traces and prompt history, creating a security liability.
Output schemas completely undocumented. No tool returns field definitions or example response structures. LLMs cannot predict what data they will receive, making multi-step tool chaining unreliable and forcing speculative retry logic.
Inject secret keys server-side via environment variables (e.g., STELLAR_SIGNER_KEY) and remove them from tool parameters entirely. Use a 'signerAlias' or 'accountName' parameter instead to let users specify which pre-configured account to use.
Document the complete output schema for every tool. Example for stellar_balance: '{"balance": string (numeric XLM amount), "account": string (public key), "subentries": number, "native_balance": string}'. Include field types, descriptions, and whether fields are always present.
Add tool annotations to tool definitions: stellar_balance, stellar_transactions, stellar_create_account, soroban_build_and_optimize, soroban_retrieve_contract_methods should set readOnlyHint=true; stellar_payment, stellar_create_asset, stellar_change_trust, stellar_fund_account, stellar_create_claimable_balance, stellar_claim_claimable_balance, soroban_deploy should set destructiveHint=true.
Expand parameter descriptions with format and constraint details. Example for stellar_payment's secretKey: 'Stellar secret key (starts with S, 56 Base32-encoded characters) of the sending account. Must have sufficient balance to cover amount + network fee (0.00001 XLM).'
Enhance error handling with actionable recovery hints. Catch predictable errors (insufficient balance, account not found, invalid asset code) and return guidance: 'Insufficient XLM balance (have 1.5, need 2.5 including fee). Fund the account with stellar_fund_account or stellar_payment first.'
Add pagination support to stellar_transactions with limit (1-200, default=20) and cursor parameters. Return a response structure with total_count and next_cursor for multi-page iteration.
Score history
Overall score trend
↑ 31 points across a rubric change (v1 → v2)
45/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
45
2026-07-28+
v2
2026-03-09
F
14
-
v1
stellar_create_claimable_balancewriteauth50/100
Create a claimable balance on the Stellar network
stellar_fund_accountwrite50/100
Fund a new Stellar account using the testnet faucet
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server explicitly declares Risk fields in the spec (READ_ONLY vs WRITE) but does not translate these into actual MCP tool annotations. Agents cannot determine which tools are safe to retry or will modify state.
Parameter descriptions lack actionable constraints and format specifications. Examples: 'Secret key of the account' does not explain the expected format (Stellar private key format? Base64? Raw hex?). 'Amount to send' omits min/max bounds and units (XLM? Stroop units?). These gaps force LLMs to guess or fail validation.
Error handling is minimal and non-actionable. The catch block in index.ts returns only 'Error: {error.message}' with no guidance on recovery, retry eligibility, or next steps. A missing account error should suggest 'Use stellar_fund_account' or 'Call stellar_create_account first.' instead of a bare error string.
Missing environment variable validation and clear error messages. If STELLAR_SERVER_URL is not set, the server throws a generic error instead of documenting the required environment setup. Production deployments will fail silently.
No pagination or result limits documented for tools that may return multiple items. stellar_transactions, soroban_retrieve_contract_methods, and any listing operations should declare max result count and offer pagination (limit, offset/cursor parameters). Unconstrained results can exhaust LLM context windows.
soroban_deploy missing enum constraint on network parameter. The parameter accepts a string but does not enforce the valid values (testnet, public, futurenet). LLMs may pass arbitrary network names, causing API failures instead of validation errors.
Parameter descriptions are too brief (under 50 characters) for most tools. Baseline for A-grade tools is 70+ chars per parameter. Examples: 'Public key of the account to query' (42 chars) lacks format details; 'Amount to send' (13 chars) omits units and bounds. Short descriptions leave LLMs guessing about expected values.
No confirmation or dry-run support for destructive operations. Tools like stellar_payment, stellar_create_asset, and soroban_deploy modify ledger state irreversibly. These should support a confirm_before_execute pattern or dry-run capability to prevent accidental financial losses.
Add enum constraint for soroban_deploy network parameter: {"enum": ["testnet", "public", "futurenet"]} with description 'Network to deploy to. Use testnet for development/testing, public for production, futurenet for beta features.'
Document all complex parameter structures with example values. For stellar_create_claimable_balance's claimants array, show: '[{"destination": "GBUQWP3BOUZX34ULNQG23RQ6F4PFXGVPLMAV2QBD45L2312KUHG4DNO", "predicate": {}}]'.
Implement confirmation for destructive operations. Add a 'confirm' boolean parameter (default=false) to stellar_payment, stellar_create_asset, soroban_deploy. When false, return a preview (amount, destination, fee estimate) instead of executing.
Validate input early and return structured error messages. Example: 'Invalid asset code for stellar_change_trust: got "USDCCC" (12 chars). Asset codes must be 1-12 alphanumeric characters.' Include the constraint that was violated.
Add timeout handling to external API calls (Horizon, Soroban RPC). Set explicit limits (e.g., 30s) and return 'Request timed out after 30s. The Stellar network may be congested. Retry in a few moments.' instead of hanging.
Document mutual exclusivity and parameter dependencies. Example: stellar_create_claimable_balance's asset parameter is optional (defaults to native XLM), but if provided, both code and issuer are required.
Consider batch variants for tools agents call in loops. Offer stellar_payment_batch accepting an array of {destination, amount, asset} objects to reduce token overhead and improve latency for multi-payment scenarios.
Add per-tool descriptions explaining WHEN to use each tool vs. similar alternatives. Example: 'Use stellar_fund_account to top up a testnet account for development. For production, use stellar_payment to send XLM from an existing account.' This prevents LLM confusion.
Ensure all tools return consistent reference IDs for chaining. If stellar_payment returns a transaction_id, stellar_transactions should accept it to retrieve details. If soroban_deploy returns a contract_id, soroban_retrieve_contract_methods must accept it.