wallet-tracker

csid_callouts

Read-only

Callouts on YOUR CabalSpy ID instance, newest first: users call a token and
CabalSpy stamps the price and market cap and tracks it. Without filters the
latest callouts of your platform; with chain + mint the callouts of one token
("Who called this token and how did it do?"); with external_id or csid_id the
callouts of one user. Each entry: token, author (your user id), called_at,
market cap at the call, now_x and peak_x (multiples since the call), score_x
(the peak multiple the callout is scored by) and the tracking phase
(first_day: every minute for 24 h, then scored on candles; extended: every
5 minutes while active; stopped: after 24 h in a row below a $10k market cap).

Callouts are an extra switched on per instance on request; otherwise this
returns feature_not_enabled. Needs your own CabalSpy API key with a CabalSpy
ID instance (no demo).

Input Schema

Name	Required	Description
`mint`	No	Only callouts of this token (mint on Solana, contract on EVM); needs chain. Answers 'who called this token and how did it do'.
`chain`	No	Only callouts on this blockchain: solana, bnb, base, eth or rh. Required together with mint. Leave empty for all chains.
`limit`	No	How many callouts (1-50, default 10).
`cursor`	No	Pagination cursor taken from the previous response. Leave empty for the first page.
`csid_id`	No	Only this user: their CabalSpy ID user id (UUID), for users who signed in with CabalSpy ID themselves. Pass external_id or csid_id, not both.
`instance`	No	Your CabalSpy ID instance (its client_id, e.g. 'csid_1a2b…'). Only needed when your account has several instances. Leave empty otherwise.
`external_id`	No	Only this user: their id on YOUR platform (external_id), as passed when the user was created or imported. Pass external_id or csid_id, not both.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the burden and does so well: it discloses ordering (newest first), the feature_not_enabled failure mode, auth requirements and the tracking-phase lifecycle (first_day/extended/stopped with the $10k threshold). That is exactly the kind of context annotations cannot 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?

Front-loaded with purpose and filter modes, then return fields, then prerequisites; every sentence carries information. It is somewhat long, and the per-field return list borders on redundant given the output schema, but nothing is filler.

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?

For a 7-parameter, zero-required, paginated read tool with an output schema and annotations, the description covers scope, filter combinations, ordering, failure modes and auth. An agent has everything needed to call it correctly and interpret an error.

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%, and the schema already documents the chain+mint dependency and the 'external_id or csid_id, not both' rule, so the description mostly repeats it. It adds the high-level filter-mode framing but no new syntax or format detail, matching the baseline 3 for a fully documented schema.

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?

States a specific verb and resource ('Callouts on YOUR CabalSpy ID instance, newest first') and explains the domain concept of a callout. It is clearly distinguishable from siblings like csid_callout_stats, csid_callout_leaderboard and csid_user_theses by being the raw callout listing.

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?

Gives explicit mode selection: no filters = latest platform callouts; chain + mint = callouts of one token; external_id or csid_id = callouts of one user, each with the question it answers. Also states prerequisites (feature enabled per instance, own API key with a CabalSpy ID instance, no demo), so an agent knows when the call will fail.

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

All wallet-tracker 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?