whale-wallet-trackerLarge USDC transfers on Base over the most recent blocks (default ~300), from confirmed Transfer logs: amount, sender, receiver, tx hash, block. Price: 0.0100 USDC per call (premium: always paid).
| Name | Required | Description | Default |
|---|---|---|---|
| windowBlocks | No | Blocks to scan, 25-600 (default 300, ~2s per block) | |
| minUsdcAmount | No | Minimum transfer size in USDC (min 1000, default 100000) |
Changes observed during successful MCP inspections.
Input schema / properties / minUsdcAmount / descriptionPrevious value: -"Minimum transfer size in USDC (default 100000)"New value: +"Minimum transfer size in USDC (min 1000, default 100000)"Input schema / properties / windowBlocksAdded value: +{
+ "description": "Blocks to scan, 25-600 (default 300, ~2s per block)",
+ "type": "number"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/openWorldHint, it discloses the data source (confirmed Transfer logs only, so unconfirmed mempool data is excluded) and the cost model (0.0100 USDC per call, always paid). The ~2s-per-block scan cost context comes from the schema, not the description, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the resource and scope, then the evidence source, returned fields, and price. Nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what the tool returns, its chain/asset scope, its data source, and its cost, which is enough for a zero-required-param read tool with no output schema. Minor omissions are rate/volume behavior and that only recent blocks are reachable, though the block cap lives in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters already document ranges and defaults, so the schema does the heavy lifting. The description only restates the default window of ~300 blocks and adds no interpretation of what 'large' or the amount threshold means in practice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: large USDC transfers on Base from confirmed Transfer logs, plus the fields returned. It implicitly separates itself from the generic contract-logs sibling via 'confirmed Transfer logs' and the USDC/Base constraint, but never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the content (whale monitoring on Base). There is no explicit when-to-use/when-not, no routing to alternatives such as contract-read or wallet-portfolio for other chain/asset views, and no prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.