Skip to main content
Glama

Agent Einstein — Crypto & Market Intelligence

Smart Money Flow

get_smart_money_flow
Read-onlyIdempotent

Where profitable on-chain wallets have been rotating capital recently, from the tracked smart-money cohort.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum rows to return (1-25).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoRow cap applied to every list in this payload.
staleNoTrue when the snapshot is past its refresh interval.
reasonNoWhy the payload is absent, when `available` is false.
availableNoFalse when this call has no data — a snapshot that is not warm yet, a domain switched off, or an argument that was rejected. NOT an error, and NOT a statement about the market.
fetchedAtNoWhen the underlying snapshot was refreshed (epoch ms or ISO-8601). Age matters: these are cached reads, not live queries.
overallSignalNoNet read across the transfers — accumulating, distributing or neutral.
smartMoneyMovesNoOne-line summaries of the same moves.
notableTransfersNoThe transfers behind the signal.
droppedRoutineCustodyNoTransfers dropped as routine custody movement rather than signal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / fetchedAt / description
      Previous value: -"When the underlying snapshot was refreshed (epoch ms, or ISO-8601 for the Bitcoin cycle feed). Age matters: these are cached reads, not live queries."New value: +"When the underlying snapshot was refreshed (epoch ms or ISO-8601). Age matters: these are cached reads, not live queries."
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "available": {
      +      "description": "False when this call has no data — a snapshot that is not warm yet, a domain switched off, or an argument that was rejected. NOT an error, and NOT a statement about the market.",
      +      "type": "boolean"
      +    },
      +    "droppedRoutineCustody": {
      +      "description": "Transfers dropped as routine custody movement rather than signal."
      +    },
      +    "fetchedAt": {
      +      "description": "When the underlying snapshot was refreshed (epoch ms, or ISO-8601 for the Bitcoin cycle feed). Age matters: these are cached reads, not live queries."
      +    },
      +    "limit": {
      +      "description": "Row cap applied to every list in this payload.",
      +      "type": "number"
      +    },
      +    "notableTransfers": {
      +      "description": "The transfers behind the signal.",
      +      "items": {
      +        "additionalProperties": true,
      +        "properties": {
      +          "amountUsd": {
      +            "description": "USD value."
      +          },
      +          "description": {
      +            "description": "Human-readable summary of the transfer."
      +          },
      +          "direction": {
      +            "description": "Direction of the flow."
      +          },
      +          "fromLabel": {
      +            "description": "Labelled sender, when known."
      +          },
      +          "signalClass": {
      +            "description": "How the transfer was classified."
      +          },
      +          "toLabel": {
      +            "description": "Labelled recipient, when known."
      +          },
      +          "token": {
      +            "description": "Token moved."
      +          }
      +        }
      +      },
      +      "type": "array"
      +    },
      +    "overallSignal": {
      +      "description": "Net read across the transfers — accumulating, distributing or neutral."
      +    },
      +    "reason": {
      +      "description": "Why the payload is absent, when `available` is false.",
      +      "type": "string"
      +    },
      +    "smartMoneyMoves": {
      +      "description": "One-line summaries of the same moves.",
      +      "items": {
      +        "description": "Summary line."
      +      },
      +      "type": "array"
      +    },
      +    "stale": {
      +      "description": "True when the snapshot is past its refresh interval."
      +    }
      +  },
      +  "type": "object"
      +}
  3. Added

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so safety and mutability are covered. The description adds useful scope by specifying the tracked cohort and recency, but it does not explain return behavior, pagination, or freshness beyond what the output schema and annotations provide.

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 a single front-loaded sentence with no filler. It quickly communicates the core data scope and then names the source cohort, making efficient use of limited space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because an output schema exists and the input schema is fully documented, return values and parameter usage do not need to be explained. However, for tool selection among a large sibling set, the description is incomplete: it does not differentiate from get_smart_money_inflow or clarify when this flow-oriented view should be chosen over related whale and inflow tools.

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?

There is one optional parameter, limit, with 100% schema description coverage already documenting its 1-25 range and default. The description adds no further meaning about the parameter, so the baseline of 3 applies.

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 clearly identifies the data resource: recent capital rotation by profitable on-chain wallets from a tracked smart-money cohort. It is more specific than a tautology, but it never states an action verb and does not distinguish this tool from the very similarly named sibling get_smart_money_inflow.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus alternatives. The description gives no conditions, prerequisites, or exclusions, and it does not route the agent between this tool and get_smart_money_inflow or other whale-tracking tools.

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.