Skip to main content
Glama
Sign In
solanaprox-mcp

solanaprox-mcp

by solanaprox
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

deposit_info

Show where and how to deposit USDC on Solana, including the address, account, 0.10 USDC minimum, and no-withdrawal rule; optionally create an exact one-hour deposit intent for exchange users.

Instructions

Show where and how to deposit: the address, the USDC account and the rules (USDC on Solana only, a 0.10 USDC minimum, no withdrawals). Free, and this tool never sends funds: the user sends them from their own wallet or exchange. With amount_usd, it also creates a deposit intent for exchange users (POST /v1/deposit/intent): a unique exact amount valid for 1 hour. Exchange fees can change the amount. The amount that ARRIVES must match to the last digit. If your exchange takes its fee out of the amount you enter, add that fee so this exact amount arrives. Other amounts are not credited automatically: contact support@solanaprox.com with your withdrawal record.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "deposit_info"
  }
}

Input Schema

NameRequiredDescriptionDefault
amount_usdNoOnly for deposits from an exchange: the rough amount in USD, 0.10 to 10,000. Returns the exact amount to send. Without a configured token, this also creates a new account and shows its token once.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full load and does it well: read-only info by default, but with amount_usd it creates a deposit intent (a side effect), the intent amount is unique and valid for 1 hour, exchange fees can alter what arrives, mismatched amounts are not auto-credited, and there is an escalation path via support email. That is exactly the behavioral context an agent needs before calling.

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?

Front-loaded with the purpose, then the conditional behavior, then the failure path, so an agent can stop reading early. The single dense paragraph packs several warnings (fees, exact arrival, support contact) without breaks, which makes it slightly harder to scan than it could be.

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?

One optional parameter, no annotations and no output schema, so the description must explain both behavior and results, and it does: it says what is returned (address, account, rules, exact amount, one-time token) and the constraints on crediting. Nothing an agent needs to call this correctly is absent.

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%, so the baseline is 3, but the description adds real meaning beyond the schema: why the amount must match exactly, that exchange fees must be grossed up, and the consequence of a mismatch. It complements rather than repeats the parameter's own text.

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?

States a specific verb and resource: show where and how to deposit, naming the address, the USDC account and the rules. It is unmistakably distinct from generic siblings like ask_ai or check_balance, and it clarifies that the tool itself never moves funds.

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

Usage Guidelines4/5

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

Gives a clear conditional: plain call for deposit details, add amount_usd for exchange users to create a deposit intent. It also states the tool is not for withdrawals and sets a 0.10 USDC minimum. What's missing is an explicit pointer to an alternative tool when a caller actually wants balances or history, but the branch conditions it does state are precise.

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

Deploy Server

Other Tools