Skip to main content
Glama

portal_get_wallet_summary

Summarizes wallet activity and fund flow across networks, showing inbound/outbound movements, top counterparties, and evidence pivots for quick investigation.

Instructions

Summarize wallet activity and fund flow with shared overview, asset movement, counterparties, evidence pivots, and follow-up filters across supported networks.

COMMON USER ASKS:

  • EVM wallet fund-flow triage

  • Solana wallet activity and fee flow

FIRST CHOICE FOR:

  • one-call wallet analysis across supported VMs

  • suspicious wallet triage, fund-flow direction, counterparties, and next evidence pivots before drilling into raw records

WHEN TO USE:

  • You want a single high-level answer about what one wallet has been doing and where value appears to move.

  • You want inbound/outbound flow, top counterparties, largest movements, and exact next pivots before drilling into raw transactions or fills.

  • The user asks to investigate a suspicious wallet, stolen-funds path, exploit counterparty, or incident address.

DON'T USE:

  • You need every raw record with full chain-specific fields and no summarization.

EXAMPLES:

  • EVM wallet fund-flow triage: {"network":"base-mainnet","address":"0xabc...","timeframe":"24h"}

  • Solana wallet activity and fee flow: {"network":"solana-mainnet","address":"Vote111...","timeframe":"6h"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoExecution depth. Defaults to complete requested-window analysis; the optional fast value is only for explicitly bounded previews.deep
cursorNoContinuation cursor from a previous response
addressNoWallet address to analyze. Optional when continuing with cursor.
networkNoNetwork name or alias. Optional when continuing with cursor.
timeframeNoLook-back period as timeframe or block count. Examples: '1h', '24h', '7d', '3d', '1000'.1000
include_nftsNoInclude NFT transfers (ERC721/1155)
to_timestampNoEnding timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
from_timestampNoStarting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
include_tokensNoInclude ERC20 token transfers
limit_per_typeNoMax items per category (txs, tokens, nfts)
response_formatNoResponse format: defaults to 'compact' for a readable wallet investigation. Use 'summary' for headline flow only or 'full' for all returned activity rows.
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool produces a summary with shared overview, asset movement, counterparties, and evidence pivots. However, it does not mention pagination or rate limits, which would enhance transparency for a tool with 11 parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES). Every sentence provides value without redundancy, and the formatting aids readability.

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?

Given the tool's complexity (11 parameters, no output schema), the description provides adequate context about purpose, usage, and examples. It mentions key output components (counterparties, evidence pivots), but lacks detail on return format or error handling, which would improve completeness.

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 description coverage is 100%, so the description adds marginal value beyond the schema. The examples illustrate parameter usage, but the schema already documents each parameter well. Baseline 3 is appropriate.

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?

The description clearly states the tool summarizes wallet activity and fund flow, and distinguishes itself from sibling tools that focus on raw records or specific chain queries. The 'FIRST CHOICE FOR' and 'DON'T USE' sections further clarify its unique role.

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?

Explicit 'WHEN TO USE' and 'DON'T USE' sections provide clear guidance on appropriate scenarios, such as suspicious wallet triage, and explicitly state when to avoid (need for raw records). Examples further reinforce correct usage.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/subsquid-labs/portal-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server