Reads the GitHub repository URL from git remote and uses it for project registration and coin description.
Enables pinning token metadata and images to IPFS using a Pinata account or the default hosted endpoint.
Allows launching a token on Solana via pump.fun, including wallet creation, token deployment, fee collection, and token locking through Streamflow.
Optionally includes a Telegram link in the token metadata.
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., "@vibecoin-mcp launch this as a coin"
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.
Launch your vibe coded app on Solana without leaving Claude Code. This MCP server drafts a coin from your repo, deploys it to pump.fun's bonding curve via the PumpPortal Local Transaction API, and recycles your creator fees into an agent budget — with keys that never leave your machine.
Site: https://vibecoin.fun · Projects: https://vibecoin.fun/projects
claude mcp add vibecoin -- npx github:thetriggeredkid-spec/vibecoin-mcp~/.claude.json or .mcp.json){
"mcpServers": {
"vibecoin": {
"command": "npx",
"args": ["github:thetriggeredkid-spec/vibecoin-mcp"]
}
}
}git clone https://github.com/thetriggeredkid-spec/vibecoin-mcp.git
cd vibecoin-mcp && npm install && npm run build
claude mcp add vibecoin -- node /absolute/path/to/vibecoin-mcp/dist/index.jsRestart Claude Code after adding it.
Related MCP server: solana-agent-mcp
Open Claude Code in your project and say "launch this as a coin". The flow:
launch reads README.md, package.json and your git remote, then shows a preview: name, ticker, description, image, links, and the full cost breakdown.
You approve (or tweak any field — everything is overridable).
A wallet is auto-created for this project if none exists. Its encryption password is generated and stored in your macOS Keychain (or a 0600 key file elsewhere), so no interactive password step ever blocks the launch — and the password never appears in the chat.
Metadata (JSON + image) is uploaded, PumpPortal builds the unsigned create transaction, it's signed locally with the mint + creator keys, and submitted to your RPC.
The coin is live on pump.fun; the launch is recorded locally and registered on vibecoin.fun/projects.
Nothing is ever sent without an explicit preview → approve → confirm: true cycle. That applies to launches, transfers, fee claims, swaps and locks alike.
Tool | What it does |
| Create the project's encrypted wallet, check SOL/USDC balances, transfer SOL |
| Draft a coin from the repo and deploy it to pump.fun's bonding curve |
| List every coin launched from this machine with live market data |
| Claim accrued pump.fun creator fees (all coins at once) |
| Collect fees → swap SOL→USDC via Jupiter → hold the budget in the agent's wallet |
| Lock a % of your own tokens via Streamflow; returns a shareable proof link |
| Fee table, config paths, wallet list, links |
What each field does, where it ends up, and who fills it. The launch preview shows this mapping before anything is sent; your agent can override any field via the tool parameters of the same name.
Field | Ends up in | Function & limits | Default source |
| on-chain + metadata JSON | Display name everywhere. Hard on-chain limit 32 chars. | README |
| on-chain + metadata JSON | The $TICKER. Hard on-chain limit 10 chars; 3–8 uppercase is the convention. | Derived from name (initials for 3+ words, blended otherwise) |
| metadata JSON | Body text on the pump.fun coin page and aggregators. Keep ≤ ~500 chars. | First real README paragraph → package.json description |
| metadata JSON | Coin avatar. Square png/jpg/gif/webp, ≤ 1.5 MB. |
|
| metadata JSON | Link box on the coin page — point it at the live app. | package.json |
| metadata JSON | Optional social link on the coin page. | omitted unless provided |
| metadata JSON | Optional social link on the coin page. | omitted unless provided |
| vibecoin registry + appended to description | pump.fun metadata has no native repo field, so the repo URL lives in the vibecoin.fun registry (and /projects), and is appended to the description for visibility on pump.fun itself. | git |
| metadata JSON | Legacy pump.fun display flag; always | fixed |
| metadata JSON | Provenance stamp; coins launched here carry | fixed |
| create transaction | Optional initial buy at the very bottom of the curve (your creator bag). PumpPortal takes 0.5% of it. |
|
Creating a coin is free; ~0.025 SOL of network cost puts it on-chain (~0.04 SOL recommended balance incl. buffer).
Bonding-curve trades cost 1.25%: 0.30% to you, 0.95% to pump.fun.
After graduation (~85 SOL raised → PumpSwap, LP burned) your share is tiered by market cap: up to 0.95%, floor 0.05% above ~$20M.
PumpPortal adds 0.5% on trades routed through its API (dev buys included; creation itself is not charged).
fund-agent swaps via Jupiter (2 bps on SOL→USDC) and keeps the USDC in your wallet. It does not auto-pay any provider — Anthropic/OpenAI bill fiat cards only, and OpenRouter crypto top-ups are a manual checkout on their site.
lock uses Streamflow: ~0.09–0.16 SOL + 0.19–0.5% of the locked tokens (their on-chain fee oracle sets the exact value).
Keypairs are generated locally and stored encrypted (scrypt N=2^15 + AES-256-GCM) under ~/.vibecoin/wallets/ with 0600 permissions.
The encryption password is resolved in order: VIBECOIN_WALLET_PASSWORD env → explicit password param → auto-generated secret in the macOS Keychain (service vibecoin) or ~/.vibecoin/keys/<name>.key (0600).
Auto mode protects the wallet file at rest (a stolen wallets/*.json alone is useless). It does not protect against an attacker with full control of your logged-in user account — set VIBECOIN_WALLET_PASSWORD yourself and delete the stored secret if you want password-only custody.
Transactions are built by PumpPortal/Jupiter as unsigned payloads, signed locally, and submitted to the RPC you configure. Private keys are never transmitted, logged, or included in tool output.
Every value-moving action requires an explicit user-approved confirm: true second call. dry_run builds and simulates without sending.
One fresh wallet per project by default — launches are pseudonymous until you link them.
Variable | Default | Purpose |
|
| RPC for submission/balances. Use a paid endpoint (Helius, Triton…) for reliability. |
|
| Where wallets/launches live. |
| — | Bring-your-own wallet password (skips the stored secret). |
| — |
|
| — | Pin metadata to IPFS via your own Pinata account instead of vibecoin.fun's hosted endpoint. |
| — | Jupiter API key (keyless works at 0.5 req/s). |
|
| Hosted metadata endpoint. |
|
| Launch registry endpoint. |
| — |
|
pump.fun and PumpPortal have no devnet — dry_run (build + mainnet simulation, no send) is the safe rehearsal.
pump.fun's terms restrict commercial transacting on behalf of others; vibecoin is a local tool — you sign for yourself, we never custody anything.
Not financial advice; launching a token is not an investment contract with your users. Ship something real.
MIT
Claim your accrued pump.fun creator fees (0.30% of curve trades, tiered after graduation). pump.fun pays out across all your coins at once. Preview first (no confirm), then call with confirm: true after the user approves.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | Wallet name (default: project directory name) | |
| confirm | No | Set true only after the user approved | |
| dry_run | No | Build + simulate the claim without sending | |
| priority_fee | No | Priority fee in SOL (default 0.00005) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety burden. It discloses the preview behavior and the requirement for user approval before confirm, plus the batching behavior. It stops short of explicitly saying 'broadcasts an on-chain transaction' or irreversible effects, but the core safety-relevant behavior is covered.
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 the primary action and fee context. Every clause earns its place: fee percentage, tiering, payout aggregation, and the preview/confirm ordering.
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 and no output schema, the description adequately covers the fee mechanism, payout scope, and the critical preview/confirm workflow. It could mention prerequisites like having accrued fees or the concrete effect of confirm:true, but the existing coverage is strong for a 4-parameter tool.
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 baseline is 3. The description adds value by operationalizing dry_run and confirm ('Preview first (no confirm), then call with confirm: true'), which is not explicit in the schema. It also provides business context for what the fees are, but does not over-repeat schema details.
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 uses a specific verb ('Claim') with a clear resource ('accrued pump.fun creator fees') and adds fee context (0.30%, tiered) plus batch payout across all coins. This strongly differentiates collect-fees from sibling tools like launch, lock, or fund-agent.
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 gives an explicit workflow: preview first without confirm, then call with confirm:true after user approval. It does not explicitly enumerate when not to use it or alternatives, but the sequencing guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-prompt loop that turns creator fees into an agent budget: optionally collect pending pump.fun fees, then swap SOL→USDC via Jupiter (keeping a gas reserve) so the wallet holds a stable budget. Preview first (no confirm) — it shows the live quote; call with confirm: true after the user approves. Honest by design: the USDC stays in the wallet; it does not auto-pay Anthropic/OpenAI (fiat-only) or OpenRouter.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | Wallet name (default: project directory name) | |
| confirm | No | Set true only after the user approved the preview | |
| dry_run | No | Quote and sign but never execute the swap | |
| keep_sol | No | Gas reserve to keep in SOL (default 0.01) | |
| sol_amount | No | SOL to swap (default: everything above the gas reserve) | |
| slippage_bps | No | Swap slippage in bps (default 100 = 1%) | |
| collect_first | No | Collect pending creator fees before swapping (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It reveals key behaviors: the tool keeps a gas reserve, requires a preview/confirm step, and does not auto-pay AI providers. The statement 'the USDC stays in the wallet; it does not auto-pay Anthropic/OpenAI (fiat-only) or OpenRouter' is a clear and honest disclosure that prevents misuse.
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 three sentences, front-loaded with the core purpose, then procedural details, then an honest caveat. Every sentence contributes value and there is no fluff.
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?
The tool is complex with 7 parameters and no output schema, yet the description covers the main workflow, preview/confirm, gas reserve, and limitations. It does not explicitly describe what the final response contains (e.g., transaction signature), but given the detailed workflow and parameter coverage, the missing piece is minor.
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 baseline is 3. The description adds meaningful context beyond the schema: it explains the purpose of keep_sol ('keeping a gas reserve'), the confirm flow, and collect_first ('optionally collect pending pump.fun fees'). This enriches parameter understanding without contradicting 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?
The description clearly states the tool's purpose: to turn creator fees into an agent budget by optionally collecting pump.fun fees and swapping SOL to USDC via Jupiter. It uses specific verbs and resources, and distinguishes itself from siblings like collect-fees by describing the end-to-end workflow.
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 gives clear workflow guidance: 'Preview first (no confirm) — it shows the live quote; call with confirm: true after the user approves.' It also explains the 'Honest by design' behavior. However, it does not explicitly mention when to use this versus sibling tools like collect-fees or wallet, so it lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Platform overview for vibecoin: what it does, current pump.fun fee structure, config, wallets and links.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It discloses the types of information provided but does not explicitly state that the tool is read-only, whether it returns data in a specific format, or any side effects. The informational nature is implied but not formally stated.
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, well-structured sentence that front-loads the core purpose ('Platform overview for vibecoin') and then efficiently lists its contents. Every part adds value with no redundancy or filler.
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, zero-parameter tool with no output schema, the description is mostly complete. It lists what the overview covers, but some terms like 'config' and 'links' are slightly ambiguous. Overall, it adequately covers the tool's role in the broader context.
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 zero parameters, so the description does not need to explain parameter details. The schema has no properties, and the baseline score for zero-parameter tools is 4, which is appropriate 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 clearly defines the tool as a platform overview for vibecoin, listing distinct content areas (what it does, fee structure, config, wallets, links). This is a specific verb+resource ('platform overview') that differentiates it from the action-oriented sibling tools like launch and wallet.
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 implies the tool is for getting broad platform context, but it does not explicitly state when to use it instead of the sibling tools or provide any exclusions. Use case is inferred rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch the current project as a coin on pump.fun's bonding curve. First call WITHOUT confirm: drafts name/ticker/description/links from the repo (README, package.json, git remote) and returns a full preview with costs. Show that preview to the user, apply any edits they want via the override params, and only after they explicitly approve call again with confirm: true. The wallet is auto-created if missing (encrypted, password stored in Keychain — no interactive step). Metadata is uploaded, the create transaction is built by PumpPortal, signed locally, and submitted to your RPC. dry_run builds and simulates everything but never sends.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Override token name (on-chain limit 32 chars) | |
| github | No | GitHub repo URL — listed on vibecoin.fun/projects and appended to the description | |
| symbol | No | Override ticker (on-chain limit 10 chars; 3-8 uppercase is the convention) | |
| wallet | No | Wallet name (default: project directory name — fresh wallet per project) | |
| confirm | No | Set true ONLY after the user explicitly approved the preview | |
| dry_run | No | Build + simulate the create transaction without sending it | |
| No | Twitter/X link for the coin page (optional) | ||
| website | No | Live URL of the project — becomes the coin's website link | |
| telegram | No | Telegram link for the coin page (optional) | |
| image_path | No | Path to a square logo (png/jpg/gif/webp ≤1.5MB). Defaults to a repo logo or a bundled placeholder | |
| description | No | Override description shown on pump.fun (keep ≤ 500 chars) | |
| dev_buy_sol | No | Initial dev buy in SOL (default 0). PumpPortal charges 0.5% on this | |
| project_dir | No | Project directory to draft from (default: current working directory) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the transparency burden. It discloses the two-phase behavior (preview vs. confirm), that the first call is safe (returns preview with costs), that confirm: true sends a real transaction, that wallet auto-creation is encrypted and non-interactive, and that dry_run never sends. This is rich behavioral disclosure beyond what a schema could convey.
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 dense but every sentence serves a purpose: purpose statement, two-step workflow, wallet creation detail, transaction mechanics, and dry_run explanation. It is well-structured chronologically and avoids fluff, making it appropriately sized for a tool with 13 parameters and a multi-step process.
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 13 parameters, no output schema, and no annotations, the description does a strong job covering the workflow, side effects (wallet creation, transaction submission), and safety (dry_run). It lacks details on the preview structure and post-submission behavior, but the overall process is clearly enough for an agent to operate correctly.
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 covers 100% of parameters with individual descriptions, so the baseline is 3. The tool description adds meaning by explaining that parameters act as 'override params' in the two-step flow, tying them to the repo-drafting behavior. It reinforces that confirm and dry_run control execution, which goes slightly beyond the schema descriptions.
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 tool's purpose: 'Launch the current project as a coin on pump.fun's bonding curve.' It uses a specific verb (launch), a clear resource (current project as a coin), and context (pump.fun's bonding curve). This distinguishes it from sibling tools like wallet, info, and my-coins, which serve different functions.
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 explicit usage guidance: first call without confirm to draft and preview, apply edits via override params, and only call again with confirm: true after user approval. It also explains dry_run for simulation and notes the wallet auto-creation process, giving clear context on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prove you're not dumping: lock a percentage of your own creator-held tokens for a chosen duration via Streamflow (third-party on-chain locker) and get a shareable proof link. Irrevocable until the unlock date. Preview first (no confirm); call with confirm: true after the user approves. Streamflow charges ~0.09-0.16 SOL plus 0.19-0.5% of the locked tokens (their on-chain fee oracle decides).
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | Lock duration in days (e.g. 90, 180, 365) | |
| mint | No | Token mint to lock (default: your most recent launch) | |
| wallet | No | Wallet name (default: project directory name) | |
| confirm | No | Set true only after the user approved the preview | |
| dry_run | No | Preview the exact lock parameters without touching the chain | |
| percent | Yes | Percentage of your current token balance to lock |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses irrevocability until unlock date, Streamflow's fee structure (0.09-0.16 SOL plus 0.19-0.5%), and the preview/confirm flow. This goes well beyond the schema and annotations (none provided), carrying the full burden of behavioral 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?
Three sentences, all relevant, front-loaded with purpose. Fee details are a bit dense but necessary.
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?
Covers purpose, workflow, fees, and irreversibility, with no output schema. Missing details like proof link format, but overall solid for a moderately complex on-chain tool.
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 coverage is 100%, so baseline is 3. The description adds marginal context about the confirm/dry_run relationship but doesn't add detail to individual params 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?
The description clearly states it locks a percentage of creator-held tokens via Streamflow for a duration and produces a proof link, distinguishing it from sibling tools like launch or collect-fees.
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?
It gives context ('Prove you're not dumping') and a clear workflow: preview first, then confirm with confirm: true after approval. It doesn't explicitly name alternatives or exclusions, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every coin launched from this machine, with live market data (price, market cap, 24h volume).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys the read-only nature through the verb 'List' and states the return data includes live market data. It does not mention any exclusions or edge cases, but for a simple list operation this is sufficient.
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 front-loaded sentence that efficiently communicates both the action and the returned data without wasted words.
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 zero-parameter interface and simple read-only nature, the description fully explains what the tool does and what it returns. No output schema exists, but the listed fields (price, market cap, volume) cover typical market data.
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 zero parameters, so there is no need for parameter-level guidance. The description clarifies the scope ('from this machine') and return data, which is more than the empty schema provides.
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 uses a specific verb ('List') and clearly identifies the resource ('every coin launched from this machine'). It distinguishes from siblings like 'launch' (creation) and 'wallet' (balances) by focusing on the machine's launched coins and adding live market data.
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 clearly implies when to use: to view all previously launched coins from this machine. It does not explicitly mention alternatives, but the scope is unambiguous in context of sibling tools like 'launch' and 'wallet'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage the project's local encrypted Solana wallet: create, status, balance, or transfer SOL. Wallets are encrypted at rest (scrypt + AES-256-GCM); the password is auto-generated and stored in the macOS Keychain (or a 0600 key file), so no interactive step is ever needed. Transfers require a preview + explicit user approval (call once without confirm, show the preview, then call again with confirm: true).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Transfer only: recipient Solana address | |
| sol | No | Transfer only: amount of SOL to send | |
| name | No | Wallet name — defaults to the current project directory name | |
| action | Yes | What to do | |
| confirm | No | Transfer only: set true only after the user approved the preview | |
| dry_run | No | Transfer only: build and simulate but never send | |
| password | No | Optional password override. Discouraged: prefer the auto-generated stored password or VIBECOIN_WALLET_PASSWORD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It covers encryption at rest (scrypt + AES-256-GCM), auto-generated password storage (macOS Keychain or 0600 key file), non-interactive operation, and the two-step transfer approval flow. This is comprehensive and proactively surfaces important behaviors.
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 tightly pack purpose, security details, and a critical workflow nuance. Every sentence earns its place: the first states the tool's function, the second explains persistence/security without fluff, and the third details the required transfer approval process. No wasted words.
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 tool has 7 parameters and no output schema, the description covers the essential context: actions, security model, and workflow. It doesn't explain return values, but that's less critical for a wallet tool, and the schema already documents each parameter. The description is sufficient for an agent to invoke the tool correctly, though it could mention dry_run's purpose explicitly.
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 coverage is 100%, so the baseline is 3. The description adds valuable meaning beyond the schema by clarifying the 'confirm' parameter's role in the two-step approval flow and explaining that 'password' is an override to an auto-generated stored password. This enriches the otherwise schema-only definitions.
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 opens with a specific verb and resource: 'Manage the project's local encrypted Solana wallet' followed by the concrete actions (create, status, balance, transfer SOL). This clearly differentiates it from sibling tools like 'collect-fees' or 'launch' by specifying the wallet management scope.
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 clear workflow guidance for transfers: call once without confirm to preview, then call again with confirm: true after approval. It does not explicitly mention when not to use this tool or compare with alternatives, but the action enum and context make the intended usage clear.
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.0collect-feesfund-agentinfolaunchlockmy-coinswalletScored across 7 tools
Each tool targets a distinct workflow: claiming fees, launching, managing wallet, listing coins, funding agent, locking tokens, and platform info. While collect-fees and fund-agent both involve fee collection, their purposes are clearly separated (claiming vs. setting up a budget), so misselection is unlikely.
Tool names mix verb phrases (launch, lock, collect-fees, fund-agent) with nouns (info, wallet, my-coins). The lowercase hyphenated style is consistent, but there is no uniform verb_noun pattern, so agents may not predict the action from the name alone.
Seven tools is well within the ideal 3-15 range for a focused server, and each tool serves a distinct, non-redundant function in the creator workflow.
The surface covers the full lifecycle: launching, monitoring coins, claiming fees, wallet management, and proof-of-lock. However, the wallet tool only supports SOL transfers, leaving USDC acquired via fund-agent without an obvious exit path, which is a minor but notable gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
7 agent tools (prune, convert, estimate, diff, patch, generate, validate). USDC on Base L2.
Native Solana staking for AI agents. 26 MCP tools, one-shot signing, webhooks.
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
Solana memecoin rug check for trading agents: pump.fun launches, calibrated rug risk, wallets, KOL.
