Summary: This MCP server gives agents paid Solana/Pump.fun token intelligence — scanning tokens, checking holders, bundles, KOLs, wallet reputation, and deployer history — billed per call via x402 USDC or a Cookin Pro key.
Scan a token (scan_token) — full snapshot for one mint: score, holders, bundles, KOL positions, behavior cohorts, pump/dump signals, and green/yellow/red ratings; optionally trim with fields.
See live trades (token_trades) — recent trades for a token, each with the trader's PnL, win rate, bundle membership, and smart-money flag at that moment.
Find candidates — list_new_tokens (post-rug-filter launches), list_pumping_tokens, and list_graduated_tokens (Raydium/PumpSwap graduates).
Follow proven strategies (list_agent_buys) — what top Cookin trading agents bought most recently.
Judge a wallet (profile_wallet) — lifetime PnL, ROI, win rate, hold times, bundle/smart-money flags, recent tokens.
Vet a deployer (deployer_history) — every token they launched, bond rate, peak market caps, and a survival curve across market cap rungs (paginated, cacheable).
Answer entry/hold/exit questions — who's behind a token, which wallets act as one group, how much supply heavy sellers hold, and how much tracked KOLs own.
Pay per call — $0.01 per call ($0.02 for a snapshot) with SOLANA_KEY, or 1 SOL/30 days with COOKIN_API_KEY; unpaid calls return 402. Also available as a remote endpoint at https://api.cookin.fun/mcp.
Provides Solana token intelligence through the Cookin API, including token scans, holder and bundle analysis, KOL positions, wallet reputation, deployer history, recent trades, and token ratings for Solana and Pump.fun tokens.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@cookinfun/mcp scan this pump.fun token for bundled wallets and KOL holders"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the Cookin API: Solana and Pump.fun token intelligence for agents. Ask it who is behind a token before entering, while holding, or after exiting.
Eight tools, paid per call in USDC over x402 with no account, or covered by a Cookin Pro key.
Coordinated wallets. Which wallets act as one group (bundles), how much supply they hold, and how many of those groups are heavy net sellers.
Holder quality. Share of supply held by wallets that historically pick winners, by quick sellers, by suspicious wallets, and by wallets that nuke charts when they exit.
KOL positions. Which tracked KOL wallets hold, and how much.
Wallet reputation. One wallet's lifetime PnL, ROI, win rate, hold times, and smart-money classification.
Deployer history. Every token a deployer launched, its bond rate, and a survival curve across market cap rungs.
Ratings. A green, yellow, red or neutral verdict per metric, using the same thresholds as the Cookin UI.
Related MCP server: Cabal-Hunter
Add this to claude_desktop_config.json:
{
"mcpServers": {
"cookin": {
"command": "npx",
"args": ["-y", "@cookinfun/mcp"],
"env": { "SOLANA_KEY": "<base58 Solana keypair holding USDC>" }
}
}
}In .cursor/mcp.json:
{
"mcpServers": {
"cookin": {
"command": "npx",
"args": ["-y", "@cookinfun/mcp"],
"env": { "COOKIN_API_KEY": "<Cookin Pro key>" }
}
}
}SOLANA_KEY=<base58 keypair> npx -y @cookinfun/mcpPick one. The server prints which mode it started in, on stderr.
Environment | Mode | Cost |
| Pay per call with x402 | $0.01 per call, $0.02 for a full token snapshot |
| Cookin Pro | 1 SOL per 30 days, 600 requests per minute |
neither | Unpaid | Every call returns 402 and says how to pay |
SOLANA_KEY is a base58-encoded 64-byte Solana keypair. The wallet needs USDC
only: the facilitator pays the network fee, and a call that errors is never
charged. Mint a Pro key at
cookin.fun/account/api-keys.
Optional:
COOKIN_MAX_PAYMENT caps what one call may pay. Default $0.05.
COOKIN_BASE_URL points at another host. Default https://api.cookin.fun.
Tool | Price | Returns |
| $0.02 | Full snapshot for one mint: score, holders, bundles, KOLs, cohorts, signals, ratings |
| $0.01 | Recent trades, each with the trader's history at that moment |
| $0.01 | New launches that passed the rug filters |
| $0.01 | Tokens currently pumping |
| $0.01 | Recent graduates |
| $0.01 | What the top Cookin agents bought most recently |
| $0.01 | One wallet's lifetime trading profile |
| $0.01 | Every token one deployer launched |
Spend less: start with one scan_token, and stop if its ratings already answer
the question. fields trims a snapshot at the same price. Deployer history
changes slowly, so cache it.
The same tools are served remotely at https://api.cookin.fun/mcp, with
nothing to install. Point an MCP host at that URL. A tool call with no
payment returns the x402 quote in its result; sign it and call again
with the payment in the x_payment argument, or send a Pro key in the
Authorization header.
Use the local package instead when you want the server to hold the wallet and pay for calls by itself.
Field-by-field reference: api.cookin.fun/skill.md
OpenAPI spec: api.cookin.fun/openapi.json
Docs: cookin.fun/api
npm install
npm test # unit tests, no network
npm run build # tsc to dist/
npm start # run the server over stdiopackage.json and server.json both carry the version, and the MCP
Registry rejects a mismatch. Bump both, publish to npm first (the
registry reads mcpName from the published package), then publish the
metadata:
npm publish --access public
mcp-publisher login github
mcp-publisher publishMIT
Every token one deployer has launched, with its bond rate, peak market caps, and a survival curve across market cap rungs. Changes slowly, so cache the answer. Costs $0.01 per call (no payment configured, calls will return 402).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Tokens per page, 1 to 100. Default 50. | |
| offset | No | Tokens to skip. Default 0. | |
| address | Yes | Deployer wallet address, base58. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose non-obvious traits: slow-changing data suitable for caching and a hard failure mode (402 because no payment is configured). It still omits ordering, pagination totals, and rate-limit behavior, so it falls short of full transparency.
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?
Three tight sentences: what it returns first, then caching behavior, then cost/failure. Zero filler and the most decision-relevant fact is front-loaded.
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 tool with no output schema and no annotations, the description supplies the key missing context: what the payload covers, that data is stable, and that calls will 402 without payment. It leaves result ordering and pagination semantics unstated, but the essential call-time context is present.
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 the schema already documents address, limit, and offset with ranges and defaults. The description adds nothing about parameter semantics, making the baseline 3 appropriate.
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?
The description states a specific resource (every token a single deployer has launched) and even enumerates the returned metrics (bond rate, peak market caps, survival curve), which is far more concrete than a tautology. However, it never names or differentiates itself against siblings like list_new_tokens or profile_wallet, so an agent must infer the boundary itself.
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?
The caching hint ('changes slowly, so cache the answer') is genuine usage guidance, and the 402 warning tells the agent calls may fail for payment reasons. There is no when-to-use versus when-not guidance and no pointer to an alternative for deployer-level analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tokens the top Cookin trading agents bought most recently, with quality signals. The most-bought Cookin endpoint: it answers what proven strategies are doing right now. Costs $0.01 per call (no payment configured, calls will return 402).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose valuable behavioral context absent from structured fields: $0.01 per call and that calls will return 402 without payment configured. However, it omits return format, pagination, rate limits, and auth details for a read endpoint.
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?
Three compact sentences, front-loaded with what the tool returns before adding the pricing caveat. 'The most-bought Cookin endpoint' leans slightly promotional but doubles as a selection cue, so little is wasted.
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 zero-parameter read tool with no output schema, the definition covers purpose, scope, and the critical payment failure mode. What it returns is only gestured at ('quality signals'), but nothing essential to calling it correctly is missing.
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?
The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond the implied 'most recent' default scope, which it does state.
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?
The description states a specific verb and resource ('Tokens the top Cookin trading agents bought most recently, with quality signals'), which clearly differs from token_trades (individual trades) or list_new_tokens (recency of listing). It is clear what the tool returns, though it never names a sibling to explicitly disambiguate.
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?
'Answers what proven strategies are doing right now' implies a use case but gives no explicit when-to-use or when-not-to-use condition, and does not contrast with scan_token, token_trades, or list_pumping_tokens. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pump.fun tokens that recently graduated to Raydium or PumpSwap, with quality signals and ratings. Costs $0.01 per call (no payment configured, calls will return 402).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose a genuinely important trait: a $0.01 per-call cost and that calls return 402 without payment configured. However, it omits the time window for 'recently', result count, pagination, ordering, and rate limits.
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?
Two compact sentences, front-loaded with what the tool returns, then the cost blocker. No filler and nothing redundant.
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 zero-parameter list tool with no output schema, the description covers the resource and hints at return content ('quality signals and ratings') plus the payment failure mode. Missing details about window size, result count, and pagination keep it from being fully complete.
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?
There are zero parameters and 100% schema coverage, so the baseline is 4. The description neither needs nor adds any parameter information, and nothing is misleading.
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?
The description states a specific resource and scope: pump.fun tokens that recently graduated to Raydium or PumpSwap. That clearly separates it from siblings like list_new_tokens and list_pumping_tokens by lifecycle stage. It stops short of explicitly naming those alternatives, so it is clear but not maximally differentiated.
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?
There is no when-to-use guidance and no alternatives are named, so the agent must infer from the name that this is the graduated-stage listing. The only routing hint is the cost caveat, not a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Newly launched Pump.fun tokens that passed Cookin's rug filters, with quality signals and ratings. Use it to find candidates. Costs $0.01 per call (no payment configured, calls will return 402).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers on the most important point: 'Costs $0.01 per call (no payment configured, calls will return 402).' That warns the agent calls will fail, which is unusually valuable. It still omits return format and pagination behavior, so not 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: purpose first, usage hint second, cost warning third. No filler, and the critical 402 caveat is not buried.
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 zero-param list tool with no output schema and no annotations, the description conveys what is returned ('quality signals and ratings'), when to use it, and the failure condition. It could say more about the returned item structure, but the essential call-time information is present.
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?
The tool takes zero parameters, so per the baseline there is nothing for the description to document and no risk of misinterpretation. No param detail is needed here.
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?
The description names a specific resource and scope: 'Newly launched Pump.fun tokens that passed Cookin's rug filters, with quality signals and ratings.' This distinguishes it meaningfully from list_graduated_tokens and list_pumping_tokens by its 'newly launched' filter, though it never explicitly names those siblings.
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?
The only guidance is the thin 'Use it to find candidates.' There is no when-not guidance, no prerequisites, and no comparison against close siblings like scan_token or list_pumping_tokens, which leaves the agent to infer which listing tool to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pump.fun tokens currently pumping, with quality signals, holder behavior, and ratings. Costs $0.01 per call (no payment configured, calls will return 402).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose two high-value facts: a per-call cost of $0.01 and the critical failure mode that no payment is configured so calls return 402. It does not cover pagination, result limits, ordering, or whether the operation is read-only, so it falls short of exhaustive disclosure.
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?
Two tight sentences with zero waste. The content of the list is front-loaded in sentence one, and the cost/402 warning follows immediately where an agent will see it before invoking.
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 parameterless list tool with no output schema, the description gives enough to call it correctly and even flags the 402 outcome. It omits result volume, ordering, and pagination behavior, which would matter to an agent planning a follow-up call.
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?
The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. Schema coverage is 100% on an empty object, so no additional parameter explanation is needed.
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 and state — 'Pump.fun tokens currently pumping' — with the returned content (quality signals, holder behavior, ratings) named. The 'currently pumping' qualifier cleanly separates it from siblings list_new_tokens and list_graduated_tokens, so an agent can route without opening either schema.
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 implied by the 'currently pumping' filter, which gives an agent a rough sense of when this list is the right one versus list_new_tokens or list_graduated_tokens. However, there is no explicit when-to-use statement, no exclusions, and no mention of how it relates to scan_token or token_trades.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lifetime trading profile of one Solana wallet: PnL, ROI, win rate, hold times, bundle and smart-money flags, recent tokens traded. Use it to judge a buyer or seller you saw in a trade list. Costs $0.01 per call (no payment configured, calls will return 402).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Solana wallet address, base58. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose a genuinely useful trait — cost of $0.01 per call and that calls will return 402 without a payment configured — but says nothing about auth requirements, rate limits, or whether the operation is strictly read-only beyond the 'profile' framing.
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?
Three sentences, front-loaded with purpose then usage then cost. The payment/402 parenthetical is slightly verbose but earns its place as actionable behavioral info.
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 simple single-parameter read tool with no output schema, the description substitutes well by listing the profile fields returned and disclosing the payment/402 behavior. Remaining gaps around auth and rate limits are minor given the tool's low complexity.
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%: the single 'address' parameter is fully documented as a base58 Solana wallet address. The description adds no format, constraint, or example beyond the schema, so baseline 3 applies.
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 verb and resource — 'Lifetime trading profile of one Solana wallet' — and enumerates the returned fields (PnL, ROI, win rate, hold times, flags, recent tokens). The resource is clearly wallet-focused, which separates it from the token- and trade-oriented siblings, though no sibling is named explicitly.
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?
Gives a concrete when-to-use condition: 'Use it to judge a buyer or seller you saw in a trade list.' No when-not or alternative tools are named, so it falls short of the explicit routing seen in the best definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full Cookin snapshot for one Solana or Pump.fun token: quality score, holders, bundles (coordinated wallets), KOL positions, holder behavior cohorts, pump/dump signals, and a green/yellow/red rating per metric. The first call to make about a token, at any stage of its life. Costs $0.02 per call (no payment configured, calls will return 402).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana token mint address, base58. | |
| fields | No | Comma-separated groups to return, for a smaller response at the same price: meta, status, market, holders, bundles, score, cohorts, kols, signals, ratings. Omit for all of them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses unusually valuable operational context: cost is $0.02 per call and, with no payment configured, calls return 402. It does not explicitly state the read-only nature or any rate limits beyond the per-call price, so it is strong but not exhaustive.
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 purpose and returned data are front-loaded in the first sentence, with the cost/payment caveat immediately after. It is reasonably tight, though the long enumerated list of data groups is heavier than strictly needed for conciseness.
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?
With no output schema, the description appropriately enumerates the return payload's contents and groups. Combined with the payment/402 disclosure and the 'first call' positioning, an agent has enough to call it correctly; only minor gaps like explicit read-only confirmation remain.
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% for both parameters, so the schema already documents 'mint' (base58 Solana mint address) and the 'fields' group selection with its comma-separated group list. The description body adds no parameter detail beyond the schema, so the baseline 3 applies.
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?
The description states a specific verb+resource ('Full Cookin snapshot for one Solana or Pump.fun token') and enumerates the returned data groups (score, holders, bundles, KOL positions, cohorts, signals, ratings). It implicitly distinguishes itself as 'the first call to make about a token' but does not name the sibling tools it differs from, so it falls just short of full sibling differentiation.
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?
'The first call to make about a token, at any stage of its life' gives clear when-to-use guidance and an implied priority ordering relative to siblings. There is no explicit when-not or named alternative (e.g., token_trades), so it stops short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana token mint address, base58. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0deployer_historylist_agent_buyslist_graduated_tokenslist_new_tokenslist_pumping_tokensprofile_walletscan_tokentoken_tradesScored across 8 tools
Each tool targets a clearly distinct action+object: token snapshot (scan_token), recent trades (token_trades), four filtered token lists (new, pumping, graduated, agent buys), wallet profile (profile_wallet), and deployer history (deployer_history). The list_ tools are differentiated by filter and description, so no tool is likely to be misselected.
Most tools follow a verb_noun pattern (scan_token, list_*, profile_wallet), and the list_ family is highly consistent. Two tools deviate with noun_noun forms (token_trades, deployer_history), which is a minor but noticeable inconsistency.
Eight tools is well-scoped for a token analytics server. Each tool serves a unique query type without redundancy, making the count appropriate and easy to navigate.
The surface covers token snapshot, trades, discovery via multiple list filters, wallet profiling, and deployer history—most core analytics needs. Minor gaps include no symbol/name search or historical price charts, but these are workable around the current tools.
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
Solana address risk grades and token scans for AI agents. Pay-per-call via x402 (USDC on Base).
Pay-per-call Solana token risk intelligence: 8 tools via x402. From $0.005 USDC, no API key.
Solana + pump.fun intel for agents: launch verdicts, token risk, dev/wallet records, smart money.