DeskCrew - AI Chatbot, Helpdesk & Knowledge base

wallet_check

Check a wallet before you pay, trade with or reward it: whether the address is on a public government sanctions list or on public scam and phishing address lists (named red flags), wallet or contract, outgoing transaction count, native coin and USDC balances, its NFT trading record, and what DeskCrew has seen of it (settled paid calls, human-approved answers, bounties won). Plain facts with the sources and their dates, notes for anything that could not be read. Never a score: no red flags found does not mean safe. Ethereum, Base, Polygon, Avalanche or Solana; cached ten minutes. [price: $0.01]

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_check"
  }
}

Input Schema

Name	Required	Description	Default
`chain`	No	ethereum, base, polygon, avalanche or solana. Defaults to ethereum for a 0x address or ens name and solana for a base58 address.
`address`	Yes	The wallet to check: a 0x address, a base58 Solana address, or an ens name.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A4.1/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 burden and does so well: it discloses data sources and their dates, per-item notes when something cannot be read, a ten-minute cache (staleness bound), the supported chains, and the cost ($0.01). The explicit 'Never a score: no red flags found does not mean safe' caveat is exactly the kind of interpretive guardrail annotations could not convey.

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?

It is one dense sentence, but it is front-loaded with the purpose and every clause (sources, dates, cache, price, no-score caveat) carries real information. The colon-delimited list is readable despite the length.

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 still conveys the shape of the response (plain facts with sources and dates, plus notes for unreadable items) and the cross-chain and caching behavior. The one real gap is that it does not position itself against the several NFT and bounty siblings whose data it partially duplicates.

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?

Schema coverage is 100% and the schema already documents the address formats and the per-chain defaulting rule, so the description adds little parameter-level detail. Listing the five chains repeats the enum rather than explaining anything new.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('check a wallet') and then enumerates exactly what is checked: sanctions lists, scam/phishing lists, tx count, native and USDC balances, NFT trading record, and DeskCrew activity. It is unambiguous what the tool returns, but it never names or rules out the overlapping sibling nft_wallet, so sibling differentiation is left implicit.

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?

It gives a clear use context — 'before you pay, trade with or reward it' — which tells the agent when to reach for it. It stops short of exclusions or naming alternatives such as nft_wallet or nft_flips, even though 'NFT trading record' overlaps visibly with those siblings.

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

All DeskCrew - AI Chatbot, Helpdesk & Knowledge base tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?