Skip to main content
Glama

groundtruth_wallet_record

Read-onlyIdempotent

One WALLET in, its counts out, from GROUNDTRUTH's own Solana capture tape (not a third party feed). Each of four fields is x/n with a one-line definition of n beside it, its rate, the same rate over all wallets, and the word above, below or about ("about" = within 2 percentage points): bad_share (buys in coins from creators with 5+ launches, 80%+ rugged, judged at each coin's launch; n = buys in coins whose dev we have counted), pre_rug_exits (n = the wallet's sells in coins that rugged; x = those in the 60 s up to the rug), copier_bagholder (buys where a wallet that first bought 1-2 s later still held at the rug; n = buys in coins that rugged where another wallet's first buy in that coin landed 1-2 s later; x = those where at least one wallet that first bought 1-2 s later had not sold at the rug) and early_buys (n = buys in coins with a known launch time; x = within 30 s of the launch). Then the tape range, buys_total (counts all buys; each n counts only the buys that meet its own condition), role (a label; role_label is its display form: deployer, early buyer or trader) and, for a deployer, its launches last (hand_label), dated, with the pip legend and what rugged means. A coin the wallet created itself is left out of the four fields (own_coins_excluded counts them). wallet_record is null, with wallet_record_reason, when the wallet is not in the tape cut (fewer than 100 buys in the tape range). Counts only. creator_record (a deployer) carries the LIVE FIELDS, from the mint feed every 5 s: last_mint_live (unix s of the dev's newest mint), launched_live, bonded_live and mints_since_asof; ticker_asof = the newest mint the feed has seen. A row with no mints_since_asof is not live: refuse it. bonded_asof dates the recount part; peak / pull and ttr_* are history (peak_proven / pull_proven false), not a trade signal; known_bad is the census rule.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletYesA Solana wallet address (base58).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already mark this as read-only, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: data provenance from a capture tape, exclusion of self-created coins, null conditions, live-field freshness, and a rule to refuse rows without mints_since_asof.

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

Conciseness2/5

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

The description is a single dense paragraph with long parenthetical definitions and many specialized terms. It front-loads the core idea but then becomes difficult to parse, and much of the field-level detail could be structured more cleanly or moved to an output schema.

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?

There is no output schema, so the description must carry the full burden of explaining return values and behavioral conditions. It does so extensively, covering the four count fields, denominator definitions, rate comparisons, null behavior, tape range, role labels, live fields, and refusal conditions.

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

Parameters4/5

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

Schema coverage is 100%, so the wallet parameter is already documented as a base58 Solana address. The description adds meaningful context by explaining the wallet must be in the tape cut (at least 100 buys) or wallet_record is null, which the schema does not state.

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 states that one wallet goes in and its counts come out, names the data source (GROUNDTRUTH's Solana capture tape), and enumerates the returned fields. It does not differentiate this tool from any sibling tool by name or scope, but the core purpose is specific enough for an agent to identify it.

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

Usage Guidelines3/5

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

Usage is implied by 'One WALLET in, its counts out,' and the description notes that wallet_record is null when the wallet is outside the tape cut (fewer than 100 buys). It gives no explicit when-to-use guidance versus sibling tools and no alternatives for wallet-level queries.

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