Skip to main content
Glama
cookinfun

@cookinfun/mcp

by cookinfun

Recent trades for one token

token_trades

Retrieve recent trades for a Solana token, including each trader's PnL, win rate, bundle membership, and smart-money flag, to see who is buying or selling now.

Instructions

Recent trades for one token, each carrying the trader's history as it stood at that moment: PnL, win rate, bundle membership, smart-money flag. Use it to see who is buying or selling right now. Costs $0.01 per call (no payment configured, calls will return 402).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mintYesSolana token mint address, base58.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations the description carries the full burden, and it does disclose genuinely non-obvious traits: the exact return fields (PnL, win rate, bundle membership, smart-money flag) and the payment model — $0.01 per call with 402 returned when unconfigured. It omits auth/rate-limit details, keeping it short of 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.

Conciseness4/5

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

Three sentences, front-loaded with purpose, then usage, then cost. Every sentence earns its place; the payload enumeration is slightly long but justified by the absence of an output schema.

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?

For a simple single-parameter read tool with no output schema or annotations, the description covers purpose, return fields, and the cost/error behavior. The main gap is lack of sibling/alternative routing, which prevents a 5.

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% for the single 'mint' parameter, so the schema already documents base58 formatting. The description adds no parameter-level detail, so the baseline 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?

States a specific verb+resource combination ('Recent trades for one token') and names the enriched payload fields. It is clear what the tool returns, but it never explicitly differentiates itself from sibling scan_token, so it falls short of a 5.

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?

The sentence 'Use it to see who is buying or selling right now' gives an implied usage context but no when-not conditions and no explicit alternative (e.g., scan_token). Guidance is present but thin.

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