What can you do with this server?

SicariusGuard is a Solana token safety oracle for AI agents, trading bots, and developers, offering multi-layer risk analysis of SPL tokens before swapping or trading. It integrates natively with AI agents and LLMs via MCP for autonomous risk assessment, and supports pay-per-call micropayments using SOL via the x402 protocol. * check_token_safety: 5-layer on-chain safety check (mint authority, freeze authority, Token-2022 extensions, honeypot simulation, holder concentration) returning a risk score (0–100) and verdict (SAFE / CAUTION / HIGH_RISK / CRITICAL) * check_honeypot: Simulate a sell order through Jupiter DEX to detect honeypot traps without real cost * check_holder_concentration: Analyze top holder distribution to flag concentrated supply (top-1 >50%, top-5 >80%, top-10 >90%) as rug pull indicators * full_token_scan: Most comprehensive 7-layer scan combining on-chain byte-level inspection with Birdeye market intelligence and Helius wallet reputation, using a weighted scoring model (60% on-chain / 25% market / 15% reputation) * get_wallet_reputation: Investigate a Solana wallet's trustworthiness via Helius DAS identity, funding chain analysis, deployer age, and known entity classification * get_market_intel: Real-time Birdeye market data (price, 24h volume, liquidity depth, market cap, holder count) with risk flags such as wash trading or low liquidity * batch_scan: Scan up to 10 tokens in parallel for portfolio-level or watchlist risk assessment

Which integrations are available for this server?

Provides real-time Solana token safety analysis combining byte-level on-chain inspection, market intelligence, and wallet reputation scoring for AI agents and trading bots.

SicariusGuard

by Chronolapse411

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

🛡️ SicariusGuard

Solana Token & NFT Safety Oracle for AI Agents & Trading Bots

GitHub stars npm version npm downloads License: MIT

sicarius-guard MCP server Score Smithery

Real-time token and NFT safety analysis combining byte-level on-chain inspection, LP lock verification, deployer reputation scoring, market intelligence, and NFT fraud detection. Built for autonomous AI agents, MCP-enabled LLMs, and trading infrastructure.

"Don't trade blind. Query SicariusGuard before every swap."

🌐 Live API: `https://sicarius-guard-640545264957.us-east4.run.app`

# Try it now — no auth required (100 free calls/day)
curl https://sicarius-guard-640545264957.us-east4.run.app/v1/scan/DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263

📑 Table of Contents

Related MCP server: RAD Security

🔍 What It Does

SicariusGuard performs 12 layers of safety analysis on any Solana SPL token or NFT:

On-Chain Safety (Layers 1-5)

Layer	Source	Detection
🔓 Mint Authority	Raw SPL mint bytes	Can deployer print infinite tokens?
🧊 Freeze Authority	SPL layout offset 46	Can deployer freeze any wallet?
⚠️ Token-2022 Extensions	Extension type scan	PermanentDelegate, TransferHook, ConfidentialTransfers
🍯 Honeypot Detection	Jupiter sell simulation	Can you actually sell this token?
📊 Holder Concentration	`getTokenLargestAccounts`	Top 5 wallets controlling >50% supply?

LP & Token Maturity (Layers 6-8)

Layer	Source	Detection
🔒 LP Lock/Burn	Raydium V4 byte decode + GeckoTerminal	Is liquidity locked, burned, or unlocked?
⏰ Token Age	Helius enhanced RPC	Newborn (<24h)? Young (<7d)? Mature?
⚖️ Unified Scoring	5-axis weighted engine	Combined risk across all layers

Intelligence & Reputation (Layers 9-12)

Layer	Source	Detection
📈 Market Intel	Birdeye API	Liquidity, volume, wash trading, manipulation
🔎 Wallet Reputation	Helius Identity + Funded-By	Is the deployer a known scammer?
🕵️ Deployer Recon	DAS + Enhanced TX	Serial rugger? Burner wallet? Dead token history?
🖼️ NFT Intelligence	Helius DAS + Magic Eden	Counterfeit collection? Unverified creators? Pricing anomaly?

5-Axis Weighted Risk Scoring

finalScore = (onChain × 0.45) + (lpLock × 0.15) + (age × 0.05) + (market × 0.22) + (reputation × 0.13)

0       → SAFE
1-15    → CAUTION
16-50   → HIGH_RISK
51-100  → CRITICAL

Weight	Source	What It Catches
45%	On-chain safety	Mint/freeze authority, honeypots, extensions, supply
15%	LP lock analysis	Unlocked liquidity, unburned LP tokens, lock duration
5%	Token age	Newborn tokens (<24h), recently deployed
22%	Birdeye market data	Low liquidity, wash trading, price manipulation
13%	Helius wallet intel	Scammer wallets, suspicious funding chains, burner deployers

🚀 Quick Start

# Clone
git clone https://github.com/Chronolapse411/sicarius-guard.git
cd sicarius-guard

# Install
npm install

# Configure
cp .env.example .env
# Add your HELIUS_RPC_URL and optionally BIRDEYE_API_KEY

# Build & Run
npm run build
npm start

📡 API Endpoints

REST API (Port 3400)

Method	Endpoint	Description
`POST`	`/v1/check`	Full on-chain safety analysis
`GET`	`/v1/check/:mint`	Convenience GET for safety check
`POST`	`/v1/scan`	Full 12-layer analysis + Birdeye + Helius + deployer recon
`GET`	`/v1/scan/:mint`	Convenience GET for enriched scan
`POST`	`/v1/honeypot`	Honeypot-only check (Jupiter sell sim)
`POST`	`/v1/holders`	Holder concentration analysis
`GET`	`/v1/lp-lock/:mint`	LP lock/burn status for a token
`GET`	`/v1/token-age/:mint`	Token creation date and age category
`GET`	`/v1/deployer/:address`	Deployer reconnaissance dossier
`GET`	`/v1/nft-check/:mint`	NFT safety analysis (Magic Eden + Helius DAS)
`GET`	`/v1/pricing`	x402 payment pricing table
`GET`	`/health`	Service health check with cache stats

Example Request

# Basic safety check (BONK)
curl https://sicarius-guard-640545264957.us-east4.run.app/v1/check/DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263

# Full 12-layer scan
curl https://sicarius-guard-640545264957.us-east4.run.app/v1/scan/DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263

# LP lock check (POPCAT — 99.2% burned, 20,865 SOL liquidity)
curl https://sicarius-guard-640545264957.us-east4.run.app/v1/lp-lock/7GCihgDB8fe6LNjn2MYtkzZcRjQy3t9GHdC8uHYmW2hr

# NFT safety check (Mad Lads #7541)
curl https://sicarius-guard-640545264957.us-east4.run.app/v1/nft-check/7zuR45WCsAsWsrqvYPyvLXFiCRKuvjh7HrMcNJ6F36Kd

# Deployer recon (checks if a wallet is a serial scammer)
curl https://sicarius-guard-640545264957.us-east4.run.app/v1/deployer/BGkkEeg4Gj8VcoerFb2RephZNkTEfHmzJBZMv4S7qVTQ

Example Response (`/v1/scan`)

{
  "safety": {
    "safe": true,
    "riskScore": 0,
    "verdict": "SAFE",
    "checks": {
      "mintAuthority": { "status": "REVOKED", "safe": true },
      "freezeAuthority": { "status": "REVOKED", "safe": true },
      "token2022Extensions": { "status": "CLEAN", "safe": true },
      "supplyConcentration": { "status": "OK", "safe": true }
    }
  },
  "honeypot": { "isHoneypot": false, "sellable": true },
  "holders": { "concentrated": false, "stats": { "top10Pct": 8.2 } },
  "lpLock": {
    "status": "burned",
    "burnPct": 99.2,
    "liquiditySOL": 20865,
    "poolCreatedAt": "2023-12-12T..."
  },
  "tokenAge": {
    "ageCategory": "mature",
    "createdAt": "2022-12-08T...",
    "ageDays": 1259
  },
  "deployerRecon": {
    "verdict": "CLEAN",
    "recidivismScore": 0,
    "portfolioSize": 1
  },
  "combined": {
    "safe": true,
    "finalScore": 0,
    "verdict": "SAFE",
    "summary": "All checks passed — token appears safe"
  }
}

🤖 MCP Server (for AI Agents)

SicariusGuard exposes tools via the Model Context Protocol (MCP), enabling LLMs and agent frameworks to call safety checks natively.

Available MCP Tools (11)

Tool	Description	Read-Only
`check_token_safety`	5-layer on-chain rug pull, honeypot, and holder analysis	✅
`check_honeypot`	Jupiter DEX sell simulation — zero cost, quote-only	✅
`check_holder_concentration`	Top holder distribution analysis with concentration flags	✅
`check_lp_lock`	LP lock/burn status — Raydium V4 byte decode + burn detection	✅
`check_token_age`	Token creation date and age category via Helius RPC	✅
`full_token_scan`	12-layer scan: on-chain + LP + age + market + reputation + deployer	✅
`get_wallet_reputation`	Helius DAS identity, funding chain, deployer age analysis	✅
`get_market_intel`	Birdeye market data: price, volume, liquidity, risk flags	✅
`recon_deployer`	Deployer reconnaissance — portfolio health, serial scammer detection	✅
`check_nft`	NFT safety analysis — collection verification, floor price, risk scoring	✅
`batch_scan`	Parallel 12-layer scan of up to 10 tokens per call	✅

Install via npx (Recommended)

# Run directly — no cloning required
npx sicarius-guard

Install in Claude Code

claude mcp add sicarius-guard -- npx -y sicarius-guard

Install in Cursor

Install MCP Server

Or manually add to your Cursor MCP config:

{
  "mcpServers": {
    "sicarius-guard": {
      "command": "npx",
      "args": ["-y", "sicarius-guard"],
      "env": {
        "HELIUS_RPC_URL": "https://mainnet.helius-rpc.com/?api-key=YOUR_KEY",
        "BIRDEYE_API_KEY": "your-birdeye-key"
      }
    }
  }
}

Install in VS Code

Or via CLI:

code --add-mcp '{"name":"sicarius-guard","command":"npx","args":["-y","sicarius-guard"]}'

Install from Source (Claude Desktop / Cursor)

{
  "mcpServers": {
    "sicarius-guard": {
      "command": "node",
      "args": ["dist/mcp-server.js"],
      "cwd": "/path/to/sicarius-guard",
      "env": {
        "HELIUS_RPC_URL": "https://mainnet.helius-rpc.com/?api-key=YOUR_KEY",
        "BIRDEYE_API_KEY": "your-birdeye-key"
      }
    }
  }
}

🏗️ Architecture

┌──────────────────────────────────────────────────────────────┐
│                       SicariusGuard v1.1                      │
│                                                              │
│  ┌─────────────┐  ┌─────────────┐  ┌──────────────────────┐ │
│  │ REST API    │  │ MCP Server  │  │ x402 Payment Gate    │ │
│  │ Express 5   │  │ 11 tools    │  │ SOL Micropayments    │ │
│  │ 12 endpts   │  │ stdio       │  │                      │ │
│  └──────┬──────┘  └──────┬──────┘  └──────────┬───────────┘ │
│         │                │                     │             │
│  ┌──────▼────────────────▼─────────────────────▼───────────┐ │
│  │               12-Layer Analysis Engine                   │ │
│  │                                                          │ │
│  │  token_safety.ts   ┐                                    │ │
│  │  honeypot_sim.ts   ├─ On-Chain (45%)                    │ │
│  │  holder_analysis.ts┘                                    │ │
│  │  lp_lock.ts          LP Lock  (15%)                     │ │
│  │  token_age.ts        Age      (5%)                      │ │
│  │  birdeye.ts          Market   (22%)                     │ │
│  │  helius_wallet.ts    Rep      (13%)                     │ │
│  │  scoring.ts          Unified 5-Axis Engine              │ │
│  │  deployer_recon.ts   Deployer Reconnaissance            │ │
│  │  nft_intel.ts        NFT Intelligence (ME + DAS)        │ │
│  └──────────────────────────┬───────────────────────────────┘ │
│                             │                                 │
│     ┌───────────┬───────────┼───────────┬─────────────┐      │
│     ▼           ▼           ▼           ▼             ▼      │
│  ┌───────┐ ┌─────────┐ ┌────────┐ ┌──────────┐ ┌─────────┐ │
│  │Solana │ │Birdeye  │ │Helius  │ │Magic Eden│ │Gecko    │ │
│  │RPC    │ │API v3   │ │DAS+RPC │ │v2 (free) │ │Terminal │ │
│  └───────┘ └─────────┘ └────────┘ └──────────┘ └─────────┘ │
└──────────────────────────────────────────────────────────────┘

💰 x402 Payment Protocol

SicariusGuard implements the x402 HTTP Payment Required protocol for machine-native micropayments. AI agents can pay per API call with SOL — no registration, no API keys, no accounts.

How It Works

1. Agent hits /v1/scan → gets 402 + payment instructions
2. Agent sends SOL to treasury wallet
3. Agent retries with X-PAYMENT: <tx_signature>
4. Server verifies on-chain → returns safety data

Pricing

Endpoint	Price (SOL)	Description
`/v1/check`	0.001	On-chain safety check
`/v1/scan`	0.002	Full 12-layer scan
`/v1/honeypot`	0.0005	Honeypot simulation
`/v1/holders`	0.0005	Holder analysis
`/v1/nft-check`	0.001	NFT safety check

Example (Paid Request)

# Step 1: Get pricing + treasury address
curl https://sicarius-guard-640545264957.us-east4.run.app/v1/pricing

# Step 2: Send SOL to treasury address (returned in pricing response)
solana transfer <TREASURY_ADDRESS> 0.002

# Step 3: Use tx signature as payment proof
curl -X POST https://sicarius-guard-640545264957.us-east4.run.app/v1/scan \
  -H "Content-Type: application/json" \
  -H "X-PAYMENT: <your_tx_signature>" \
  -d '{"mint": "DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263"}'

Security

On-chain verification — Every payment is verified against Solana mainnet
Replay protection — Each tx signature can only be used once
Amount validation — Exact SOL amount must match endpoint pricing
Freshness check — Transactions older than 10 minutes are rejected
Verified live on mainnet — Tested with real SOL transfers

Access Tiers

Tier	Auth Method	Rate Limit
Free	None	100 calls/day per IP
x402 Pay-Per-Call	`X-PAYMENT` header (SOL tx sig)	Unlimited

🔧 Configuration

Variable	Description	Default
`HELIUS_RPC_URL`	Solana RPC endpoint (Helius recommended)	`https://api.mainnet-beta.solana.com`
`PORT`	API server port	`3400`
`HOST`	Bind address	`0.0.0.0`
`BIRDEYE_API_KEY`	Birdeye API key (optional, enriches scans)	—
`TREASURY_WALLET`	SOL payment recipient (x402)	—
`CACHE_TTL_SECONDS`	Cache duration	`300`
`FREE_TIER_CALLS_PER_DAY`	Free tier rate limit	`100`
`UPSTASH_REDIS_REST_URL`	Upstash Redis URL for persistent rate limiting	—
`UPSTASH_REDIS_REST_TOKEN`	Upstash Redis auth token	—

📊 Performance

Tested with 50-token bulk scan on Solana mainnet:

Metric	Value
Success rate	50/50 (100%)
Avg response time	5.4s
x402 payment verification	Verified live on mainnet

📦 Tech Stack

Runtime: Node.js 22+ (ESM)
Language: TypeScript 5.9
Blockchain: @solana/web3.js (direct RPC, no wrapper SDKs)
API: Express 5
MCP: @modelcontextprotocol/sdk
Market Data: Birdeye API v3
NFT Data: Magic Eden v2 API (free tier)
Wallet Intel: Helius DAS / Identity / Funded-By APIs
Pool Data: GeckoTerminal API + Raydium V4 byte decode

🛡️ Why SicariusGuard?

Most token safety tools rely on third-party APIs that can be gamed. SicariusGuard reads raw mint account bytes directly from the blockchain — the same data the Solana runtime uses to execute transactions. No middleman, no stale data, no API that can be fooled.

Feature	SicariusGuard	RugCheck	GoPlus
Byte-level SPL analysis	✅	❌	❌
Token-2022 extension scanning	✅	❌	Partial
Jupiter honeypot simulation	✅	❌	❌
LP lock/burn detection	✅	✅	❌
Raydium V4 byte decode	✅	❌	❌
Token age analysis	✅	❌	❌
Deployer serial scammer detection	✅	❌	❌
NFT fraud detection	✅	❌	❌
Helius wallet reputation	✅	❌	❌
12-layer weighted scoring	✅	❌	❌
MCP server for AI agents	✅	❌	❌
x402 pay-per-call (SOL)	✅	❌	❌
Self-hosted (no vendor lock-in)	✅	❌	❌
Birdeye market enrichment	✅	❌	❌
Sub-6s full scan	✅	✅	✅

Build powerful agentic workflows by combining SicariusGuard with these complementary MCP servers:

Server	Description	Use With SicariusGuard
Pentagonal	AI-powered smart contract auditing for Solidity & Anchor/Rust	Audit the contract → scan the token with SicariusGuard
Desk3	Real-time cryptocurrency market data	Get macro market context → validate token safety
AgentForge	DeFi safety layer — SPL approval scans & contract registry	Check approvals → scan token safety with SicariusGuard
Financial Datasets	Stock & market data for AI assistants	Cross-market correlation analysis

⭐ Star History

📄 License

MIT — Built by Chronolapse411

🔗 Links

npm: npmjs.com/package/sicarius-guard
Live API: sicarius-guard-640545264957.us-east4.run.app
GitHub: github.com/Chronolapse411/sicarius-guard
Glama: glama.ai/mcp/servers/Chronolapse411/sicarius-guard
Smithery: smithery.ai/server/chronolapse411/sicarius-guard
Dev.to: How I Built a 12-Layer Token Safety Oracle
Twitter/X: @chronolapse411
Author: @Chronolapse411

Available Tools

11 tools

batch_scanA

Scan multiple Solana tokens in a single call for portfolio-level risk assessment. Runs the full 10-layer analysis (same as full_token_scan) on each mint in parallel. Returns a JSON object with scanned count and a results array, each containing mint, safe (boolean), finalScore (0-100), verdict, honeypot status, LP lock status, token age, liquidity, marketFlags, and walletAge. Max 10 tokens per batch. This is a read-only operation with no on-chain side effects. Use this when evaluating a portfolio, watchlist, or multiple tokens from a pool discovery. Do not use this for a single token — use full_token_scan or check_token_safety instead, as they return more detailed results.

ParametersJSON Schema

Name	Required	Description	Default
`mints`	Yes	Array of Solana token mint addresses to scan (max 10)

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behaviors: read-only, no on-chain side effects, parallel execution, max 10 tokens, and lists return fields. With no annotations provided, the description fully compensates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise two-sentence structure with no wasted words. Front-loaded with core purpose, then details efficiently. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool, the description covers purpose, usage, behavior, return fields, and differentiates from 10 siblings. No output schema, but return fields are described. Complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and describes the parameter. The description adds value by explaining the return structure and reinforcing the batch intent, going beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it scans multiple Solana tokens for portfolio-level risk assessment, runs full 10-layer analysis in parallel, and returns specific fields. Explicitly distinguishes from siblings by stating use case and naming alternatives for single token scans.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use (portfolio, watchlist, multiple tokens) and when-not-to (single token) with named alternatives (full_token_scan, check_token_safety). This leaves no ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_holder_concentrationA

Analyze token holder distribution to detect supply concentration (a key rug pull indicator). Returns a JSON object with concentrated (boolean), reason, and stats showing percentage held by top 1/5/10 wallets. Flags risk if top 1 holder >50%, top 5 >80%, or top 10 >90%. This is a read-only RPC call with no on-chain side effects. Use this when you specifically need holder distribution data; use check_token_safety for a broader safety analysis that includes this check among others.

ParametersJSON Schema

Name	Required	Description	Default
`mint`	Yes	Solana token mint address

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description clearly states 'This is a read-only RPC call with no on-chain side effects', fully disclosing the behavioral trait.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five concise sentences front-loading purpose, return format, thresholds, read-only status, and usage guidance. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description explains the return structure (boolean, reason, stats with thresholds) adequately. The single parameter and low complexity are well covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter 'mint' with 100% schema description coverage. The description mentions the return format but does not add extra meaning for the parameter beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies 'Analyze token holder distribution to detect supply concentration' with a clear verb and resource. It explicitly distinguishes from sibling tool check_token_safety, earning a top score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: 'Use this when you specifically need holder distribution data' and names alternative check_token_safety for broader analysis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_honeypotA

Check if a Solana token is a honeypot by simulating a sell order through Jupiter DEX. Zero cost — only requests a quote, no actual transaction is executed. Returns a JSON object with isHoneypot (boolean) and sellability details. This is a read-only operation with no on-chain side effects or gas costs. Use this when you only need to verify sellability; use check_token_safety for a broader 8-layer analysis, or full_token_scan for the most comprehensive 10-layer scan including market data.

ParametersJSON Schema

Name	Required	Description	Default
`mint`	Yes	Solana token mint address
`amount`	No	Raw token amount to simulate selling (default: 1000000)

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description fully explains behavior: read-only operation, no on-chain side effects, zero cost, only requests a quote. It also notes returns JSON with isHoneypot and sellability details, covering all behavioral aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact but includes necessary details; the second sentence is a bit long but contains relevant information about sibling tools. No superfluous content, and the main purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the return type (JSON with isHoneypot and sellability details) but lacks specifics on sellability fields. For a simple check, it is adequate and covers cost, side effects, and usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with clear descriptions for both parameters (mint and amount). The description adds context by explaining the simulation process, enhancing understanding of how parameters are used.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks if a Solana token is a honeypot by simulating a sell order through Jupiter DEX, with specific verb and resource. It distinguishes from sibling tools like check_token_safety and full_token_scan, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides when to use this tool (verify sellability) and when to use alternatives (check_token_safety for broader analysis, full_token_scan for comprehensive scan). This gives clear guidance on tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_lp_lockA

Check whether a Solana token's liquidity pool has its LP tokens burned or locked. Discovers the primary pool via GeckoTerminal/Raydium, decodes the Raydium V4 pool state, computes LP burn percentage, and checks holders against known burn addresses and locker programs (Streamflow, UNCX). Returns pool address, LP mint, burn percentage, lock type, and risk score. This is a read-only operation with no on-chain side effects. Use this for LP-specific analysis; use full_token_scan for comprehensive analysis.

ParametersJSON Schema

Name	Required	Description	Default
`mint`	Yes	Solana token mint address

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Explicitly states it is a read-only operation with no on-chain side effects, and describes the internal process (discover pool, decode state, compute burn percentage, check holders). No annotations provided, so description carries full burden and does so well, though edge cases or limitations are not mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the main purpose, though it includes some internal steps that could be trimmed. Still, it's not overly long and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description lists the return fields (pool address, LP mint, burn percentage, lock type, risk score) and explains the internal logic, which is sufficient for a read-only tool with one parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes the sole parameter as 'Solana token mint address' with 100% coverage. The description does not add additional meaning to the parameter beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it checks whether a Solana token's LP tokens are burned or locked, and distinguishes from siblings like full_token_scan for comprehensive analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises using this for LP-specific analysis and directs to full_token_scan for comprehensive analysis, providing clear when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_nftA

Perform a safety analysis on a Solana NFT combining Helius DAS on-chain metadata with Magic Eden marketplace intelligence. Returns riskScore (0-100), verdict (SAFE | CAUTION | HIGH_RISK | CRITICAL), collection verification status, floor price, volume, creator verification, and per-signal flags. Read-only — no on-chain side effects. Use this for NFTs; use check_token_safety for fungible SPL tokens.

ParametersJSON Schema

Name	Required	Description	Default
`mint`	Yes	Solana NFT mint address (base58)

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

States 'Read-only — no on-chain side effects,' which is critical behavioral info. Also describes data sources and return fields, compensating for missing annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first function and output, second usage guidance. No unnecessary words, heavily front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter, no output schema, but description enumerates return values (riskScore, verdict, etc.) and data sources, fully informing agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage with description for 'mint' parameter. Description adds 'NFT' and 'base58,' providing extra semantic clarity beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it performs a safety analysis on a Solana NFT, specifying data sources (Helius DAS, Magic Eden) and outputs. It also distinguishes from sibling tool check_token_safety for fungible tokens.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this for NFTs; use check_token_safety for fungible SPL tokens,' providing clear when-to-use and alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_token_ageA

Determine when a Solana token was created by finding its first-ever on-chain transaction. Returns creation timestamp, age in days, age category (newborn/young/adolescent/mature), and risk score. Newer tokens carry higher risk as they haven't been market-tested. This is a read-only RPC operation. Use this for age-specific analysis; use full_token_scan for comprehensive analysis.

ParametersJSON Schema

Name	Required	Description	Default
`mint`	Yes	Solana token mint address

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It correctly states the tool is read-only, mentions that newer tokens carry higher risk, and describes the output. However, it does not disclose error conditions, rate limits, or any potential side effects, which would be useful for full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences. The first sentence clearly explains the purpose and output. The second provides usage guidance. No unnecessary words; each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has a single parameter and no output schema, the description is highly complete. It describes the return values (timestamp, age, category, risk score) and provides interpretation context for risk. It also references the sibling tool for further analysis.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter 'mint' with a description 'Solana token mint address'. The tool description does not add additional semantics beyond what the schema provides. Since schema description coverage is 100%, the baseline score is 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool determines when a Solana token was created by finding its first transaction, and lists the returned fields (timestamp, age, category, risk score). It distinguishes from sibling tool full_token_scan, which is used for comprehensive analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this for age-specific analysis; use full_token_scan for comprehensive analysis,' providing clear guidance on when to use this tool versus an alternative. It also notes it is a read-only RPC operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_token_safetyA

Analyze a Solana SPL token for rug pull, honeypot, and safety risks. Call this BEFORE executing any swap or buy transaction. Performs 8 checks: mint authority, freeze authority, Token-2022 extensions, honeypot simulation, holder concentration, LP lock status, and token age. Returns a JSON object with a combined risk score (0-100) and verdict (SAFE | CAUTION | HIGH_RISK | CRITICAL). This is a read-only operation with no on-chain side effects. Rate limited to 100 free calls/day per IP. Use this instead of check_honeypot or check_holder_concentration when you need a comprehensive pre-trade safety check. Use full_token_scan instead when you also need Birdeye market data and wallet reputation.

ParametersJSON Schema

Name	Required	Description
`mint`	Yes	Solana token mint address to check (base58)
`txSignature`	No	Optional: tx signature of pool creation for deeper analysis
`isPumpSwap`	No	Set true for Pump.fun/PumpSwap graduated tokens

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states it is a read-only operation with no on-chain side effects and mentions a rate limit of 100 free calls/day per IP. It also outlines the 8 checks performed and the return format. However, it does not mention potential failure cases or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, front-loading the purpose and usage, then detailing specific checks and alternatives. While slightly long, every sentence adds value and avoids redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 checks, multiple sibling tools, no output schema), the description covers all essential aspects: purpose, when to use, behavioral traits, parameter roles, return format (risk score and verdict), rate limits, and explicit alternatives.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds slight context (e.g., txSignature for deeper analysis, isPumpSwap for Pump.fun tokens) but does not significantly enhance meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes Solana SPL tokens for rug pull, honeypot, and safety risks, and explicitly distinguishes it from sibling tools like check_honeypot and check_holder_concentration by positioning it as a comprehensive pre-trade check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Call this BEFORE executing any swap or buy transaction' and provides clear alternatives: 'Use this instead of check_honeypot or check_holder_concentration... Use full_token_scan instead when you also need Birdeye market data and wallet reputation.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

full_token_scanA

Most comprehensive 10-layer safety analysis: combines on-chain byte-level inspection (mint auth, freeze, Token-2022, honeypot, holders), LP lock detection (burn %, locker status), token age analysis, Birdeye market intelligence (liquidity, volume, wash trading), and Helius wallet reputation data. Returns a JSON object with layered breakdown, weighted finalScore (0-100), verdict (SAFE | CAUTION | HIGH_RISK | CRITICAL), and detailed per-layer data. This is a read-only operation with no on-chain side effects. Use this for high-value trades where you need maximum confidence; use check_token_safety for a faster check without market data. Rate limited to 100 free calls/day per IP.

ParametersJSON Schema

Name	Required	Description
`mint`	Yes	Solana token mint address
`txSignature`	No	Optional: tx signature for deeper analysis
`isPumpSwap`	No	Set true for PumpSwap graduated tokens

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Declares read-only operation with no on-chain side effects, and describes output format (JSON with layered breakdown, finalScore 0-100, verdict). No annotations provided, so description carries the burden; lacks details on error states or data freshness, but otherwise transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise at about 3 sentences, front-loaded with the core purpose and key differentiators. Every sentence adds value: functionality, output, use case, rate limit. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, description fully covers return structure. With many sibling tools, it clearly explains when to use this vs alternatives, and includes rate limits. Adequate for a complex analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with all 3 parameters described. Description adds context: mint is the token address, txSignature for deeper analysis, isPumpSwap for graduated tokens. Baseline 3 due to high coverage, with added clarity earning a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it performs '10-layer safety analysis' and enumerates specific checks like mint auth, freeze, LP lock, token age, market intelligence, and wallet reputation. Explicitly distinguishes from sibling tool check_token_safety by noting the latter is faster but lacks market data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises use for 'high-value trades where you need maximum confidence' and directs to check_token_safety for faster checks. Also notes rate limit of 100 free calls/day per IP, helping the agent plan invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_market_intelA

Get real-time market intelligence for a Solana token from the Birdeye API. Returns a JSON object with price, 24h volume, liquidity depth, market cap, holder count, 24h price change, and market risk flags (wash trading, low liquidity, extreme volume-to-liquidity ratios). This is a read-only API call with no on-chain side effects. Use this for trade sizing, market health assessment, and liquidity analysis. Do not use this for safety/rug-pull checks — use check_token_safety or full_token_scan for that. Requires a Birdeye API key for data.

ParametersJSON Schema

Name	Required	Description	Default
`mint`	Yes	Solana token mint address

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It declares the tool is read-only with no on-chain side effects and requires a Birdeye API key. This information is useful but could also mention rate limits or error handling. Still, it provides good transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with each sentence serving a distinct purpose: stating the main action, clarifying read-only nature, listing use cases, and providing exclusions. It is well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description enumerates the key fields in the returned JSON object. It covers use cases, prerequisites (API key), and alternative tools, making it contextually complete for a simple one-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description repeats the schema's description of the 'mint' parameter ('Solana token mint address') but does not add further semantic detail beyond that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves real-time market intelligence for a Solana token from the Birdeye API, listing specific data returned (price, volume, market cap, etc.). It distinguishes itself from sibling tools like check_token_safety and full_token_scan by explicitly excluding safety checks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use the tool (trade sizing, market health assessment, liquidity analysis) and when not to (safety/rug-pull checks), naming specific alternative tools (check_token_safety, full_token_scan).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_wallet_reputationA

Analyze a Solana wallet's reputation using Helius DAS identity data and funding chain analysis. Checks deployer/wallet age, funding source identity, and known entity classification. Returns a JSON object with creatorAddress, reputation verdict, riskScore, flags, creatorAge, and identity data. This is a read-only operation — queries Helius API with no on-chain side effects. Use this to evaluate whether a token deployer or counterparty wallet is trustworthy before transacting. Do not use this for token analysis — use check_token_safety or full_token_scan for that. Requires a Helius API key for full results.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Solana wallet address to investigate (base58)

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses it is a read-only operation with no on-chain side effects, queries Helius API, and requires an API key for full results. This is comprehensive given 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with key information upfront, but could be slightly more concise. Each sentence adds value, though the list of return fields might be streamlined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, no output schema), the description fully covers the tool's behavior, return fields, and limitations, making it complete for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'address' has schema description (base58 Solana wallet address). The description adds context that it is the wallet to investigate, providing some extra meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes Solana wallet reputation using Helius DAS identity data and funding chain analysis, with specific outputs. It distinguishes itself from sibling tools by explicitly excluding token analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use (evaluate wallet trustworthiness before transacting) and when-not-to-use (do not use for token analysis, use check_token_safety or full_token_scan instead).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recon_deployerA

Perform a deep background investigation on a Solana wallet to determine if they are a serial rugger. Analyzes their entire token deployment history algorithmically — no hardcoded blacklists. Returns a JSON dossier with: totalTokensLaunched, portfolio health breakdown (alive/abandoned/rugged), deadTokenRatio, wallet creation date, funding genesis (who funded them), Recidivism Score (0-100), and verdict (CLEAN | SUSPICIOUS | SERIAL_DEPLOYER | LIKELY_SCAMMER). Use this to evaluate a deployer before trusting their token. This is a read-only operation using DAS API and Enhanced Transactions — zero extra cost on Helius Developer plan.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Solana wallet address of the token deployer to investigate

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains it's a read-only operation using DAS API and Enhanced Transactions with zero extra cost, and details the JSON dossier structure. No annotations are provided, so the description carries the full burden and does well, though it could mention any potential limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat lengthy but well-structured with front-loaded purpose and clear details. It could be slightly more concise without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description thoroughly explains the return JSON dossier, covering all relevant fields. It also provides usage context and behavioral details, making it complete for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'address' is described in both the input schema and the tool description, which adds context by specifying it's the Solana wallet address of the token deployer. The description adds value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a deep background investigation on a Solana wallet to detect serial ruggers, using algorithmic analysis. It specifies the verb, resource, and method, distinguishing it from siblings like 'get_wallet_reputation' by focusing on rugger detection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises using the tool to evaluate a deployer before trusting their token, providing clear context. While it doesn't explicitly exclude cases or name alternatives, the use case is well-defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.1.0May 27, 2026
- Addedcheck_lp_lock
- Addedcheck_nft
- Addedcheck_token_age
- Addedrecon_deployer
7 tool updatesv1.0.0May 12, 2026
- First observedbatch_scan
- First observedcheck_holder_concentration
- First observedcheck_honeypot
- First observedcheck_token_safety
- First observedfull_token_scan
- First observedget_market_intel
- First observedget_wallet_reputation

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Scored 2026-05-27 13:45 across 11 tools

Disambiguation5/5

Each tool targets a distinct aspect of Solana token safety analysis (e.g., batch scanning, specific checks for honeypot, LP lock, holder concentration, NFT, wallet reputation, deployer background). No two tools have overlapping purposes, and descriptions clearly delineate when to use each.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., check_honeypot, get_market_intel, recon_deployer). Verbs are appropriately descriptive and uniform, aiding predictability for an agent.

Tool Count5/5

With 11 tools, the server is well-scoped for its domain of Solana token security analysis. Each tool serves a necessary function without redundancy, covering individual checks, comprehensive scans, and specialized analyses.

Completeness4/5

The tool surface covers a wide range of safety checks (token, NFT, wallet, deployer) and includes batch processing and market intelligence. A minor gap might be the lack of a direct buy simulation, but the honeypot check covers sell simulation, and the overall set is highly comprehensive.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

rugcheck-ai B
io.github.MrWizardlyLoaf
Solana token safety for AI agents — rug-pull, honeypot & Token-2022 trap detection before you buy.
Blockchain Cryptocurrency
21
agentforge A
io.github.acarchidi
DeFi safety layer for AI agents: wallet safety, token risk, tx decode/simulate. 20 tools.
Blockchain Web3 & Decentralized Tech Autonomous Agents
2
Token risk x402
com.ogenalabs
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
Blockchain Cryptocurrency
1
solenrich B
io.github.0xSardius
Solana onchain intelligence for AI agents: wallet risk, due-diligence, perps funding, smart money.
Blockchain Cryptocurrency Finance
4322

Related MCP Servers

Crypto MCP
Cryptocurrency Finance
kiss-kedaya
F
license
Not graded
quality
D
maintenance
A cryptocurrency price query service based on Model Context Protocol that provides tools for retrieving virtual currency prices, market trends, detailed information, and K-line data.
Updated a year ago (2025-03-23 08:59 UTC)
3
-
RAD Securityofficial
Security Cloud Platforms Monitoring
rad-security
A
license
C
quality
A
maintenance
CP server for RAD Security, providing AI-powered security insights for Kubernetes and cloud environments. This server provides tools for querying the Rad Security API and retrieving security findings, reports, runtime data and many more.
Updated 4 days ago (2026-09-08 11:18 UTC)
65
186
6
MIT
crypto-pegmon-mcp
Blockchain Cryptocurrency Monitoring
kukapay
A
license
A
quality
D
maintenance
An MCP server that tracks stablecoin peg integrity across multiple blockchains.
Updated a year ago (2025-05-05 17:42 UTC)
4
4
MIT
universal-blockchain
Blockchain Web3 & Decentralized Tech
zeta-chain
A
license
Not graded
quality
C
maintenance
An MCP server that connects ZetaChain CLI into your editor. Query balances, send cross-chain transactions, and manage universal contracts directly through MCP.
Updated 7 months ago (2026-02-19 22:31 UTC)
51
6
ISC

🛡️ SicariusGuard

🌐 Live API: https://sicarius-guard-640545264957.us-east4.run.app

📑 Table of Contents

🔍 What It Does

On-Chain Safety (Layers 1-5)

LP & Token Maturity (Layers 6-8)

Intelligence & Reputation (Layers 9-12)

5-Axis Weighted Risk Scoring

🚀 Quick Start

📡 API Endpoints

REST API (Port 3400)

Example Request

Example Response (/v1/scan)

🤖 MCP Server (for AI Agents)

Available MCP Tools (11)

Install via npx (Recommended)

Install in Claude Code

Install in Cursor

Install in VS Code

Install from Source (Claude Desktop / Cursor)

🏗️ Architecture

💰 x402 Payment Protocol

How It Works

Pricing

Example (Paid Request)

Security

Access Tiers

🔧 Configuration

📊 Performance

📦 Tech Stack

🛡️ Why SicariusGuard?

🔗 Related MCP Servers

⭐ Star History

📄 License

🔗 Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

RAD Securityofficial

🌐 Live API: `https://sicarius-guard-640545264957.us-east4.run.app`

Example Response (`/v1/scan`)