memecoin-radar-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have clear distinctions in their primary focus (Pump.fun graduates, KOL activity, trending tokens by source/platform), but there is some overlap in purpose. For example, get_pumpfun_graduates_by_marketcap and get_pumpfun_graduates_by_trading_volume both retrieve Pump.fun graduates with different sorting criteria, which could cause confusion if an agent needs general graduate data without a specific sorting preference. The descriptions help clarify, but the boundaries between tools like get_trending_tokens_by_kol_trading_volume and get_recent_kol_buys are somewhat fuzzy, as both relate to KOL activity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with 'get_' prefix, using snake_case throughout. The naming is predictable and clear, such as get_pumpfun_graduates_by_marketcap and get_trending_tokens_on_raydium, making it easy for agents to understand the action and target resource without confusion.
Tool Count4/5
With 8 tools, the count is reasonable for a memecoin tracking server, covering multiple aspects like graduates, KOL activity, and trending tokens across platforms. It's slightly on the higher side but well-scoped, as each tool serves a distinct query type. However, it might feel a bit heavy for a narrow domain, but not excessively so.
Completeness3/5
The tool set provides good coverage for retrieving data on memecoin trends, graduates, and KOL activity, but there are notable gaps. It lacks tools for creating, updating, or deleting data (e.g., no way to add custom alerts or track specific tokens), which limits it to read-only operations. While this might be intentional for a radar server, the surface feels incomplete for full lifecycle management or interactive features beyond basic queries.
Average 4.3/5 across 8 of 8 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?
With no annotations provided, the description carries full burden and does well by disclosing: the data source (Dune API), error behavior (returns error message on query failure), specific exception type (httpx.HTTPStatusError), and return format (formatted table with specific columns). It doesn't mention rate limits or authentication needs, but provides substantial behavioral 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 efficiently structured with a clear purpose statement followed by organized sections for Args, Returns, and Raises. Every sentence serves a distinct purpose with zero wasted words, making it easy to parse.
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 single-parameter read operation with no output schema, the description provides excellent context: clear purpose, parameter explanation, return format details, and error handling. The only minor gap is lack of explicit sibling tool differentiation, but overall it's highly complete for its complexity level.
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?
With 0% schema description coverage for the single parameter, the description fully compensates by explaining the 'limit' parameter's purpose ('Maximum number of tokens to return') and default value (100). This adds complete meaning beyond the bare 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 specific action ('Retrieve'), resource ('Pump.fun token launches'), and key sorting criteria ('sorted by highest trading volume in the last 24 hours'). It distinguishes itself from siblings like 'get_pumpfun_graduates_by_marketcap' by specifying the volume-based sorting approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the sorting criteria (24-hour trading volume), but doesn't explicitly state when to use this tool versus alternatives like 'get_pumpfun_graduates_by_marketcap' or 'get_recent_pumpfun_graduates'. No explicit exclusions or prerequisites are provided.
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 of behavioral disclosure. It effectively describes the return format (formatted table with specific fields), error handling (error message on query failure), and external dependencies (Dune API request). However, it doesn't mention rate limits, authentication needs, or data freshness, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises) and front-loaded purpose. It's appropriately sized, but the 'Raises' section could be slightly more concise, and the overall text is efficient with minimal waste.
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's moderate complexity (1 parameter, no output schema, no annotations), the description is largely complete. It covers purpose, parameters, return format, and error handling. However, it could improve by adding more behavioral context like rate limits or data sources, though the lack of annotations and output schema is adequately addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains the 'limit' parameter's purpose ('Maximum number of buy transactions to return'), default value (100), and context, fully compensating for the schema's lack of descriptions and providing clear parameter semantics.
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 specific action ('Retrieve recent token purchases') and the resource ('by memecoin Key Opinion Leaders (KOLs)'). It distinguishes this tool from sibling tools that focus on trending tokens or pumpfun graduates, making its purpose unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving KOL buy data, but provides no explicit guidance on when to use this tool versus alternatives like sibling tools for trending tokens or graduates. It lacks context on prerequisites, exclusions, or specific scenarios where this tool is preferred.
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 full burden and does well by disclosing key behaviors: it describes the return format (formatted table with specific columns), mentions error handling (error message if query fails), and reveals external dependencies (Dune API with httpx.HTTPStatusError potential). It doesn't cover rate limits, caching, or authentication needs, but provides substantial operational 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 efficiently structured with a clear purpose statement followed by organized sections (Args, Returns, Raises). Every sentence adds value: the first defines the tool's function, and subsequent sections provide essential usage details without redundancy. It's front-loaded with the core functionality.
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's moderate complexity (1 parameter, no output schema, no annotations), the description is largely complete. It covers purpose, parameter semantics, return format, and error conditions. However, it lacks explicit guidance on when to choose this tool over siblings, and doesn't mention performance characteristics like response time or data freshness, leaving minor gaps.
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 description adds meaningful semantics beyond the input schema's 0% coverage. It explains that 'limit' controls the 'maximum number of tokens to return' and provides the default value (100), which clarifies the parameter's purpose and typical usage. Since schema coverage is 0%, this compensation is effective, though it doesn't detail constraints like minimum/maximum values.
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 specific action ('Retrieve tokens with the highest trading volume by memecoin KOLs'), identifies the resource (tokens), and distinguishes from siblings by specifying the unique KOL trading volume focus. It's more specific than general trending token tools like get_trending_tokens_by_source or get_trending_tokens_on_pumpswap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'tokens with the highest trading volume by memecoin KOLs,' suggesting this tool is for analyzing influencer-driven trading activity. However, it doesn't explicitly state when to use this versus alternatives like get_recent_kol_buys (which might show individual buys) or other trending token tools that use different metrics (e.g., market cap or general volume).
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 full burden and does well by disclosing: the tool queries Dune API, returns a formatted table or error message, and raises specific exceptions (ValueError, httpx.HTTPStatusError). It doesn't mention rate limits, authentication needs, or data freshness, but provides substantial behavioral context beyond basic functionality.
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?
Well-structured with clear sections (description, Args, Returns, Raises), front-loaded purpose statement, and every sentence earns its place. No redundant information - each section provides distinct value in minimal space.
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 2-parameter tool with no annotations and no output schema, the description provides excellent coverage: clear purpose, parameter details, return format, and error conditions. It could improve by mentioning data source limitations or typical response time, but is largely complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics: time_span options ('5h', '12h', '24h') with default, limit parameter purpose with default, and clear formatting of the Args section. This adds significant value beyond the bare schema which only shows types and titles.
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 specific action ('Retrieve tokens with the highest trading volume'), target resource ('on PumpSwap'), and scope ('within a specified time span'). It distinguishes from sibling tools by specifying the platform (PumpSwap) rather than other platforms like Raydium or different metrics like KOL trading volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the time span parameter options and mentions retrieving tokens with highest trading volume, but doesn't explicitly state when to use this tool versus alternatives like 'get_trending_tokens_on_raydium' or 'get_trending_tokens_by_kol_trading_volume'. No explicit guidance on when-not-to-use or comparisons with siblings is provided.
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 full burden and does well by disclosing: the tool queries an external API (Dune), returns formatted table data or error messages, and raises specific exceptions for invalid inputs or API failures. It doesn't mention rate limits or authentication needs, but covers key behavioral aspects.
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 efficiently structured with a clear purpose statement followed by well-organized sections (Args, Returns, Raises). Every sentence adds value—no redundancy or fluff. It's appropriately sized for a tool with two parameters and no annotations.
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 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is largely complete: it explains purpose, parameters, return format, and errors. It could slightly improve by mentioning sibling tools for context, but covers essential aspects well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for both parameters: time_span with allowed values ('5h', '12h', '24h') and defaults, and limit with purpose and default. This adds significant meaning beyond the bare 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 specific action ('Retrieve tokens with the highest trading volume'), target resource ('on Raydium'), and scope ('within a specified time span'). It distinguishes from siblings by specifying the Raydium platform, unlike tools for Pumpfun or Pumpswap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (tokens with high trading volume on Raydium) but doesn't explicitly state when to use this tool versus alternatives like 'get_trending_tokens_on_pumpswap' or volume-based tools for other platforms. No explicit when-not-to-use guidance is provided.
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 of behavioral disclosure. It effectively describes the tool's behavior: it retrieves data from Dune API, returns a formatted table or error message, and can raise HTTP errors. It covers key aspects like data source, output format, and error handling, though it lacks details on rate limits or authentication needs.
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 well-structured and front-loaded with the core purpose, followed by organized sections for Args, Returns, and Raises. Every sentence adds value without redundancy, making it efficient and easy for an agent to parse.
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's moderate complexity (one parameter, no output schema, no annotations), the description is largely complete. It explains the purpose, parameter, return format, and error handling. However, it could improve by mentioning data freshness or limitations, such as the exact timing of the 24-hour window or potential API constraints.
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 description coverage is 0%, so the description must compensate. It clearly explains the 'limit' parameter's purpose ('Maximum number of tokens to return') and default value, adding meaningful semantics beyond the basic schema. Since there is only one parameter, this is sufficient for effective use.
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 specific action ('Retrieve'), resource ('Pump.fun token launches'), and key sorting criteria ('sorted by highest market capitalization in the last 24 hours'). It distinguishes from sibling tools like 'get_pumpfun_graduates_by_trading_volume' by specifying the market cap focus, making the purpose unambiguous.
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 usage context by specifying 'in the last 24 hours' and sorting by market cap, which helps differentiate it from siblings like 'get_recent_pumpfun_graduates' (likely unsorted or differently sorted). However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions, leaving some ambiguity for the agent.
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 full burden and does well by disclosing: the 24-hour time window constraint, the formatted table output structure, error handling behavior, and specific API dependencies (Dune API). It doesn't mention rate limits or authentication requirements, but covers most essential behavioral aspects.
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?
Perfectly structured with purpose statement, args section, returns section, and raises section. Every sentence earns its place by providing essential information without redundancy. The information is front-loaded with the core functionality stated first.
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?
For a single-parameter read operation with no output schema, the description provides complete context: purpose, parameter semantics, return format details, error conditions, and API dependencies. It addresses all necessary aspects given the tool's complexity and lack of structured annotations.
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?
With 0% schema description coverage for the single parameter, the description fully compensates by explaining the 'limit' parameter's purpose, default value, and effect. It adds meaning beyond the bare schema by clarifying this controls the maximum number of tokens returned.
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 specific action ('Retrieve'), resource ('most recently graduated tokens from Pump.fun'), and temporal scope ('in the last 24 hours'). It distinguishes this tool from its siblings by focusing on recency rather than marketcap, volume, or trending metrics.
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 about when to use this tool (for recent graduates within 24 hours), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. The temporal scope helps differentiate from other graduate-related tools.
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 of behavioral disclosure. It effectively describes the tool's behavior: time-bound query (last 12 hours), default values, error conditions (ValueError for invalid source, HTTPStatusError for API failure), and return format (formatted table or error message). It doesn't mention rate limits or authentication requirements, but covers core operational behavior well.
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 efficiently structured with a clear purpose statement followed by well-organized sections (Args, Returns, Raises). Every sentence adds value: the opening establishes scope, parameter sections provide essential details, and error documentation helps anticipate failures. 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?
For a 2-parameter tool with no annotations and no output schema, the description provides complete context. It covers purpose, parameters with semantics and constraints, return format, error conditions, and temporal scope. The agent has all necessary information to invoke this tool correctly without needing additional structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It explains both parameters (source and limit), specifies allowed values for source ('Telegram', 'Web', 'Mobile'), indicates defaults, and describes their purpose in the context of the query.
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 specific action ('Retrieve top traded tokens'), resource ('on specified source platform'), and temporal scope ('in the last 12 hours'). It explicitly distinguishes this tool from sibling tools by focusing on source platforms rather than other criteria like KOL trading volume or specific exchanges like PumpSwap/Raydium.
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 about when to use this tool (querying trending tokens by source platform with 12-hour recency). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the distinction is implied through the different query criteria.
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:

[![memecoin-radar-mcp MCP server](https://glama.ai/mcp/servers/kukapay/memecoin-radar-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kukapay/memecoin-radar-mcp)

Score Badge

Copy to your README.md:

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

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