솔라나 기반 Pump.fun 플랫폼과 상호 작용하기 위한 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버를 통해 AI 어시스턴트는 Pump.fun 플랫폼에서 토큰을 생성, 구매 및 판매할 수 있습니다.
https://github.com/user-attachments/assets/0b0f1f6f-6ea6-4ca8-92a8-b4cc895814e4
Claude나 다른 MCP 호환 AI 어시스턴트와 함께 이 서버를 사용하려면 MCP 클라이언트에 다음 구성을 추가하세요.
MacOS를 사용하고 Claude Desktop에서 실행하려면 ~/Library/Application \Support/Claude/claude_desktop_config.json 파일에 다음을 작성하세요.
지엑스피1
https://your-helius-rpc-url.com Helius RPC URL 로 바꾸세요.
Related MCP server: AMOCA Solana MCP Server
이 저장소를 복제하세요:
git clone https://github.com/noahgsolomon/pumpfun-mcp.git
cd pumpfun-mcp종속성 설치:
npm installSolana RPC URL로 .env 파일을 만듭니다.
HELIUS_RPC_URL=https://your-helius-rpc-url.comHelius 에서 무료 RPC URL을 얻을 수 있습니다.
기존 Solana 지갑을 사용하려면 .env 파일에 개인 키를 추가하세요.
PRIVATE_KEY=your-base58-encoded-private-key그런 다음 변환 스크립트를 실행하여 키 쌍 파일을 만듭니다.
node convert-key.js이렇게 하면 키 쌍이 포함된 default.json 파일이 .keys 폴더에 생성됩니다.
프로젝트를 빌드하세요:
npm run buildMCP 서버를 실행합니다.
node build/index.js토큰 정보 가져오기
Pump.fun 토큰에 대한 정보를 얻으세요
입력 매개변수:
tokenAddress (문자열, 필수): 토큰의 민트 주소
토큰 생성
새로운 Pump.fun 토큰을 생성하세요
입력 매개변수:
name (문자열, 필수): 토큰 이름
symbol (문자열, 필수): 토큰 심볼
description (문자열, 필수): 토큰 설명
imageUrl (문자열, 선택 사항): 로컬 이미지 파일 경로
initialBuyAmount (숫자, 필수): SOL 단위의 초기 구매 금액(최소 0.0001)
accountName (문자열, 선택 사항): 사용할 계정의 이름(기본값은 "default")
토큰 구매
Pump.fun 토큰을 구매하세요
입력 매개변수:
tokenAddress (문자열, 필수): 토큰의 민트 주소
buyAmount (숫자, 필수): SOL로 구매할 금액(최소 0.0001)
accountName (문자열, 선택 사항): 사용할 계정의 이름(기본값은 "default")
slippageBasisPoints (숫자, 선택 사항): 기준 포인트 단위의 미끄러짐 허용 오차(기본값은 100)
토큰 판매
Pump.fun 토큰 판매
입력 매개변수:
tokenAddress (문자열, 필수): 토큰의 민트 주소
sellAmount (숫자, 필수): 판매할 토큰 수량(모두 판매하려면 0 사용)
accountName (문자열, 선택 사항): 사용할 계정의 이름(기본값은 "default")
slippageBasisPoints (숫자, 선택 사항): 기준 포인트 단위의 미끄러짐 허용 오차(기본값은 100)
목록 계정
키 폴더에 있는 모든 계정을 나열합니다
입력 매개변수가 필요하지 않습니다
계정 잔액 가져오기
계정의 SOL 및 토큰 잔액을 확인하세요
입력 매개변수:
accountName (문자열, 선택 사항): 확인할 계정의 이름(기본값은 "default"임)
tokenAddress (문자열, 선택 사항): 잔액을 확인할 토큰 주소
MCP는 .keys 폴더에 Solana 키 쌍을 자동으로 생성하고 관리합니다. 각 키 쌍은 계정 이름을 파일 이름으로 사용하는 JSON 파일로 저장됩니다.
토큰을 생성할 때 mint 키 쌍도 mint- 접두사를 붙여 .keys 폴더에 저장됩니다.
자신의 계정으로 MCP를 사용하려면 다음이 필요합니다.
.env 파일에 개인 키를 추가하고 node convert-key.js 실행합니다.
해당 지갑에 충분한 SOL이 있어야 합니다.
이 프로젝트에는 직접 실행할 수 있는 여러 개의 독립 실행형 스크립트가 포함되어 있습니다.
토큰 정보 가져오기 : node build/get-token-info.js <token_address>
토큰 생성 : node build/create-token.js <name> <symbol> <description> <initial_buy_amount> [account_name] [image_url]
토큰 구매 : node build/buy-token.js <token_address> <buy_amount_sol> [account_name] [slippage_basis_points]
토큰 판매 : node build/sell-token.js <token_address> <sell_amount> [account_name] [slippage_basis_points]
계정 목록 : node build/list-accounts.js
계정 잔액 가져오기 : node build/get-token-balance.js <account_name> [token_address]
보안 : 키 쌍은 .keys 폴더에 암호화되지 않은 상태로 저장됩니다. 이 폴더를 적절하게 보호하세요.
수수료 : Solana에서 이루어지는 모든 거래에는 수수료로 SOL이 필요합니다. 계좌에 충분한 SOL이 있는지 확인하세요.
슬리피지 : 기본 슬리피지 허용 범위는 1%(100 베이시스 포인트)입니다. 각 거래마다 이 허용 범위를 조정할 수 있습니다.
이미지 : 이미지로 토큰을 생성할 때는 이미지의 로컬 파일 경로를 제공해야 합니다. 원격 URL은 지원되지 않습니다.
src/index.ts : 메인 MCP 서버 진입점
src/get-token-info.ts : 토큰 정보 검색
src/create-token.ts : 토큰 생성 기능
src/buy-token.ts : 토큰 구매 기능
src/sell-token.ts : 토큰 판매 기능
src/list-accounts.ts : 계정 목록 기능
src/get-token-balance.ts : 계좌 잔액 확인
src/utils.ts : 공유 유틸리티 함수
convert-key.js : base58 개인 키를 키페어 JSON 파일로 변환하는 유틸리티
npm run buildBuy a Pump.fun token
| Name | Required | Description | Default |
|---|---|---|---|
| accountName | No | Name of the account to use | default |
| buyAmount | Yes | Amount to buy in SOL | |
| slippageBasisPoints | No | Slippage tolerance in basis points (1% = 100) | |
| tokenAddress | Yes | The token's mint address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without disclosing behavioral traits like required permissions, transaction costs, rate limits, or what happens on failure. 'Buy' implies a financial transaction, but critical details like confirmation steps or irreversible effects are missing.
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 description is a single, efficient sentence with zero waste, front-loading the core action. It's appropriately sized for the tool's complexity, making it easy to parse quickly.
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?
Given no annotations, no output schema, and a financial transaction tool with 4 parameters, the description is incomplete. It lacks essential context like return values, error handling, or behavioral nuances, leaving significant gaps for safe and effective use.
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 parameters are well-documented in the schema. The description adds no additional meaning beyond implying token purchase, which aligns with schema but doesn't enhance understanding of parameter interactions or usage context.
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 clearly states the action ('buy') and resource ('a Pump.fun token'), providing specific purpose. However, it doesn't differentiate from sibling 'sell-token' beyond the verb direction, missing explicit distinction about when each is appropriate.
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?
No guidance on when to use this tool versus alternatives like 'sell-token' or 'create-token' is provided. The description assumes context but offers no explicit usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Pump.fun token
| Name | Required | Description | Default |
|---|---|---|---|
| accountName | No | Name of the account to use (will be created if it doesn't exist) | default |
| description | Yes | Token description | |
| imageUrl | No | URL to token image (optional) | |
| initialBuyAmount | Yes | Initial buy amount in SOL | |
| name | Yes | Token name | |
| symbol | Yes | Token symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. 'Create' implies a write operation, but it doesn't disclose critical traits like authentication requirements, cost implications (SOL usage), whether the token becomes immediately tradable, or potential rate limits. The description fails to compensate for the lack of annotations.
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 description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point with zero wasted content.
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 token creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., token address returned, initialization state), doesn't mention SOL cost implications from 'initialBuyAmount', and provides no context about the creation process. The schema covers parameters well, but behavioral and outcome aspects are 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?
Schema description coverage is 100%, providing good documentation for all parameters. The description adds no parameter-specific information beyond what's in the schema. This meets the baseline of 3 since the schema adequately covers parameter meanings, but the description doesn't enhance understanding of how parameters interact or their business significance.
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 clearly states the action ('Create') and resource ('new Pump.fun token'), making the purpose immediately understandable. It distinguishes from siblings like 'buy-token' or 'sell-token' by focusing on creation rather than trading operations. However, it doesn't specify what 'create' entails in this context (e.g., minting, deployment).
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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an account), differentiate from similar tools like 'get-token-info', or indicate when creation is appropriate versus buying existing tokens. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the SOL and token balances for an account
| Name | Required | Description | Default |
|---|---|---|---|
| accountName | No | Name of the account to check | default |
| tokenAddress | No | Optional token address to check balance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical behavioral details such as whether this is a read-only operation (implied but not explicit), potential rate limits, authentication requirements, or error conditions. This is a significant gap for a tool that likely interacts with financial data.
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 description is a single, efficient sentence that directly states the tool's purpose without any fluff. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.
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?
Given the complexity of financial balance retrieval, no annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., balance values, formats), potential side effects, or error handling. This leaves the agent with insufficient context for reliable tool invocation.
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 schema description coverage is 100%, so the schema already documents both parameters ('accountName' and 'tokenAddress') with clear descriptions. The description adds no additional semantic context beyond implying balance retrieval for SOL and tokens, which aligns with the schema but doesn't provide extra value like parameter interactions or examples.
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 clearly states the action ('Get') and resources ('SOL and token balances for an account'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list-accounts' or 'get-token-info', which could provide related information, so it falls short of a perfect score.
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 description provides no guidance on when to use this tool versus alternatives. For example, it doesn't clarify if this is for checking balances of a specific account versus listing all accounts (as 'list-accounts' might do), or how it differs from 'get-token-info' in terms of balance retrieval. This lack of context leaves 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.
Get information about a Pump.fun token
| Name | Required | Description | Default |
|---|---|---|---|
| tokenAddress | Yes | The token's mint address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get information'), which implies it's likely safe and non-destructive, but doesn't address potential rate limits, authentication needs, error conditions, or what specific information is returned. This leaves significant gaps for a tool with no annotation coverage.
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 description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's perfectly front-loaded and every word earns its place, making it highly concise and well-structured.
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?
Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what information is returned (e.g., price, liquidity, creator), how errors are handled, or any behavioral constraints. For a tool with no structured data beyond the input schema, this leaves too many unknowns for reliable agent operation.
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 schema description coverage is 100%, with the single parameter 'tokenAddress' clearly documented in the schema as 'The token's mint address'. The description doesn't add any additional parameter context beyond what the schema provides, so it meets the baseline for adequate but not exceptional coverage.
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 clearly states the action ('Get information') and target resource ('about a Pump.fun token'), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'get-account-balance' that might also retrieve information, so it doesn't reach the highest score.
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 description provides no guidance on when to use this tool versus alternatives like 'get-account-balance' or 'list-accounts'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all accounts in the keys folder
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a list operation, implying it's likely read-only, but doesn't clarify permissions, rate limits, pagination, or what 'keys folder' represents. The description adds minimal behavioral context beyond the basic action.
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 description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information.
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 list tool with no parameters and no output schema, the description provides the basic purpose but lacks important context. Without annotations, it should ideally clarify what 'accounts' and 'keys folder' mean, the return format, and any behavioral constraints. The description is minimally adequate but leaves gaps.
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 has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. Baseline for 0 parameters with full coverage is 4.
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 clearly states the action ('List') and target resource ('all accounts in the keys folder'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from its siblings like 'get-account-balance', which might also retrieve account information but with different scope or detail.
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 description provides no guidance on when to use this tool versus alternatives like 'get-account-balance' or 'create-token'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sell a Pump.fun token
| Name | Required | Description | Default |
|---|---|---|---|
| accountName | No | Name of the account to use | default |
| sellAmount | Yes | Amount of tokens to sell (0 for all) | |
| slippageBasisPoints | No | Slippage tolerance in basis points (1% = 100) | |
| tokenAddress | Yes | The token's mint address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Sell a Pump.fun token' implies a financial transaction with potential consequences, but doesn't disclose critical behaviors like whether this is irreversible, requires authentication, has rate limits, or what happens on failure. The description mentions no behavioral traits beyond the basic action, leaving significant gaps for a financial tool.
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 description is a single, efficient sentence that states exactly what the tool does without any wasted words. It's appropriately sized for a straightforward financial transaction tool and is perfectly front-loaded with the core action. Every word earns its place in conveying the essential purpose.
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 financial transaction tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after selling (e.g., where funds go, confirmation process), error conditions, or return values. The combination of a potentially destructive financial operation with minimal contextual information creates significant gaps for safe and effective use.
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 fully documents all 4 parameters. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain parameter relationships, provide examples, or clarify edge cases. This meets the baseline for high schema coverage but doesn't add value beyond the structured data.
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 clearly states the action ('sell') and resource ('Pump.fun token'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'buy-token' and 'create-token' by specifying the opposite financial transaction. However, it doesn't specify what type of token (e.g., cryptocurrency) or platform context beyond 'Pump.fun', which slightly limits specificity.
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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing tokens to sell, account setup, or market conditions. While the tool name implies it's for selling tokens, there's no explicit context about when this operation is appropriate versus using 'buy-token' or other financial tools.
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.
v1.0.0buy-tokencreate-tokenget-account-balanceget-token-infolist-accountssell-tokenScored across 6 tools
Each tool has a clearly distinct purpose with no overlap: buying, selling, creating tokens, getting token info, getting account balances, and listing accounts. The actions and targets are well-defined and unambiguous.
Most tools follow a consistent verb_noun pattern (e.g., buy-token, create-token, get-token-info, sell-token). However, 'list-accounts' uses 'list' instead of 'get' for consistency with 'get-account-balance', and 'get-account-balance' includes a hyphenated compound noun, causing minor deviations.
With 6 tools, this server is well-scoped for managing Pump.fun tokens and accounts. Each tool serves a clear, essential function, and the count is appropriate for the domain without being excessive or insufficient.
The toolset covers core token operations (create, buy, sell, get info) and account management (balance, listing), providing good coverage. A minor gap is the lack of update or delete operations for tokens or accounts, but agents can likely work around this for basic workflows.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Pay-per-call MCP tools over x402 (USDC/Solana): LLM, utilities, x402 market and model prices.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.