Rug-check & launch radar for trading agents: composite honeypot score, EVM+Solana, keyless x402.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.7/5 across 7 of 7 tools scored.
Each tool has a distinct purpose: catalog for pricing, launch_radar for discovery, rug_check for detailed analysis, vet_token for pre-trade decision, track_record and truth for transparency, and weather_consensus for unrelated weather data. No overlap in functionality.
All tool names follow a consistent pattern of lowercase with underscores (e.g., launch_radar, rug_check, vet_token). Even single-word names like catalog and truth fit the pattern without deviation.
Seven tools is a well-scoped count for the server's purpose. Each tool serves a necessary function without redundancy, and the set is neither too sparse nor overwhelming.
The tool set covers the full lifecycle for rug protection: discovery (launch_radar), detailed analysis (rug_check), pre-trade vetting (vet_token), and transparency (track_record, truth). The weather tool adds unrelated but still useful functionality.
catalogAInspectFREE: what x402-seller sells, prices, and how to pay. The paid HTTP API is keyless (pay per call in USDC on Base via x402).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the tool is free and contrasts with a paid API, but does not disclose whether it requires authentication, is read-only, or has rate limits.
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 two concise sentences, front-loaded with the core purpose, and every word adds value. No wasted space.
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 output schema and no parameters, the description covers the essential purpose and pricing model. However, it could be more complete by hinting at the output format or structure.
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. The description adds value by explaining the output contains items, prices, and payment methods, which is more informative than the empty schema alone.
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 retrieves a catalog of what x402-seller sells, including prices and payment methods. It differentiates from sibling tools like launch_radar or rug_check, which are unrelated.
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 this tool is free and for querying a seller's catalog, but does not explicitly state when to use it over siblings or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
launch_radarAInspectDiscover what just launched AND rug-screen it in one call: fresh token launches ranked by liquidity depth (deepest first), with a per-token rug verdict, each with a verdict (a clean contract with unlocked LP is caution, not clear — most fresh rugs are liquidity pulls). The proactive 'safe alpha' feed. FREE demo (shared daily budget).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the rug verdict logic ('a clean contract with unlocked LP is caution, not clear — most fresh rugs are liquidity pulls') and ranking by liquidity depth. It does not mention data freshness, rate limits, or potential side effects, but the core behavioral traits are 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with minimal wasted words. It front-loads the main action and key features. However, it could be more structured (e.g., bullet points) for easier parsing, and the final 'FREE demo' line is slightly out of place.
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 description covers the tool's purpose and main behavioral nuance but omits details about return format (e.g., structure of the rug verdict) and does not clarify how the single parameter affects output. Given no output schema, these gaps reduce completeness for an agent.
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 sole parameter 'chain' (enum of 7 chains, default 'base') has 0% schema description coverage, and the description does not mention or explain this parameter at all. The agent receives no guidance on how to use or override the default chain, which is a significant gap given low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Discover what just launched AND rug-screen it'), the resource ('fresh token launches'), and the specific behavior ('ranked by liquidity depth... with a per-token rug verdict'). This distinguishes it from siblings like rug_check (individual token check) and catalog (general list).
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 usage for discovering new token launches with safety screening, and includes 'FREE demo (shared daily budget)' suggesting cost awareness, but does not explicitly state when to use versus alternatives or when not to use. No exclusions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rug_checkAInspectDetailed composite rug/honeypot report for one token: red/green flags, 0-100 risk, live-simulation results, disagreement flag. EVM + Solana. FREE demo (shared daily budget).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses supported chains (EVM + Solana) and mentions 'FREE demo (shared daily budget)' indicating rate limits. However, it does not specify the return format, error handling, or whether the tool is read-only.
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 concise sentences. The first front-loads the core purpose and output. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main features (flags, risk score, simulation) but does not describe the output structure. Since there is no output schema, the agent is left to infer the report format. Adequate but not fully comprehensive.
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 0%, so description must compensate. It adds context for 'chain' (EVM + Solana) and implies 'address' is a token contract. But it lacks details on address format, validation rules, or how the default chain ('base') is applied.
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?
Clearly states it provides a 'composite rug/honeypot report' for a token, listing key elements (flags, risk score, simulation results, disagreement flag). Distinguishes itself from sibling tools like 'catalog' or 'truth' by focusing on rug detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'vet_token' or 'weather_consensus'). Lacks context on prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
track_recordCInspectFREE, always: the service's public self-graded track record — its rug verdicts on fresh launches graded against what actually happened, hits AND misses. Judge the scorer by its receipts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions it is 'FREE, always' and 'public'. It fails to disclose authentication requirements, data freshness, or whether it is a read-only operation.
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 sentence but includes metaphorical language ('rug verdicts', 'receipts') that adds flair without enhancing clarity. It could be more direct.
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 absence of an output schema, the description should explain the return format or data fields. It only vaguely describes the content as 'hits AND misses' and 'receipts', leaving the agent uncertain about the structure.
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?
No parameters exist, so baseline 4 applies. The description does not need to add parameter information, as the schema covers 100% of parameters (none).
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 indicates the tool provides the service's public self-graded track record of rug verdicts and their outcomes, distinguishing it from sibling tools like rug_check or truth. However, it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as catalog or weather_consensus. The description does not specify context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
truthAInspectFREE, always: the Truth Engine — every endpoint this service sells grades itself against reality in public (rug verdicts vs actual rugs, weather forecasts vs the ERA5 archive, market calls vs realized spot). Returns the doctrine + all three live ledgers' summaries. Judge us by receipts, not claims.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It implies a read-like operation but does not disclose side effects, auth needs, or rate limits. The phrase 'returns doctrine and summaries' gives some transparency, but not comprehensive.
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 and front-loaded with the key concept. Each sentence contributes useful information, though some repetition could be removed.
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 no parameters and no output schema, the description adequately covers its functionality and return value, making it complete for its simplicity.
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?
No parameters exist, and schema coverage is 100%. The description adds value by explaining the tool's purpose and output, meeting the baseline for zero-parameter tools.
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 is an accountability engine that grades every endpoint against reality, returning doctrine and summaries. It distinguishes itself from sibling tools by focusing on self-verification.
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 does not provide explicit guidance on when to use this tool versus siblings like rug_check or weather_consensus. It states 'FREE, always' implying general availability, but no when-not or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vet_tokenAInspectGo/no-go verdict on a token before trading it: composite rug score (static analysis + live buy/sell simulation + LP-lock/liquidity-pull gate) + market → clear/caution/avoid with reasons. EVM + Solana. FREE demo (shared daily budget); unlimited via the paid HTTP API.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| address | Yes | token contract / mint address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the analysis components (static analysis, live simulation, LP-lock), output categories (clear/caution/avoid with reasons), and pricing tiers (free demo vs paid API). No side effects or auth requirements are mentioned, but the tool appears non-destructive.
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 concise, consisting of three focused sentences. It front-loads the core purpose and immediately provides key details about the analysis and pricing. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-component analysis, cross-chain, pricing), the description covers essential aspects: what it does, how it works, output format, and limitations (shared daily budget). It lacks explicit return schema but gives enough for an agent to decide usage. Without output schema, the output hint is adequate.
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 input schema has 2 parameters: 'address' (required, described as token contract/mint address) and 'chain' (enum with default 'base'). The description adds minimal extra meaning beyond the schema; it mentions 'token contract / mint address' which corresponds to the schema's description. Schema coverage is 50% (only 'address' has a description), so baseline 3 is appropriate.
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: providing a go/no-go verdict on a token before trading via a composite rug score. It distinguishes from siblings like rug_check by detailing a multi-component analysis (static, simulation, LP-lock) and supporting both EVM and Solana. However, it could more explicitly differentiate from rug_check.
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 usage before trading a token and mentions free vs paid access, but it does not explicitly contrast with sibling tools or state when not to use this tool. No exclusion criteria or alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
weather_consensusAInspectCross-source weather consensus for any coordinates: blends Open-Meteo + NOAA/NWS + 7Timer into one temperature with an agreement score (how much independent models agree). Keyless multi-source ground truth in one call — built by the autonomous crew, ported through the bridge. FREE demo (shared daily budget); unlimited via the paid HTTP API ($0.03).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | latitude | |
| lon | Yes | longitude |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels: it discloses the multi-model blending, agreement score, keyless access, and pricing constraints (shared daily budget, $0.03 per call). No contradictions.
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 two sentences, front-loaded with the primary purpose. The second sentence adds useful context but could be slightly more concise. Well-structured overall.
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 output schema, the description explains the result (temperature + agreement score) and the data sources. It is fairly complete for a simple 2-parameter tool, though units and exact output format are omitted.
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% with lat and lon described. The description adds 'any coordinates' but no significant meaning beyond the schema. Baseline 3 is appropriate as the schema already documents parameters well.
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 a specific verb+resource: 'Cross-source weather consensus for any coordinates'. It uniquely distinguishes from sibling tools (catalog, launch_radar, etc.) which are unrelated to weather.
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 usage for obtaining multi-source weather data and mentions free vs paid tiers, but does not explicitly state when not to use it or provide alternatives. However, siblings are unrelated, so no confusion arises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.