The SolSentry MCP server provides Solana threat intelligence and rug pull risk analysis, enabling AI agents to assess wallet and token risk on Solana mainnet.
check_operator: Analyze a Solana wallet's history as a token deployer — returns confirmed rug count, risk label, behavioral tags, and a plain-English summary.
check_token: Evaluate a Solana token mint's risk profile — returns risk score, flags, operator history, and bundle detection to help decide whether to buy or list a token.
get_top_operators: Retrieve a ranked leaderboard of the worst serial rug pull deployers tracked by SolSentry (up to 50 operators), useful for blacklisting known bad actors.
get_network_stats: Fetch system-wide threat intelligence metrics including total scans, prediction accuracy, resolve rate, operator counts, and bot cluster data.
explain_risk: Get a plain-English explanation of why a specific wallet or token is considered risky — suitable for displaying warnings directly to end users.
The server continuously monitors Solana mainnet to track serial rug pull operators, bot clusters, and malicious token launches.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SolSentry MCP Check token 7GCihg... for rug risk"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
RugCheck tells you a fire is burning. SolSentry tells you who lit it.
SolSentry packages its public operator-risk intelligence surface as an MCP
server, a TypeScript SDK, and a skills bundle. All interfaces use the live REST
API at https://api.solsentry.app.
Precision is auditable per-mint at /v1/predictions/{mint} (live). Pull any
current system numbers from the live API rather than this README — never cite a
hardcoded accuracy/precision figure or operator-level aggregate as a standing fact.
API stats: https://api.solsentry.app/v1/stats
NPM: https://www.npmjs.com/package/@solsentry/mcp
GitHub org: https://github.com/solsentry
Related MCP server: token-rugcheck
Surface | Use it when | Entry |
MCP server | AI agents (Claude Desktop, Cursor, Claude Code, any MCP client) |
|
TypeScript SDK | TS backends, bots, wallets, dApps that don't speak MCP |
|
Skills bundle | Claude Code / Cursor with the Agent Skills spec |
|
All three call the public REST API at api.solsentry.app. No API key
required for read endpoints.
Numbers drift daily as predictions resolve — verify live: curl https://api.solsentry.app/v1/stats
solsentry-mcp/
├── src/ ← TypeScript source (MCP server + SDK)
├── skills/
│ └── solsentry-postdeploy/ ← 1 skill, 6 references (progressive disclosure)
│ ├── SKILL.md orchestrator: when to load each reference
│ └── references/
│ ├── threat-intel.md · generic risk lookup
│ ├── counterparty.md · pre-CPI counterparty check
│ ├── monitor.md · post-deploy program monitoring
│ ├── forensics.md · post-incident drain trace
│ ├── token-launch.md · pre-launch readiness for your own token
│ └── cluster-graph.md · operator/bot network exploration
└── docs/ ← public reference docs
├── risk-scoring.md · scoring methodology + thresholds
├── flags.md · canonical flag glossary
├── openapi.yaml · machine-readable REST spec
└── x402-example.md · paid endpoint integration exampleSolSentry monitors Solana mainnet continuously and tracks serial rug pull operators, bot clusters, and malicious token launches. The data is refreshed every 30 seconds and available to any client that speaks MCP or plain HTTP.
npx -y @solsentry/mcp{
"mcpServers": {
"solsentry": {
"command": "npx",
"args": ["-y", "@solsentry/mcp"]
}
}
}{
"mcpServers": {
"solsentry": {
"command": "npx",
"args": ["-y", "@solsentry/mcp"]
}
}
}Tool | Purpose |
| Risk profile of a wallet as a token deployer |
| Risk profile of a token mint |
| System-wide public metrics |
| Plain-language summary for a wallet or mint |
import { SolSentryClient } from "@solsentry/mcp/client";
const client = new SolSentryClient();
const stats = await client.get("/v1/stats");
console.log(stats);curl https://api.solsentry.app/v1/stats
curl https://api.solsentry.app/v1/operator/<wallet-address>
curl https://api.solsentry.app/v1/predictions/<mint-address>Environment variable | Default | Purpose |
|
| API endpoint |
| — | Bearer token for authenticated endpoints |
Public quality claim: precision is auditable per-mint at /v1/predictions/{mint}
(live) — re-verify on the day; never ship a hardcoded precision number.
Node.js >= 18
MIT
Site: solsentry.app
X (project): @solsentryai
Telegram: t.me/solsentryai
GitHub: github.com/solsentry
Email: hello@solsentry.app
Built by: Crash Diniz · @crashdiniz
Check the risk profile of a Solana wallet as a token operator/deployer. Returns confirmed rug count, risk label, behavioral tags, and a plain-English summary. Call this before interacting with tokens deployed by an address.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet_address | Yes | Base58-encoded Solana wallet address to check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It discloses that it returns specific data (rug count, risk label, behavioral tags, summary) and implies a read operation. No side effects mentioned, but adequate for the tool's nature.
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 redundant information. Purpose, return data, and usage guidance are front-loaded and concise.
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 or annotations, the description sufficiently covers purpose, parameters, return values, and usage context for an agent to correctly invoke the 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?
Single parameter with 100% schema description coverage. Description adds no additional meaning beyond the schema's 'Base58-encoded Solana wallet address to check,' 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 checks the risk profile of a Solana wallet as an operator/deployer, distinguishing it from sibling tools like check_token (token risk) and get_top_operators (listing).
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 guides when to use: 'Call this before interacting with tokens deployed by an address.' No explicit alternatives mentioned, but 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.
Check the risk profile of a Solana token by mint address. Returns risk score, risk flags, operator history, and bundle detection. Call this before buying or listing any token.
| Name | Required | Description | Default |
|---|---|---|---|
| mint_address | Yes | Base58-encoded Solana token mint address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description does not disclose behavioral traits such as read-only nature, authentication needs, rate limits, or error handling (e.g., invalid mint address). The burden is on the description, and it is insufficient.
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 concise sentences with no fluff. Front-loaded with purpose and key outputs. Could be slightly improved by structuring the return items, 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?
For a single-parameter tool with no output schema, description covers purpose and return fields but lacks specifics on response structure or error cases. Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (mint_address described). Description does not add extra meaning beyond the schema, which already explains 'Base58-encoded Solana token mint address.' 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?
Description explicitly states the tool checks the risk profile of a Solana token by mint address, lists returned items (risk score, flags, operator history, bundle detection), and distinguishes from siblings like check_operator and explain_risk through specific purpose.
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 clear direction to call before buying or listing any token, implying pre-trade due diligence. Does not explicitly state when not to use or compare with siblings, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a human-readable explanation of why a wallet or token is risky. Accepts either a wallet address (checked as operator) or a token mint address. Returns a plain-English warning suitable for displaying to end users.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Solana wallet address or token mint address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses input types (wallet or token address) and output type (plain-English warning), but does not mention any behavioral traits like idempotency, side effects, or authentication needs. Adequate but not detailed.
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, front-loaded with purpose. No wasted words; every sentence contributes meaningful 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 no output schema, description only states 'plain-English warning' without specifying structure, severity levels, or examples. Adequate for a simple tool but could be more 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%, but description adds value by clarifying that 'address' can be either a wallet address (checked as operator) or a token mint address, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get a human-readable explanation' and the resource 'why a wallet or token is risky'. Distinguishes from sibling tools like check_operator and check_token, which likely provide binary risk status rather than explanation.
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?
Implied when to use (when you need an end-user explanation) but does not explicitly state when not to use or mention alternative tools. Sibling tools exist but no guidance on choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SolSentry system-wide threat intelligence statistics: total scans, accuracy, resolve rate, operator counts, bot clusters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states what is returned. It fails to mention safety, permissions, side effects, or that it is read-only, leaving behavioral traits undocumented.
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?
A single sentence that is front-loaded with action and lists outputs. Efficient and clear, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values. However, it lacks usage guidance and behavioral context, making it minimally complete for a simple 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?
No parameters exist, so baseline is 4. The description adds value by enumerating the statistics returned, which is useful beyond the empty 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 verb 'get' and resource 'network stats', specifying system-wide threat intelligence statistics. It distinguishes from siblings like check_operator and check_token by focusing on aggregate 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?
No guidance on when to use this tool vs alternatives. It does not specify context or exclusions, leaving the agent to infer from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top Solana rug pull operators ranked by confirmed scam count. Returns a leaderboard of the worst serial deployers tracked by SolSentry.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of operators to return (1-50, default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the output as a leaderboard with 'confirmed scam count' and source (SolSentry), but does not disclose data freshness, pagination, or if the result is real-time. The behavioral traits are adequately but not richly described.
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, zero waste. The first sentence front-loads the purpose and resource, the second adds context. Every word 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?
For a simple read-only leaderboard tool with one optional parameter and no output schema, the description is complete. It states what is returned (ranked operators), the criterion (scam count), and the source (SolSentry). No additional completeness needed.
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% for the sole parameter 'limit', so baseline is 3. The description does not add any additional meaning or context for the parameter beyond what is in the schema (e.g., default value or typical use).
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 'Get the top Solana rug pull operators ranked by confirmed scam count', specifying both the verb ('Get') and the resource (top operators ranked by scam count). It distinguishes from siblings like 'check_operator' (individual check) and 'get_network_stats' (network-level stats).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a leaderboard of serial deployers, but does not explicitly state when to use vs alternatives (e.g., when needing a single operator check, use check_operator). No exclusions or when-not guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.2check_operatorcheck_tokenexplain_riskget_network_statsget_top_operatorsEach tool targets a distinct function: checking operator risk, checking token risk, explaining risk, getting network stats, and getting top operators. There is no overlap in purpose.
All tools follow a consistent verb_noun pattern with snake_case: check_operator, check_token, explain_risk, get_network_stats, get_top_operators. The naming is predictable and uniform.
With 5 tools, the server is well-scoped for risk assessment and monitoring of Solana tokens and operators. It covers core actions without unnecessary bloat.
The tool set provides full coverage for the domain: checking operator and token risk, explaining risk, and accessing system-wide statistics and top operators. No obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Solana token safety for AI agents — rug-pull, honeypot & Token-2022 trap detection before you buy.
Solana address risk grades and token scans for AI agents. Pay-per-call via x402 (USDC on Base).
Solana pre-trade safety for agents: rug check, honeypot sell-sim, drainer scan, tx preflight.
Solana onchain intelligence for AI agents: wallet risk, due-diligence, perps funding, smart money.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/solsentry/solsentry-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
