Fetch Solana token launches and profiles ordered by pair age, with price, liquidity, volume, and risk flags; set a liquidity minimum and result limit.
Newest Solana tokens — 0.005 USDC. Newest Solana token profiles and fresh launches, youngest pair first, with price, liquidity, volume and risk flags. Cost: 0.005 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of tokens, 1-30 (default 20) | |
| minLiquidity | No | Minimum pool liquidity in USD (default 0) |
Changes observed during successful MCP inspections.
v1.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does add real value: a concrete price (0.005 USDC via x402), the sort order (youngest pair first), and the returned fields (price, liquidity, volume, risk flags). It omits pagination, retry/failure behavior, and what payment flow the agent must complete before the call succeeds.
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?
The content is short, but the cost is stated twice ('0.005 USDC' up front and again as 'Cost: 0.005 USDC via x402'), and the opening is a fragment rather than a front-loaded statement of function. Trimming the duplicate price would make it tighter.
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?
For a two-parameter, no-output-schema listing tool, the description covers what is returned, how it is ordered, and what it costs, which is nearly everything an agent needs. The only meaningful gap is payment mechanics and result-set size behavior.
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 description coverage is 100%, so both `limit` and `minLiquidity` are already documented with defaults, setting the baseline at 3. The description references liquidity and volume only as return fields, not as filter semantics, so it adds nothing beyond the schema.
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 (newest Solana token profiles / fresh launches) and the ordering rule ('youngest pair first'), which an agent can distinguish from get_trending or get_token_report. It does not explicitly name a sibling to contrast with, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'newest' and 'fresh launches' suggest a recency-discovery use case versus get_trending's popularity angle, but the description never states when to prefer this tool or when not to. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.