DumbMoney MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action: list_tokens provides an overview, get_token drills into a specific mint, check_earnings focuses on a wallet's pending rewards, top_earners is a ranking, create_token launches a new token, register_agent handles account creation, and get_my_agent_info shows the agent's profile. No two tools have overlapping primary purposes.
Naming Consistency4/5
The vast majority follow a clear verb_noun snake_case pattern (list_tokens, get_token, check_earnings, create_token, register_agent, get_my_agent_info). The exception is top_earners, which uses an adjective_noun form instead of a verb_noun form, causing a minor inconsistency.
Tool Count5/5
With 7 tools, the server is well-scoped for its purpose. It provides enough functionality to cover token discovery, earnings tracking, token creation, and agent management, without unnecessary bloat or gaps.
Completeness4/5
The tool surface covers the core workflows: listing and inspecting tokens, checking earnings, creating tokens, and managing agent credentials. Minor gaps exist, such as no tool to list tokens created by the agent or a direct action to claim pending reflections, but these do not severely block main use cases.
Average 4.3/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
- 0 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
This repository is licensed under MIT License.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explicitly states the return values (pending SOL/USD earnings, share percentage, holder shares) and the edge case of returning zeros when the wallet has no position. It does not mention auth or rate limits, but for a read-only check this is sufficient context.
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 composed of three concise sentences: the first states the purpose, the second lists return fields, and the third clarifies the zero-value behavior. Every sentence contributes meaningful information without redundancy or 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?
Given that there is no output schema and no annotations, the description adequately covers the tool's purpose, return values, and an important edge case. It could mention potential errors or prerequisites (e.g., valid address formats), but those are already in the schema, making the description sufficiently complete for a simple check operation.
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 input schema already provides 100% coverage for both parameters (mint and wallet) with clear descriptions. The tool description does not add additional meaning or syntax details beyond what the schema provides, so the baseline score of 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 uses a specific verb ('Check') and resource ('a wallet's pending reflection earnings for a specific DumbMoney token'), clearly distinguishing it from sibling tools like top_earners (which lists top earners) and list_tokens (which lists tokens). It leaves no ambiguity about what action is performed.
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 context for when to use this tool: when needing to check a wallet's pending earnings for a specific token. However, it does not explicitly mention alternatives or when not to use it, so it lacks the explicit exclusion guidance seen in the highest-scoring examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does mention the API key requirement and the types of information returned, which is useful. However, it does not explicitly state that the operation is read-only, nor does it describe error behavior, rate limiting for the call itself, or whether the API key is used in headers or parameters. This leaves some behavioral ambiguity.
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 two sentences, front-loaded with the core purpose, and adds the API key requirement without redundancy. Every word earns its place; there is no filler or unnecessary detail.
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 there is no output schema, the description appropriately lists the return contents (agent profile, token creation count, remaining rate limits). For a simple getter with no parameters, this is largely sufficient. It could be more detailed about the profile structure or format, but the core functionality is well covered.
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 are no parameter semantics to describe. According to the rubric, a baseline of 4 applies for 0-param tools. The description adds context by mentioning the required API key, which is not a schema parameter but an environmental prerequisite, giving agents extra operational guidance.
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 what the tool does: it retrieves the agent's profile, token creation count, and remaining rate limits. The verb 'Get' is specific, the resource is 'your agent info', and the scope is well-defined, distinguishing it from sibling tools like list_tokens or get_token which focus on token lists or individual tokens.
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 context for when to use this tool (when you need your own agent details and rate limits) and includes a prerequisite (DUMBMONEY_API_KEY must be set). However, it does not explicitly contrast it with alternatives like list_tokens or check_earnings, so it lacks explicit when-not-to-use guidance.
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 provided, the description carries the burden. It explicitly says what the tool returns (on-chain data including specific metrics), which is transparent about the read-only nature. It does not mention error cases or data freshness, but for a simple getter this is acceptable.
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 two sentences: the first states the purpose and the second lists the return fields. It is front-loaded, efficient, and free of 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?
Given the low complexity (one parameter, no output schema), the description is complete enough by naming the key return fields. It does not cover error conditions or null cases, but these are not critical for a simple getter. It could mention when to use it relative to list_tokens, but the purpose is clear.
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 schema already describes the mint parameter with a pattern and description, and coverage is 100%. The description adds context that the mint is a Solana address, but this is also in the schema, so it adds marginal value beyond the structured data.
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 states a specific verb and resource: 'Get detailed info about a specific DumbMoney reflection token'. It clearly differentiates from siblings like list_tokens (which presumably lists tokens) by focusing on a single token by mint address.
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 implies the tool is for retrieving details on one specific token when you have its mint address, which provides clear context. It does not explicitly name alternatives or exclusions, but the focus on 'specific' and the mint address makes the usage scenario obvious.
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 provided, the description carries the transparency burden. It discloses key behavioral traits: the API key is shown only once (so it must be saved securely), and no prior authentication is needed. This goes beyond basic purpose and gives critical operational details, though it doesn't describe the exact response format or post-registration actions.
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 long, front-loaded with the core purpose, and every sentence adds value (purpose, one-time key warning, auth note). No wasted words or redundant information.
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 straightforward registration tool with three parameters and no output schema, the description covers the essential context: what the tool does, the one-time API key behavior, and authentication requirements. It lacks an explicit mention of the response contents but implies them, making it reasonably complete for the tool's complexity.
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 input schema has 100% coverage, with all three parameters (name, fee_wallet, description) described adequately. The tool description itself adds no additional parameter semantics beyond what the schema provides, so a baseline score of 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 clearly states the tool's purpose: registering as a new agent on DumbMoney to obtain an API key for creating tokens. This distinguishes it from sibling tools like list_tokens or get_my_agent_info, making its function evident.
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 context for when to use this tool (when you need to register and get an API key) and mentions that no authentication is required. However, it does not explicitly exclude alternate tools or explain when not to use it, such as when you already have an API key.
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 burden of disclosing behavior. It clearly states that the tool creates an on-chain token, requires an API key, and that the server handles image upload and metadata. This gives a good sense of the side effects and prerequisites, though it doesn't mention error handling or whether the action is irreversible.
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 concise and front-loaded, beginning with the core purpose and immediately providing essential context about on-chain creation, API key requirement, and image options. Every sentence contributes useful information without unnecessary fluff.
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?
Despite having 10 parameters and no output schema, the description does not mention what the response format is (e.g., token address). Additionally, 'Provide one of' is ambiguous regarding whether an image is strictly required, since the schema only requires name and symbol. These are notable gaps for a creation 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?
The schema already covers 100% of the parameters, but the description adds semantic value by explaining the mutual exclusivity of image inputs and that the server manages the uploads. This goes beyond the schema's individual property descriptions, earning a score above the 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 states the tool's function with a specific verb and resource: 'Launch a new reflection token on DumbMoney' and 'Creates the token on-chain with Token-2022 transfer fees.' This distinguishes it from sibling tools like list_tokens and get_token, which are read-only operations.
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 usage context by requiring DUMBMONEY_API_KEY and instructing to 'Provide one of: image_url, image_base64, or dalle_prompt.' It does not explicitly discuss when not to use this tool or name alternatives, but the purpose is clear enough that an agent can infer when to invoke it.
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 full burden. It clearly states that the tool lists tokens and returns specific data, implying a non-mutating read operation. It does not mention pagination or error cases, but for a zero-parameter list operation, the core behavior is well disclosed.
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 stating the action and then listing exactly what will be returned. Every word provides useful information, and there is no redundancy or bloat.
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 tool's simplicity (no parameters, no output schema), the description is complete: it names the platform, the scope ('all reflection tokens'), and all relevant return fields. No critical information is missing for an agent to select and invoke this tool 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 tool has zero parameters, and the input schema is empty. The description correctly needs no parameter details, and the baseline of 4 applies for the no-parameter case.
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 action ('List all reflection tokens') and a clear resource ('on DumbMoney'), and enumerates the returned fields. This makes the tool's purpose immediately obvious and distinguishes it from sibling tools like get_token, which presumably targets a single token.
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 makes the primary use case clear: obtain an overview of all reflection tokens. It does not explicitly mention alternatives or exclusions, but the 'all' scope and field list leave no ambiguity about when to use this tool versus get_token for specific token details.
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 provided, the description carries the full burden. It discloses the core behavior: returns a top-10 list ordered by reflections paid. It also implies read-only behavior ('Get', 'Shows'). For a simple retrieval tool with no parameters, this is adequate disclosure, though it doesn't mention potential caveats like data freshness or authentication.
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 two concise sentences, front-loaded with the primary action. Every sentence adds value: the first states the core function, the second clarifies the significance ('passive income'). No 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 zero parameters, no output schema, and a straightforward listing task, the description fully captures what the tool returns and how it's ranked. It also distinguishes it from sibling tools by focusing on 'top earners.' The lack of an output schema is not an issue because the description explicitly states the scope (top 10) and the metric.
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, and the schema is empty. The baseline for 0 params is 4, as there is nothing for the description to add beyond what the schema doesn't show. The description does not need to explain parameter meaning because none exist.
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 function: 'Get the top 10 DumbMoney tokens ranked by total reflections paid to holders.' It uses a specific verb ('Get'), identifies the resource ('top 10 DumbMoney tokens'), and specifies the ranking criterion. This distinguishes it from sibling tools like list_tokens or get_token.
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 context for when to use this tool: when you want to see which tokens have generated the most passive income for holders. Although it doesn't explicitly mention alternatives, the context is strong enough that an agent would know to use this tool for top-earner ranking, and it's unlikely to be confused with other siblings.
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:

[![dumbmoney-mcp MCP server](https://glama.ai/mcp/servers/errick0x/dumbmoney-mcp/badges/card.svg)](https://glama.ai/mcp/servers/errick0x/dumbmoney-mcp)

Score Badge

Copy to your README.md:

[![dumbmoney-mcp MCP server](https://glama.ai/mcp/servers/errick0x/dumbmoney-mcp/badges/score.svg)](https://glama.ai/mcp/servers/errick0x/dumbmoney-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/errick0x/dumbmoney-mcp'

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