A
licenseNot graded
qualityF
maintenanceAn MCP server that enables AI agents to launch, buy, and sell tokens on the Raydium Launchpad(aka LaunchLab).
4
MIT
cook4fun-mcp
by htunaa
Click on "Install 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., "@cook4fun-mcpbuy 0.1 ETH of $MEME"
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.
cook4fun-mcp
An MCP server that lets any MCP-compatible agent launch and trade coins on cook4.fun, a Uniswap-V4-native launchpad on the Robinhood chain (chainId 4663).
It runs locally on your own machine (stdio transport), signs with your own wallet, and talks straight to the chain. There is no hosted service and nothing to pay for: your client (Claude Desktop, Cursor, Cline, Windsurf, and other MCP clients) starts it on demand.
Tools
Tool | What it does | Wallet needed |
| List the newest coins with market caps | no |
| Show the trading wallet address and ETH balance | yes |
| Launch a new coin (deploys token + opens its V4 pool, optional first buy) | yes |
| Buy a coin with ETH (slippage-protected) | yes |
| Sell a coin back to ETH by amount, percentage, or all (auto-approves) | yes |
| Claim reward-sharing fees | yes |
Coins are referenced by contract address (0x…) or $TICKER.
Related MCP server: base-token-sniper-mcp
Setup
Add the server to your MCP client's config. No install step is required: npx fetches and builds it on first run.
Claude Desktop (claude_desktop_config.json), Cursor, Cline, Windsurf, and most clients use the same shape:
{
"mcpServers": {
"cook4fun": {
"command": "npx",
"args": ["-y", "github:htunaa/cook4fun-mcp"],
"env": {
"COOK4FUN_PRIVATE_KEY": "0xYOUR_WALLET_PRIVATE_KEY"
}
}
}
}Restart the client and the cook4fun_* tools appear.
Configuration
Env var | Required | Default | Notes |
| for trading | none | Wallet private key ( |
| no |
| Custom RPC endpoint. |
| no |
| Override the launchpad contract. |
| no |
| Default slippage tolerance for buys/sells, in basis points. |
⚠️ Security: the server can spend everything in this wallet. Fund it with only what you want the agent to trade, and treat the key like any other secret. The key stays on your machine; it is never sent anywhere except to sign transactions locally.
Example prompts
what's new on cook4fun?
launch a coin called "Space Cat" with ticker SCAT
buy 0.05 ETH of $SCAT
sell 50% of my $SCAT
claim my rewards on $SCATRun from a local checkout
git clone https://github.com/htunaa/cook4fun-mcp
cd cook4fun-mcp
npm install
npm run buildThen point the client's command/args at node + the built file:
{
"mcpServers": {
"cook4fun": {
"command": "node",
"args": ["/absolute/path/to/cook4fun-mcp/dist/index.js"],
"env": { "COOK4FUN_PRIVATE_KEY": "0x…" }
}
}
}Develop
npm run typecheck
npm run buildLicense
MIT
Available Tools
6 toolscook4fun_buyBuy a coinA
Buy a cook4.fun coin by spending ETH. Reference the coin by 0x address or $TICKER. Slippage-protected.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Coin address (0x…) or $TICKER | |
| ethAmount | Yes | ETH to spend, e.g. "0.05" | |
| slippageBps | No |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses slippage protection, a key behavioral trait, but omits details like whether the purchase is immediate, transaction result, or reversibility.
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?
Two front-loaded sentences convey the action and key details without redundancy. Could be slightly more structured but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction tool with 3 parameters, no output schema, and no annotations, the description lacks completeness. It does not explain the return value, gas implications, or failure conditions, which are critical for an AI agent to use correctly.
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?
The description adds value by clarifying how to reference the token (0x address or $TICKER) and gives an example for ethAmount. However, the slippageBps parameter, though mentioned as slippage-protected, is not explicitly described, and schema coverage is 67%.
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?
The description uses a specific verb 'Buy' and resources 'cook4.fun coin' and 'ETH', clearly distinguishing it from sibling tools like cook4fun_sell or cook4fun_launch.
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 description implies usage for buying coins but does not explicitly state when to use this tool over alternatives like cook4fun_claim or cook4fun_sell, nor does it mention prerequisites like having ETH.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cook4fun_claimClaim rewardsB
Claim the wallet's share of a reward-sharing coin's accrued fees.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Coin address (0x…) or $TICKER |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description offers only minimal behavioral info (claiming fees). Missing details on whether the call is a write operation, triggers transactions, requires wallet balance, or has side effects like gas fees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action and resource. No wasted words; the entire description is functional and to the point.
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?
Despite missing annotations and some behavioral details, the description covers the essential purpose and parameter for a simple claim operation. It could mention expected outcomes or return values, but the lack of output schema reduces burden. Still fairly complete given tool simplicity.
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 coverage is 100% for the single required parameter (token), and the schema description adequately defines it. The tool description adds no extra semantic value beyond the schema, so the score is at baseline.
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?
The description clearly specifies the action ('claim'), the resource ('wallet's share of a reward-sharing coin's accrued fees'), and distinguishes from sibling tools (buy, sell, launch, list_coins, wallet) by focusing on claiming rewards rather than purchasing, selling, or managing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like buying or selling. No prerequisites, context, or conditions for claiming are mentioned, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cook4fun_launchLaunch a coinA
Launch a new coin on cook4.fun: deploys the token, opens its Uniswap V4 pool, and optionally makes a first buy. Requires a wallet with ETH.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Coin name, e.g. "Space Cat" | |
| image | No | Any public image URL (https or ipfs://). cook4.fun copies it onto IPFS and pins it, so a temporary host is fine — you don't need to host it permanently yourself. | |
| symbol | Yes | Ticker, e.g. SCAT | |
| No | |||
| website | No | ||
| telegram | No | ||
| distribute | No | Share LP fees with holders | |
| description | No | ||
| firstBuyEth | No | ETH amount for an initial buy, e.g. "0.05" | |
| metadataUrl | No | ERC-7572 metadata JSON URL |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses main actions (deploy, open pool, optional buy) and a prerequisite. No annotations present, so description carries full burden; lacks details on costs, reversibility, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single compact sentence that conveys essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description is minimal. Lacks explanation of return values, post-launch behavior, or parameter interactions.
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?
No parameter details in description; schema covers 60% of parameters with descriptions. Description adds no value beyond schema, so baseline 3 is appropriate.
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?
The description explicitly states the tool launches a new coin, detailing actions (deploys token, opens Uniswap V4 pool, optional first buy). It clearly distinguishes from sibling tools like cook4fun_buy, cook4fun_sell, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions prerequisite ('requires a wallet with ETH'), providing context. No explicit when-not or alternatives, but sibling names imply usage for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cook4fun_list_coinsList cook4.fun coinsA
List the newest coins on cook4.fun with their market caps. Read-only, no wallet needed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is read-only and requires no wallet, which is useful behavioral transparency given no annotations. It does not mention rate limits or empty returns, but the tool is simple.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the key purpose and behavioral hint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional param, no output schema), the description covers the basic purpose and read-only nature. However, it omits the limit parameter and does not clarify the return format beyond market caps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the tool description does not mention the 'limit' parameter or its effect. The parameter is optional with constraints, but the description should guide usage.
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?
The description clearly states the tool lists the newest coins on cook4.fun with their market caps, using a specific verb and resource, and is distinguished from sibling tools like buy, sell, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is read-only and requires no wallet, providing context for when to use. However, it does not explicitly exclude scenarios or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cook4fun_sellSell a coinA
Sell a cook4.fun coin back to ETH. Specify an exact token amount, a percentage, or all. Auto-approves and is slippage-protected.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | Sell the entire balance | |
| token | Yes | Coin address (0x…) or $TICKER | |
| percent | No | Percent of balance to sell | |
| slippageBps | No | ||
| amountTokens | No | Exact number of tokens to sell |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds value by stating 'Auto-approves and is slippage-protected.' However, it lacks details on failure modes, gas costs, or prerequisites, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding essential information: the main action, amount specification methods, and behavioral features. No redundancy or wasted words.
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?
Given no output schema and no annotations, the description covers inputs and key behaviors. Missing: return value, error handling, and prerequisites. Still mostly complete for a sell tool.
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 80%, and the description adds meaning by explaining the three amount modes (exact, percent, all) corresponding to parameters. It does not elaborate on 'slippageBps' beyond the general claim of slippage protection.
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?
The description clearly states the action: selling a cook4.fun coin back to ETH. It distinguishes from sibling tools like buy, claim, launch, etc., by specifying the seller's perspective and the target asset (ETH).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to specify the amount (exact, percentage, or all) and mentions auto-approve and slippage protection. It does not explicitly contrast with alternatives, but the context of selling vs. other operations is clear from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cook4fun_walletShow trading walletA
Show the configured wallet address and its ETH balance on the Robinhood chain.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates read-only behavior ('Show'), but does not disclose auth requirements or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no wasted words. Front-loaded with action and result.
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?
Description explains return value (address and balance). No output schema needed for simple read. Contextually adequate.
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?
No parameters in schema; schema description coverage is 100%. No additional parameter info needed.
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?
Description clearly states action (Show) and resource (wallet address and ETH balance). Distinct from sibling tools (buy, sell, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It is implied for checking wallet info, but no explicit when-not or alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
6 tool updates
v0.1.0- First observed
cook4fun_buy - First observed
cook4fun_claim - First observed
cook4fun_launch - First observed
cook4fun_list_coins - First observed
cook4fun_sell - First observed
cook4fun_wallet
TDQS
A4/5.0
Disambiguation5/5
Each tool has a distinct purpose: buy, sell, launch, claim, list, and wallet. No overlapping functionality.
Naming Consistency5/5
All tools follow the consistent pattern 'cook4fun_<verb>' or 'cook4fun_<verb_noun>', using snake_case.
Tool Count5/5
6 tools is ideal for a coin platform; each is necessary and earns its place.
Completeness4/5
Covers core operations: buy, sell, launch, claim, list, wallet. Could add a transfer tool but no major gaps.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
The only x402 MCP server for Robinhood Chain (chainId 4663) - 147 onchain, trading & AI tools.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
HiveCapital MCP Server — autonomous investment layer for AI agents
Official MCP server for subfeed.app — the cloud for agents. 15+ tools for AI agents to register, build, and deploy other agents. Zero human required. Start here: subfeed.app/skill.md
Related MCP Servers
- AlicenseAqualityDmaintenanceAn MCP server for AI agents to discover and trade new token launches on Base chain.5381MIT
- AlicenseAqualityAmaintenanceAn MCP server enabling AI agents to trade stock tokens using StonkBroker NFTs via ERC-6551 wallets on Robinhood Chain through Uniswap, with X integration.6MIT
- AlicenseNot gradedqualityAmaintenanceAn MCP server that gives AI agents a Solana wallet to autonomously launch and trade tokens on Solana's AgentPump bonding-curve launchpad via natural language.73MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/htunaa/cook4fun-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server