Skip to main content
Glama

wallet_quick

Read-onlyIdempotent

Use this for a cheap copy-trade screen before paying for a full profile. Cheap copy-trade screen for one wallet: windowed realized PnL, win rate, closed trades, last active time, bot, exchange, net-winner and dormant flags, plus copyTradeScore and copyTradeGrade (copy-return after a 3s delay and a 3.6% round trip, win rate, sample-size shrinkage, bot and insider penalties). Free teaser at /wallet/preview; full report at /wallet/profile. Costs $0.003 USDC (3000 base units) via x402. The same price is charged for HTTP GET /wallet/quick. An unpaid HTTP call returns 402 even when the query is missing or invalid. A signed call with invalid arguments is rejected before settlement and is not charged. A successful result can set cached, stale, and cacheAgeMs. stale true means a previous result was served while a refresh runs or the upstream failed. You are charged only when the tool result is not an error.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "wallet_quick"
  }
}

Input Schema

NameRequiredDescriptionDefault
addressYesSolana wallet address in base58 (32 to 44 characters). Example: HD1ryR3dYSXBVNGfJZydbpmnChiE1wrAQkupWWtHt4pM

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / address / description
      Previous value: -"Solana wallet address"New value: +"Solana wallet address in base58 (32 to 44 characters). Example: HD1ryR3dYSXBVNGfJZydbpmnChiE1wrAQkupWWtHt4pM"
  2. Added
  3. Removed
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds substantial context beyond them: the $0.003 USDC x402 price, that unpaid HTTP calls return 402 even for invalid queries, that signed calls with invalid arguments are rejected pre-settlement and not charged, and that billing only occurs on non-error results. It also discloses the cached/stale/cacheAgeMs result fields and what stale=true means, which is exactly the kind of operational nuance annotations cannot express.

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 usage directive and the one-line purpose, then billing and caching rules. Nearly every sentence carries decision-relevant information, though the parenthetical breakdown of copyTradeScore internals (3s delay, 3.6% round trip, shrinkage, penalties) is denser than an agent needs to select and call the tool.

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?

No output schema exists, and the description compensates by enumerating the returned metrics and flags, plus explaining the cached/stale/cacheAgeMs fields. With one fully documented parameter and a clear cost model, an agent has everything needed to invoke it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter has 100% schema coverage, including base58 format, length bounds, and a concrete example, so the schema already carries the semantics. The description adds nothing parameter-specific beyond the implicit requirement for one wallet address; baseline 3 is appropriate when the schema does the heavy lifting.

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+resource ('cheap copy-trade screen for one wallet') and enumerates exactly what it returns: windowed realized PnL, win rate, closed trades, last active, bot/exchange/net-winner/dormant flags, plus copyTradeScore and copyTradeGrade. It also explicitly positions itself against siblings by naming the free teaser (/wallet/preview) and the full report (/wallet/profile), so an agent can distinguish it from wallet_preview and wallet_profile without opening schemas.

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?

Opens with the selection rule: 'Use this for a cheap copy-trade screen before paying for a full profile.' That gives both the when-to-use condition and the alternative (full profile), reinforced by naming /wallet/preview as the free tier and /wallet/profile as the paid full report.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources