BaseGuard + WalletGuard
Server Details
Deterministic on-chain token safety verdicts for Base, Ethereum, Arbitrum, and Solana. No LLM — pure on-chain data including Clanker CREATE2 resolution, Pump.fun bonding curve detection, Raydium LP checks, and a pro tier with Farcaster social signals and holder growth velocity. Also includes /verdict/pump — a fast Pump.fun specific verdict optimised for HFT at 474ms p50, covering bonding curve SOL reserve, graduation status, and deployer age. Solana only, $0.02 USDC."
- 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.6/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: check_pump_token for Pump.fun tokens, check_token_safety for general tokens, check_token_safety_lite for quick screening, check_token_safety_pro for social signals, check_wallet for full wallet analysis, and check_wallet_quick for wallet age verification. Descriptions provide explicit use cases and examples, eliminating ambiguity.
All tools follow a consistent verb_noun pattern starting with 'check_', with specific suffixes (pump_token, token_safety, token_safety_lite, token_safety_pro, wallet, wallet_quick). The naming is predictable and correctly reflects the tool's function.
Six tools is well-scoped for the domain of blockchain risk assessment. It provides a tiered suite for token safety (standard, lite, pro, pump-specific) and wallet analysis (full, quick), covering varying needs without being excessive.
The tool set covers the full lifecycle of token and wallet risk assessment: general token safety, fast screening, deep social analysis, Pump.fun-specific checks, and wallet risk profiling at two levels. No obvious gaps for the stated purpose of evaluating counterparty and token risk before trades.
Available Tools
6 toolscheck_pump_tokenARead-onlyInspect
Use this tool when you need to evaluate a Pump.fun token on Solana before a time-sensitive trade. Input the mint address (Solana only — no chainId needed). Returns deployer age, bonding curve SOL reserve, graduation status, and holder concentration in ~474ms p50 — so you can reject rug-risk tokens before the window closes. Returns an error if the token is not a Pump.fun mint; use check_token_safety in that case.
Example input: {"contractAddress":"8xem5nmhT5zrsBbfH3Vf5wkvKiLBRkFxKpvHvaTpump"} Example output shape: {"riskScore":30,"recommendation":"CAUTION","graduated":false,"bondingCurveReserveSol":14.2,"deployer":{"walletAgeDays":1,"flag":"WARN"},"holderConcentration":{"top10Pct":62.1,"flag":"WARN"},"processingMs":474}
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | Required. Pump.fun token mint address — base58 encoded Solana public key, 32–44 characters. Example: '8xem5nmhT5zrsBbfH3Vf5wkvKiLBRkFxKpvHvaTpump'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld; description adds error handling and speed (~474ms p50), which is useful context without contradicting 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?
Well-structured with clear purpose, usage, and examples; slightly verbose example output but justified for completeness.
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?
Despite no output schema, description provides expected output shape, error case, and speed, fully covering what an agent needs to know.
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 the single parameter thoroughly (pattern, length, description); description adds an example but no new semantic meaning, fitting baseline for high 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 evaluates Pump.fun tokens on Solana for time-sensitive trades, distinguishing it from check_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?
Explicitly says when to use ('before a time-sensitive trade') and when to use an alternative ('use check_token_safety' if not a Pump.fun mint).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_token_safetyARead-onlyInspect
Use this tool when you need to decide whether a token contract is safe before executing a trade or listing it. Input the contract address and chain. Returns a SAFE/CAUTION/AVOID verdict, risk score (0–100), deployer wallet age, LP lock status, and top-10 holder concentration — so you can reject dangerous tokens before committing funds. For Pump.fun tokens use check_pump_token (faster). For sub-3s bulk screening use check_token_safety_lite.
Example input: {"contractAddress":"0x4ed4e862860bed51a9570b96d89af5e1b0efefed","chainId":"base"} Example output shape: {"riskScore":12,"recommendation":"SAFE","confidence":"HIGH","checks":{"deployer":{"walletAgeDays":421,"flag":"OK"},"liquidity":{"lpLocked":true,"flag":"OK"},"holders":{"top10Concentration":18.4,"flag":"OK"}},"processingMs":840}
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | No | Optional. Chain the token is deployed on. Defaults to 'base'. Enum: 'base' | 'ethereum' | 'arbitrum' | 'solana'. | base |
| contractAddress | Yes | Required. Token contract address. 0x-prefixed 42-char hex for EVM chains; base58 for Solana. Example: '0x4ed4e862860bed51a9570b96d89af5e1b0efefed' (Base/EVM) or '8xem5nmhT5zrsBbfH3Vf5wkvKiLBRkFxKpvHvaTpump' (Solana). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint. The description adds behavioral details: returns a verdict, risk score, deployer info, LP lock, holder concentration, and example output shape. 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 a single, well-structured paragraph that front-loads the key purpose and usage. It is efficient but slightly verbose with the example output; still 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 tool's complexity (2 parameters, no output schema) the description is complete. It covers purpose, usage, return values, and examples. No gaps remain.
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%, so baseline 3. The description includes an example input and output, but does not add significant meaning beyond the schema's property descriptions. The schema already explains the 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 the tool's purpose: to decide if a token contract is safe before trading or listing. It specifies the verb 'check' and the resource 'token safety', and distinguishes from siblings by mentioning alternative tools for specific cases.
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 provides when to use (before trade/listing) and when to use alternatives (check_pump_token for Pump.fun tokens, check_token_safety_lite for bulk screening). This offers clear context and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_token_safety_liteARead-onlyInspect
Use this tool when you need to screen tokens at high frequency and full holder concentration analysis is cost-prohibitive, or when you need a sub-3s response. Input the contract address and chain. Returns deployer age, LP lock status, and SAFE/CAUTION/AVOID — so you can filter obviously-risky tokens before deciding whether to pay for a full check_token_safety call.
Example input: {"contractAddress":"0x1234567890abcdef1234567890abcdef12345678","chainId":"base"} Example output shape: {"riskScore":55,"recommendation":"CAUTION","deployerAgeDays":3,"deployerFlag":"WARN","lpLocked":false,"lpFlag":"WARN","processingMs":1100}
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | No | Optional. Chain the token is deployed on. Defaults to 'base'. Enum: 'base' | 'ethereum' | 'arbitrum' | 'solana'. | base |
| contractAddress | Yes | Required. Token contract address. 0x-prefixed 42-char hex for EVM chains; base58 for Solana. Example: '0x4ed4e862860bed51a9570b96d89af5e1b0efefed' (Base/EVM) or '8xem5nmhT5zrsBbfH3Vf5wkvKiLBRkFxKpvHvaTpump' (Solana). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds value by disclosing the return fields (deployer age, LP lock status, recommendation) and providing an example output shape. No contradictions with 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 well-structured with a clear opening sentence, usage context, and example. It is concise yet includes necessary details. Slight redundancy in explaining usage could be trimmed, but overall effective.
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 2-parameter tool with no output schema, the description is thorough: it explains the tool's role, provides example input/output, and lists return fields. It fully compensates for the lack of output schema.
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 descriptions for both parameters. The description adds example input and output, helping contextualize the parameters. While schema already covers meaning, the examples improve usability.
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: screening tokens at high frequency with sub-3s response, distinguishing it from the full check_token_safety tool. It specifies the verb 'screen' and the resource 'tokens', and differentiates from siblings by emphasizing speed and cost-effectiveness.
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 explicitly states when to use this tool: when high frequency or full holder concentration analysis is cost-prohibitive, or when sub-3s response is needed. It also suggests that after using this, users may decide to pay for the full check_token_safety call, providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_token_safety_proARead-onlyInspect
Use this tool when you need the most complete token safety signal and social traction or holder momentum is part of your decision criteria. Input the contract address and chain (Base gives full signals; other chains return holder velocity as unknown). Returns the standard safety verdict plus Farcaster mention count and sentiment (last 24h) and holder growth trend — so you can catch tokens with anomalous momentum or negative social sentiment that on-chain checks alone would miss.
Example input: {"contractAddress":"0x4ed4e862860bed51a9570b96d89af5e1b0efefed","chainId":"base"} Example output shape: {"riskScore":12,"recommendation":"SAFE","pro":{"proVerdict":"SAFE","farcaster":{"mentions":14,"sentiment":"positive"},"holderGrowth":{"trend":"rising","change24h":8.2}}}
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | No | Optional. Chain the token is deployed on. Defaults to 'base'. Enum: 'base' | 'ethereum' | 'arbitrum' | 'solana'. Full holder growth velocity signals are only available on Base; other chains return trend: 'unknown'. | base |
| contractAddress | Yes | Required. Token contract address. 0x-prefixed 42-char hex for EVM chains; base58 for Solana. Example: '0x4ed4e862860bed51a9570b96d89af5e1b0efefed' (Base/EVM) or '8xem5nmhT5zrsBbfH3Vf5wkvKiLBRkFxKpvHvaTpump' (Solana). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations (readOnlyHint, openWorldHint) by detailing the return data: risk score, recommendation, verdict, Farcaster mentions/sentiment, and holder growth trend. It also clarifies limitations for non-Base chains. This adds valuable 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and includes an example. Every sentence adds value. It wastes no words while being 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 lack of output schema, the description compensates with a detailed example output shape. It explains chain behavior and parameter requirements completely. The tool has only two parameters, and the description covers all needed context.
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 schema already provides 100% description coverage for both parameters. The description adds an example input and output shape, explaining how chainId affects results and validating parameter usage. This exceeds what the schema provides.
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 the most complete token safety signal with social traction and holder momentum. It distinguishes itself from siblings by mentioning Farcaster mentions/sentiment and holder growth trend, which are not present in simpler tools like check_token_safety_lite.
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 explicitly says when to use the tool (when social traction or holder momentum is needed) and provides guidance on chain-specific behavior (Base gives full signals). However, it does not explicitly state when not to use it or mention alternative sibling tools by name, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_walletARead-onlyInspect
Use this tool when you need to assess counterparty risk before interacting with an unknown wallet — for example, when evaluating a token deployer, a trading counterparty, or an airdrop claimant. Input the EVM wallet address. Returns a CLEAN/SUSPICIOUS/FLAGGED verdict with bot score, whale classification, contract deploy count (rug proxy), and risk flags (MIXER_INTERACTIONS, HIGH_BOT_SCORE, SERIAL_DEPLOYER, etc.) — so you can decide whether to proceed or abort the interaction.
Example input: {"address":"0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"} Example output shape: {"verdict":"CLEAN","riskScore":8,"botScore":14,"classification":"WHALE","rugHistory":0,"riskFlags":[],"ageDays":1820,"txCount":4210}
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Required. EVM wallet address — 0x-prefixed, 42 characters. Example: '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds value by detailing the return verdict (CLEAN/SUSPICIOUS/FLAGGED), specific risk flags, bot score, whale classification, and contract deploy count, which are beyond what annotations offer.
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, front-loaded with purpose, and every sentence adds value. Two well-structured paragraphs with no wasted words.
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 usage, input, output shape, and an example. Although no output schema exists, the example output provides sufficient context. For a single-parameter tool with good annotations, it is nearly 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?
Schema coverage is 100% with a detailed description of the 'address' parameter. The description adds a real example but does not provide additional meaning 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 assesses counterparty risk for an unknown wallet, with specific verb 'assess risk' and resource 'wallet'. It distinguishes from siblings like check_wallet_quick and check_token_safety by focusing on wallet-level risk assessment.
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 explicitly states when to use ('when you need to assess counterparty risk') and provides concrete scenarios (evaluating token deployer, trading counterparty, airdrop claimant). It does not explicitly state when not to use, but the context of sibling tools implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_wallet_quickARead-onlyInspect
Use this tool when you need to quickly confirm a wallet is not brand-new before a trust decision, such as filtering sybils in an airdrop or gating participation by wallet age. Input the EVM wallet address. Returns wallet age in days, transaction count, and CLEAN/SUSPICIOUS — so you can reject obviously-new wallets without paying for a full profile. For bot score, whale classification, and rug history use check_wallet instead.
Example input: {"address":"0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"} Example output shape: {"ageDays":1820,"txCount":4210,"verdict":"CLEAN","processingMs":310}
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Required. EVM wallet address — 0x-prefixed, 42 characters. Example: '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and open-world. The description adds specifics: returns wallet age in days, transaction count, and CLEAN/SUSPICIOUS verdict, along with processing time in the example. No contradictions; fully discloses the nature of the 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?
Two dense sentences plus example input/output. Every sentence adds value: purpose, usage context, alternative, and examples. No fluff; front-loaded with key info.
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, no nested objects), the description covers all needed context: purpose, input format, output shape, and differentiation from siblings. Example output compensates for lack of output schema.
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 detailed description of the address parameter (pattern, example). The description adds an example input and output shape, providing concrete semantics 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 purpose: quickly confirm a wallet is not brand-new before a trust decision, with specific use cases like filtering sybils in airdrops. It distinguishes from the sibling tool check_wallet by specifying what this tool does not provide (bot score, whale classification, rug history).
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 tells when to use (quick confirmation before trust decisions) and when not to use (for full profile, use check_wallet instead). Gives concrete examples and alternatives, making the decision boundary clear.
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!