rugcheck-ai
Server Details
Solana token safety for AI agents — rug-pull, honeypot & Token-2022 trap detection before you buy.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.1/5 across 15 of 15 tools scored. Lowest: 2.4/5.
Several tools overlap in purpose, particularly scan_token and verify_token_safety both offering a full safety verdict. Tools like is_safe, batch_scan, and compare_tokens also reuse aspects of the core scan, creating ambiguity about which to use for a given task.
Tool names are inconsistent in style: some use verb_noun (scan_token, simulate_sell), others are noun phrases (holders_breakdown, rug_forecast) or mixed (verify_token_safety, execute_safe_swap). Underscores are used sporadically, and names like 'scammer_dna' lack clarity.
With 15 tools focused on token safety analysis, the count is appropriate for covering various aspects without being overwhelming. The scope is well-defined, and each tool addresses a specific need, though some consolidation could reduce redundancy.
The server covers the full lifecycle of token safety analysis: scanning, specific checks (authorities, liquidity, holders), simulation, comparison, and forecasting. Minor gaps exist (e.g., no tool for retrieving basic token metadata), but the core safety workflow is well-supported.
Available Tools
15 toolsbatch_scanAInspect
Scan several tokens at once — one full safety report per mint (up to 10).
| Name | Required | Description | Default |
|---|---|---|---|
| mints | Yes | List of SPL / Token-2022 mint addresses. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description should disclose behaviors like rate limits, auth needs, or error handling, but only mentions output per mint. Inadequate for a batch tool.
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?
Single sentence, front-loaded, no redundant information. Every word adds value.
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?
Output schema exists but description doesn't mention error conditions, batch limit rationale, or result ordering. Adequate but not 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 covers parameter with description, and tool description adds the 'up to 10' constraint not in schema, providing extra guidance.
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 scans multiple tokens (up to 10) and produces a full safety report per mint, distinguishing it from single-token scan tools like scan_token.
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?
Implies use for batch scanning vs single, but lacks explicit guidance on when not to use or alternatives for different batch sizes or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_authoritiesAInspect
Report a token's mint/freeze authority and Token-2022 traps, read directly on-chain.
Use this for a focused authority check when you want the raw authority picture (e.g. to confirm a creator truly renounced control) rather than the full verdict from verify_token_safety. Returns an Authorities report listing every Token-2022 extension and which of them are dangerous.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address to inspect. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mint | Yes | The mint address inspected. |
| error | No | Populated when the mint could not be read. |
| verdict | No | 'clean' if no authorities/traps present, otherwise 'review'. |
| mint_authority | No | Active mint-authority address, or None if revoked. |
| freeze_authority | No | Active freeze-authority address, or None if revoked. |
| dangerous_extensions | No | Subset considered dangerous: permanentDelegate, transferHook, nonTransferable, pausable. |
| token2022_extensions | No | All Token-2022 extensions present on the mint. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses 'read directly on-chain' (safe, read-only nature) and output is an 'Authorities report listing every Token-2022 extension and which of them are dangerous'. Does not mention permissions or limitations but sufficient for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs with no extraneous text. Front-loaded with core purpose, followed by usage guidance. Every sentence adds value.
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 one required parameter and presence of output schema, description fully covers purpose, usage context, and output nature. No gaps for agent to infer.
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 100% with description for the single parameter. Description adds no extra meaning beyond schema's 'The SPL or Token-2022 mint address to inspect.' 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?
Clearly states 'Report a token's mint/freeze authority and Token-2022 traps' with specific verb and resource. Explicitly distinguishes from sibling verify_token_safety by contrasting 'raw authority picture' vs 'full verdict'.
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?
Directly instructs when to use: 'Use this for a focused authority check when you want the raw authority picture... rather than the full verdict from verify_token_safety'. Provides concrete scenario and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_deployerCInspect
The wallets that hold power over the token — its mint authority and freeze authority.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose behavioral traits such as side effects, authorization requirements, rate limits, or whether it is read-only. The tool likely performs a safe read operation, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at 14 words, but its brevity sacrifices clarity and structure. It is a single incomplete sentence lacking a verb, which hinders understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (not shown), the description is incomplete. It omits what the tool returns, the action it performs, and any important context about the deployer check.
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% (the 'mint' parameter is well-described in the schema). The description adds no value beyond the schema; it does not elaborate on expected formats, constraints, or edge cases. Baseline of 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 is a noun phrase ('The wallets...') without a verb indicating an action. It does not state what the tool does (e.g., 'checks' or 'retrieves'), making its purpose ambiguous. The sibling 'check_authorities' likely performs a similar function, and the description offers no differentiation.
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 is provided on when to use this tool versus alternatives like 'check_authorities' or other siblings. There is no mention of prerequisites, context, or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_liquidityAInspect
Liquidity depth and 24h trading activity for a token — can you exit at size?
Reports total DEX liquidity, 24h volume, pair age and buy/sell counts. Thin liquidity or no volume means you may not be able to sell at your size even if it is not a honeypot.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mint | Yes | The mint address checked. |
| error | No | Populated when no market data was found. |
| age_days | No | Age of the oldest trading pair, in days (None if unlisted). |
| buys_24h | No | Number of buy transactions in the last 24h. |
| sells_24h | No | Number of sell transactions in the last 24h. |
| volume_24h | No | 24-hour traded volume in USD. |
| liquidity_usd | No | Total DEX liquidity in USD across the token's pairs. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It states the tool 'reports' data, implying a read-only operation. It also explains the implications of the results (inability to sell at size). It does not explicitly confirm non-destructiveness or mention rate limits, but the read-only nature is clear enough for a 4.
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 two sentences. It front-loads the core purpose and provides essential context without 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?
Given a simple one-parameter schema and an existing output schema (not shown), the description is complete enough. It covers the tool's output and practical implications, and the context signals indicate high schema coverage.
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 100% coverage with a clear description of the 'mint' parameter. The tool description adds context by explaining what the tool does with the parameter (checks liquidity for that mint), but it does not provide additional syntax or format beyond the schema. 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 checks liquidity depth and 24h trading activity for a token. It uses specific verbs and resources ('reports total DEX liquidity, 24h volume, pair age and buy/sell counts') and distinguishes itself from sibling tools that focus on other token attributes like authorities, deployer, or safety.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool: to assess whether a token can be exited at a given size. It warns about thin liquidity or no volume, implying use cases. However, it does not explicitly compare with sibling tools or state when not to use it, which would warrant a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_tokensBInspect
Scan several tokens and return them ranked safest-first — pick the best one to trade.
| Name | Required | Description | Default |
|---|---|---|---|
| mints | Yes | List of SPL / Token-2022 mint addresses (up to 10). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool scans and ranks tokens but omits any behavioral traits: whether it is destructive, requires special permissions, has rate limits, or fetches data live. The description is too thin for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. It is concise and to the point, though it could benefit from a bit more detail without becoming verbose.
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 presence of an output schema (not shown) and a single well-described parameter, the description provides adequate context for a basic tool. However, it lacks details on ranking methodology and how it differs from sibling tools, which would enhance completeness for a tool in a complex domain.
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% for the 'mints' parameter, already explaining it's a list of mint addresses up to 10. The tool description adds no additional meaning beyond 'scan several tokens', 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 it scans multiple tokens and returns them ranked by safety, with the goal of picking the best to trade. This distinguishes it from siblings like scan_token (single token) and batch_scan (likely scans multiple but doesn't rank).
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 when comparing safety across tokens, but does not explicitly state when not to use it or provide alternatives from the sibling list. No exclusions or context for when to prefer this over batch_scan or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
execute_safe_swapAInspect
Buy amount_usd of a token, paying with USDC (or input_mint) — only AFTER it passes the scan.
The point of a safety router: never execute an unscreened trade. The target mint is re-scanned
here with the full scan_token verdict; if the verdict is DANGER (honeypot, active freeze/mint
authority, dangerous Token-2022 extension, no sell route), NO swap is built. Otherwise it builds a
Jupiter swap from input_mint (USDC by default) into the target for exactly amount_usd and
returns an UNSIGNED transaction for you to sign. The build adds a small Jito tip (~0.0001 SOL) for
faster inclusion and wraps/unwraps SOL as needed. Note: only a DANGER verdict is refused — a CAUTION
token (e.g. an active mint authority) is allowed through, so check the scan yourself if you require
SAFE-only. The server only reads the target mint and builds the route — it never reads your other
holdings, never holds keys, never signs, never sends.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Token to buy. | |
| wallet | Yes | The agent's wallet — signer and funder (the swap is built for this pubkey). | |
| amount_usd | Yes | Amount to spend, in USD of the input token. | |
| input_mint | No | Mint to pay with — defaults to USDC. The swap is always input_mint -> mint. | EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Human-readable note: sign to execute, or why it was blocked. |
| route | Yes | Route label: 'safety-verified' when screened & built, 'screen-blocked' if refused. |
| token | Yes | The token mint the swap targets. |
| action | Yes | 'buy' when a swap was built, or 'blocked' when the token failed the safety screen. |
| amount_usd | Yes | The USD size requested for the trade. |
| transaction | Yes | Base64 UNSIGNED transaction for the agent to sign & submit; empty if blocked. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it rescans the token, only builds the swap if not DANGER, returns an unsigned transaction, never holds keys, never signs, never sends. It also mentions the Jito tip and wrapping/unwrapping behavior.
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 paragraph but efficiently conveys all critical information. It front-loads the core purpose and includes necessary details without verbosity. Minor improvement could be structuring conditions (e.g., DANGER vs CAUTION) more explicitly.
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 complexity of a safety-checked swap execution, the description covers the scan process, verdict handling, transaction building (unsigned, with Jito tip), and constraints (no key holding). The presence of an output schema (not shown) reduces need to explain return values. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing baseline of 3. The description adds context for 'wallet' (signer and funder) and clarifies that 'amount_usd' is spent from the input token. This adds modest value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: buying a specified amount of a token using USDC or an alternative input mint, only after passing a safety scan. It distinguishes itself from sibling tools which are analytical or scanning-only, by focusing on execution with a safety guard.
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 explains when to use the tool (after a scan) and defines the safety threshold: only a DANGER verdict blocks execution, while CAUTION is allowed. It provides context about the Jito tip and SOL wrapping. It does not explicitly list alternatives or when not to use, but the sibling tools imply the scanning steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
holders_breakdownAInspect
Top-holder concentration — how much of the supply the largest wallets control.
High concentration (one wallet, or the top 5, holding most of the supply) is a dump/rug risk: a single holder can crash the price on you. Reads the largest token accounts on-chain.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mint | Yes | The mint address checked. |
| error | No | Populated when holder data is unavailable. |
| top_holders | No | Largest accounts with their address and percent of supply. |
| top_holder_pct | No | Percent of supply held by the single largest account. |
| holder_accounts | No | Number of largest accounts inspected. |
| top5_holder_pct | No | Percent of supply held by the top 5 accounts combined. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool reads on-chain data, implying read-only behavior, but lacks details on rate limits, caching, or cost. 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 extremely concise: three sentences, no filler, front-loaded with the core purpose. Every sentence adds value.
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 an output schema (though not shown), the description provides sufficient context for a simple tool. It explains the output concept (concentration percentages) and the on-chain source. Lacks only minor details like whether it returns top 5 or top 10.
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?
There is only one parameter, 'mint', which the schema already describes as 'The SPL or Token-2022 mint address.' The description adds no additional meaning beyond the schema coverage of 100%.
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 reads top-holder concentration and identifies the largest wallets. The verb 'reads' and resource 'holder concentration' are specific. It naturally distinguishes from sibling tools like 'scan_token' or 'is_safe' by focusing on concentration data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for assessing dump/rug risk by noting that high concentration is a risk. However, it does not explicitly state when not to use it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
is_safeAInspect
Quick yes/no gate before trading: is this token safe enough to enter?
Wraps the full scan_token into a single boolean for fast decisions. safe is True only when the
verdict is SAFE and a live sell route exists — anything CAUTION/DANGER or unsellable returns False.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the output depends on the verdict (SAFE vs CAUTION/DANGER) and existence of a live sell route. It does not cover error handling, rate limits, or authentication, but for a simple boolean tool, this is adequate.
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 extremely concise: two sentences with no wasted words. The purpose and logic are front-loaded, making it easy to parse quickly.
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 simplicity (one parameter, boolean output), the description is mostly complete. It explains the output conditions and purpose. However, it does not mention what happens on invalid inputs or network errors, nor does it reference the output schema (which exists).
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 a single 'mint' parameter described as 'The SPL or Token-2022 mint address.' The description does not add additional meaning or format details beyond what the schema provides, so baseline of 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: a quick yes/no gate to check token safety before trading. It specifies that it wraps scan_token into a boolean, distinguishing it from siblings like scan_token (full report) and verify_token_safety.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use: as a quick gate before trading. It implies that for detailed information, one should use scan_token, but lacks explicit exclusions or comparisons to alternatives like check_authorities or rug_forecast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rug_forecastAInspect
Heuristic rug-pull forecast — probability and urgency from observable on-chain signals.
NOT an ML prediction or guarantee. Weights real factors: active mint/freeze authority, dangerous Token-2022 extensions, no sell route (honeypot), high holder concentration, sells outpacing buys, and very fresh age. Returns a 0-100 probability, an urgency window, and the contributing factors.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mint | Yes | The mint address assessed. |
| window | Yes | Urgency window: imminent / hours / days / low. |
| factors | No | The specific risk signals that drove the score. |
| rug_probability_pct | Yes | Heuristic rug probability 0-100 from the factors below. Not an ML prediction. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Discloses it's heuristic and lists factored signals, but does not describe error handling, idempotency, or potential impacts of invalid input. Adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-paragraph structure is front-loaded with purpose. Second paragraph adds essential detail without redundancy. Could be slightly more concise but overall efficient.
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 output schema exists, the description focuses on inputs and behavior. Covers key aspects: heuristic nature, factors, outputs. Leaves out pagination or rate limits, which may be acceptable.
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 covers 100% of parameters with clear description. The tool description adds value by explaining the evaluation factors, beyond the schema's brief 'SPL or Token-2022 mint address.'
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's a heuristic rug-pull forecast with specific outputs (probability, urgency, contributing factors). Distinguishes from sibling tools like is_safe and scan_token by focusing on rug-pull signals.
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?
Provides context on when to use (observable on-chain signals) and cautions it's not a guarantee. However, does not explicitly mention when not to use or suggest alternatives like verify_token_safety.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scammer_dnaAInspect
Scammer-DNA / intent score (0-100): how much the token's STRUCTURE looks like a deliberate scam.
A pattern score over structural signals — permanent delegate, kept mint/freeze authority, no sell route, extreme holder concentration. NOT proof of intent; a heuristic to flag deliberate scam setups.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently lists the structural signals checked and explicitly states it is a heuristic, not proof of intent, which accurately sets expectations.
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 exceptionally concise—two sentences that convey purpose, score range, and key signals without extraneous information. It is well-structured with the key takeaway front-loaded.
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 single parameter and presence of an output schema, the description is complete. It explains the output (score 0-100), the signal types checked, and the heuristic nature, which is sufficient for an agent to understand the tool's behavior.
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 already provides a high-coverage description (100%) for the single parameter (mint address). The description does not add significant semantic detail beyond what the schema gives, resulting in a baseline score of 3.
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 computes a scam likelihood score (0-100) based on structural signals like permanent delegate, kept authorities, no sell route, and holder concentration. It distinguishes itself from other tools by being a heuristic for structural scam setups, not a definitive proof.
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 explicitly state when to use this tool over siblings like is_safe or rug_forecast. It implies it is for structural analysis but lacks clear guidance on context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_tokenAInspect
Full safety scan of a Solana token — the one-call verdict combining every screen.
Aggregates the on-chain authority/extension screen, a live honeypot (sell-route) check, DEX liquidity & trading activity, and top-holder concentration into one SAFE/CAUTION/DANGER verdict with a 0-100 safety score. Call this first for a complete picture; use the focused tools (check_liquidity, holders_breakdown, simulate_sell, rug_forecast) to drill into one aspect.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address to scan. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mint | Yes | The mint address scanned. |
| error | No | Populated when the token could not be read. |
| risks | No | All risk flags found across authority, extensions, liquidity, sellability. |
| verdict | Yes | Overall risk: SAFE / CAUTION / DANGER / UNKNOWN. |
| age_days | No | Age of the oldest pair in days. |
| sellable | No | Whether a live sell route exists (honeypot if False). |
| volume_24h | No | 24h volume in USD. |
| holder_count | No | Largest accounts inspected for concentration. |
| safety_score | Yes | 0-100 composite safety score (higher = safer). |
| liquidity_usd | No | Total DEX liquidity in USD. |
| mint_authority | No | Active mint authority, or None if revoked. |
| top_holder_pct | No | Largest-wallet concentration, percent of supply. |
| freeze_authority | No | Active freeze authority, or None if revoked. |
| dangerous_extensions | No | Dangerous Token-2022 extensions present. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does so by detailing the aggregated screens (authority, honeypot, liquidity, holders). However, it does not explicitly state that the operation is read-only, which would have earned a 5.
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 and well-structured: a one-line summary followed by a paragraph with details and usage guidance. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple screens, verdict output), the description covers the main aspects. It mentions the verdict types and safety score. The output schema exists for further details, so no need to describe return values fully. Missing error behavior or edge cases, but still quite complete.
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?
There is only one parameter 'mint' with 100% schema description coverage. The description does not add additional semantics beyond the schema; it merely repeats the context. 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 'Full safety scan of a Solana token' with a specific verb and resource. It explicitly distinguishes itself from sibling tools like check_liquidity and holders_breakdown by positioning itself as the first call for a complete picture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call this first for a complete picture; use the focused tools... to drill into one aspect.' It also lists alternative sibling tools for specific aspects, making when-to-use and when-not-to-use very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulate_sellAInspect
Check whether a token can actually be SOLD after buying — a dedicated honeypot detector.
Call this when you specifically worry a token is a honeypot (you can buy but not exit). Combines
on-chain constraints (non-transferable / pausable extensions, freeze authority) with a live
Jupiter sell-route probe — a token with no sell route is effectively a honeypot even if no
extension formally blocks it. Returns a SellCheck where sellable is the bottom line.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address to test for sellability. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mint | Yes | The mint address checked. |
| error | No | Populated when the mint could not be read. |
| verdict | No | Plain-language sellability summary with the reason. |
| sellable | No | True if a live sell route exists and nothing on-chain blocks selling; False if blocked or no route; None if it could not be determined. |
| freeze_authority | No | Active freeze authority, which can also block selling. |
| blocking_extensions | No | Extensions that block selling (nonTransferable, pausable). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the combination of on-chain checks and a live Jupiter probe, and notes the return value 'SellCheck where `sellable` is the bottom line.' 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?
Concise and well-structured. Two paragraphs: first states purpose, second provides usage and method. Every sentence earns its 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?
Given the presence of an output schema, the description adequately covers purpose, method, and output semantics. It is complete for a honeypot detection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description. The description adds context (e.g., 'SPL or Token-2022 mint address') but does not significantly augment the schema's meaning. Baseline 3 applies.
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: 'Check whether a token can actually be SOLD after buying — a dedicated honeypot detector.' It uses specific verbs and resources, distinguishing it from siblings like 'simulate_trade' and 'verify_token_safety'.
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?
Provides explicit guidance: 'Call this when you specifically worry a token is a honeypot.' It explains the method (on-chain constraints and Jupiter sell-route probe) but does not explicitly state when not to use it, though the context with siblings implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulate_tradeAInspect
Full round-trip simulation: buy amount_usd of the token with USDC, then sell it ALL back.
Estimates the real cost of entering AND exiting at your size from Jupiter quotes (no on-chain execution): tokens received, USD returned, and round-trip loss % (both-side slippage). A honeypot shows buyable=true but sellable=false — you can enter but not exit.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address. | |
| amount_usd | No | Trade size in USD (default 100). Use your real size for an accurate estimate. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It fully discloses that the tool is a simulation ('from Jupiter quotes, no on-chain execution'), describes the round-trip behavior, explains honeypot detection, and lists output estimates (tokens received, USD returned, round-trip loss %). 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?
Two well-structured sentences. Front-loaded with main action, followed by explanation of outputs and honeypot use case. No wasted words; every sentence is informative.
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 (round-trip simulation, honeypot detection, output estimates) and presence of an output schema, the description is fairly complete. It explains purpose, behavior, and hints at outputs. Could mention prerequisites (e.g., token must exist), but overall 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?
Schema description coverage is 100% with adequate param descriptions. Description adds value by advising 'Use your real size for an accurate estimate' for amount_usd, which aids selection. Baseline 3 due to full schema coverage, plus one for added guidance.
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?
Description clearly states the core action: 'Full round-trip simulation: buy `amount_usd` of the token with USDC, then sell it ALL back.' It specifies the verb (simulate), resource (token), and scope (round-trip). Distinguishes from sibling 'simulate_sell' which likely only simulates selling.
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?
Description provides context on when to use: estimating real cost of entering and exiting, and detecting honeypots. It implies use for pre-trade analysis. However, it does not explicitly state when not to use or list alternatives beyond mentioning 'no on-chain execution'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
token_ageAInspect
Token age and recent trading activity — freshness and whether anyone is actually trading it.
A token only minutes/hours old, or with no 24h volume, is high-risk (fresh launch or dead market).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mint | Yes | The mint address checked. |
| error | No | Populated when no market data was found. |
| age_days | No | Age of the oldest trading pair, in days (None if unlisted). |
| buys_24h | No | Number of buy transactions in the last 24h. |
| sells_24h | No | Number of sell transactions in the last 24h. |
| volume_24h | No | 24-hour traded volume in USD. |
| liquidity_usd | No | Total DEX liquidity in USD across the token's pairs. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that tokens with low age or no 24h volume are high-risk, indicating a read-only analysis. However, it does not describe return format or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. Front-loaded purpose, then behavioral insight. Every sentence adds value.
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 a simple tool with one parameter and an output schema (not shown), the description adequately covers the key risk assessment. Slightly lacking on explicit return values.
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?
Only one parameter 'mint' with 100% schema coverage; the schema already describes it as a mint address. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assesses token age and recent trading activity, focusing on freshness and trading volume. This distinguishes it from sibling tools like 'scan_token' or 'rug_forecast' which are broader safety checks.
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 assessing risk of fresh or dead tokens but does not explicitly specify when to use this tool over siblings. No direct comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_token_safetyAInspect
Audit a Solana token for rug-pull and honeypot risk before buying it.
Call this FIRST, before entering any position. Reads the mint directly on-chain (getAccountInfo)
and flags: an active mint authority (supply can be inflated after you buy), an active freeze
authority (your tokens can be frozen), dangerous Token-2022 extensions (permanent delegate,
transfer hook, non-transferable, pausable), and whether the token has a live, routable market
(no market is itself a risk). Returns a TokenSafety with a SAFE / CAUTION / DANGER / UNKNOWN
verdict plus the specific risks found — gate your buy decision on verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The SPL or Token-2022 mint address to audit. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Populated when the mint could not be read. |
| risks | No | Plain-language risk flags detected; empty means none found. |
| token | Yes | The mint address that was audited. |
| supply | No | Raw on-chain total supply. |
| verdict | Yes | Overall risk: SAFE (no red flags), CAUTION (authority/liquidity risk), DANGER (rug or honeypot trap present), or UNKNOWN (not a mint / RPC unavailable). |
| decimals | No | Token decimal places. |
| extensions | No | Token-2022 extensions present on the mint (e.g. transferHook). |
| mint_authority | No | Active mint-authority address if present — its holder can mint new supply and dilute you after purchase; None means revoked. |
| freeze_authority | No | Active freeze-authority address if present — its holder can freeze your account so you cannot sell; None means revoked. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility. It details the on-chain read operations (getAccountInfo), specific risk flags checked (mint authority, freeze authority, Token-2022 extensions, market), and the output verdict structure (SAFE/CAUTION/DANGER/UNKNOWN). All behaviors are 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 concise and well-structured: first sentence states the core purpose, second sentence details behavior and output. Every sentence adds value with no redundant text.
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 (multiple checks), the description thoroughly explains what is checked and the output format. It positions itself as the first step among many sibling tools, and the output schema covers return values. No missing information.
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% (one parameter 'mint' with description matching the tool's domain). The description adds no new information about the parameter beyond what the schema provides, 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: audit a Solana token for rug-pull and honeypot risk before buying. It uses a specific verb 'audit' and distinguishes itself by being the first call before entering any position, which sets it apart from sibling tools.
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?
Explicitly says 'Call this FIRST, before entering any position' and 'gate your buy decision on verdict', providing clear when-to-use guidance and decision-making context.
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.
Discussions
No comments yet. Be the first to start the discussion!