vibecoin-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.5/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![vibecoin-mcp MCP server](https://glama.ai/mcp/servers/thetriggeredkid-spec/vibecoin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/thetriggeredkid-spec/vibecoin-mcp)

Score Badge

Copy to your README.md:

[![vibecoin-mcp MCP server](https://glama.ai/mcp/servers/thetriggeredkid-spec/vibecoin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/thetriggeredkid-spec/vibecoin-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/thetriggeredkid-spec/vibecoin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server