VerdictSwarm MCP Server provides AI-powered token security analysis using 6 adversarial AI agents to detect rug pulls, scams, and risks in crypto tokens across multiple blockchains (Solana, Ethereum, Base, BSC).
scan_token — Comprehensive 6-agent consensus analysis with configurable depth (basic, full, debate), returning detailed risk scores and security findings
get_quick_score — Fast cached risk score (0–100, A–F grade) with basic token metadata for rapid pre-trade checks
check_rug_risk — Focused rug-pull assessment evaluating mint/freeze authority, liquidity lock/burn, honeypot behavior, holder concentration, and bundle/sniper activity — returns a SAFE/CAUTION/DANGER verdict
get_token_report — Generates a human-readable markdown report summarizing score, risk level, red flags, and security checks
get_trending_risky — Query trending high-risk tokens by chain and minimum risk level (currently in development)
get_pricing — Retrieve the USDC micropayment pricing table, payment wallet address, and instructions for autonomous agents
verify_payment — Confirm a Solana USDC micropayment was received before invoking paid endpoints
Works with MCP-compatible clients (Claude Desktop, Cursor, Codex, Windsurf, etc.), requires no blockchain nodes (cloud API with sub-second cached responses), and supports free-tier access (10 lifetime scans) or paid access via API key or USDC micropayments.
Click on "Deploy 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., "@VerdictSwarm MCP Server Check if this token is safe: DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263 on Solana"
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.
VerdictSwarm is a pre-trade security layer for agents that touch crypto. This MCP server exposes the Verdict API v2 as a small set of read-only tools for token checks, size-aware exit screening, and live pricing discovery.
No account setup is required. If VS_API_KEY is absent, the server mints a free key on the first API-backed tool call and saves it in the platform user config directory.
uvx verdictswarm-mcpThen ask your MCP client: “Check DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263 on Solana at fast level.”
To supply an existing free or credits-backed key:
VS_API_KEY=vs1_your_key uvx verdictswarm-mcpUse this server entry (the env block is optional):
{
"mcpServers": {
"verdictswarm": {
"command": "uvx",
"args": ["verdictswarm-mcp"],
"env": {
"VS_API_KEY": "vs1_your_key"
}
}
}
}Without VS_API_KEY, the self-provisioned key is stored at:
macOS: ~/Library/Application Support/VerdictSwarm/config.json
Linux: ${XDG_CONFIG_HOME:-~/.config}/verdictswarm/config.json
Windows: %APPDATA%\VerdictSwarm\config.json
The file is created with user-only permissions where the operating system supports them. Set VS_CONFIG_DIR to override the directory.
Related MCP server: safeagent-token-safety
Tool | Description |
| Calls |
| Requests |
| Reads live pricing, levels, limits, and supported chains from |
The 0.1.x names scan_token, get_quick_score, check_rug_risk, get_token_report, and verify_payment are no longer advertised as MCP tools; clients see only the three current v2 tools above. An explicit call to an old name still returns a migration response and makes no legacy pay-lane request.
Free keys have per-level daily limits advertised by the API. If a limit is exhausted, the tool response says when the quota resets and preserves the complete x402 challenge. To continue immediately, set VS_API_KEY to a credits-backed key or use the returned x402 payment instructions.
The MCP client sends these attribution headers on API requests:
X-VS-Integration: mcp
X-VS-SDK-Version: 0.2.1
Environment variable | Default | Description |
| unset | Optional free or credits-backed v2 API key. |
|
| VerdictSwarm API base URL. |
|
| HTTP request timeout in seconds. |
| platform user config dir | Directory for the self-provisioned key. |
|
| MCP transport. Use |
|
| HTTP bind host. |
|
| HTTP bind port. |
For HTTP transport:
VS_TRANSPORT=streamable-http HOST=0.0.0.0 PORT=8000 uvx verdictswarm-mcpimport asyncio
from verdictswarm_mcp import VerdictSwarmApiClient
async def main():
client = VerdictSwarmApiClient()
verdict = await client.check_token("TOKEN_ADDRESS", "solana", "fast")
print(verdict["verdict"]["action"], verdict["verdict"]["score"])
asyncio.run(main())git clone https://github.com/sentien-labs/verdictswarm-mcp.git
cd verdictswarm-mcp
uv sync --extra dev
uv run --extra dev python -m pytest -qThe server supports Python 3.10–3.13 and both stdio and HTTP transports.
Used the server in an agent, bot, wallet, or dashboard? Share the client, runtime, where the risk check fits, and what worked or failed through the VerdictSwarm community page. You can also show an integration, choose a structured issue form, or add your project to ADOPTERS.md. Praise is never required. Stars should come only from people who independently find the project useful; agents must not automate them.
MIT licensed. See LICENSE.
Rug-pull-focused security scan. Checks mint/freeze controls, LP lock status, honeypot behavior, holder concentration, and returns SAFE/CAUTION/DANGER.
| Name | Required | Description | Default |
|---|---|---|---|
| token_address | Yes | Contract address of the token to check for rug-pull risk | |
| chain | No | Blockchain network: solana, ethereum, base, etc. | solana |
| api_key | No | API key for authentication (alternative to tx_signature) | |
| tx_signature | No | Solana USDC payment transaction signature for pay-per-call auth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it as a read-only, idempotent operation. The description adds valuable context on the specific checks performed and the output format (SAFE/CAUTION/DANGER), enhancing transparency beyond 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 two sentences, front-loaded with the purpose, and each sentence contributes meaning. No unnecessary words or repetition.
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 tool with good annotations and schema, the description provides the output format and a list of checks. It could mention chain support or error handling, but it is sufficiently complete for the agent to understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions, achieving 100% coverage. The description does not add new semantic information about parameters, but the schema is sufficient. 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 performs a 'rug-pull-focused security scan' and lists specific checks (mint/freeze controls, etc.), differentiating it from siblings like scan_token or get_quick_score. The verb 'checks' and resource 'rug-pull risk' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for rug-pull risk assessment but does not explicitly state when to use this tool versus alternatives like scan_token or get_quick_score. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current tool pricing and Solana payment details.
Includes USDC rates, wallet/mint, free-tier limits, and transaction instructions.
Optionally filter by tool name via the tool_name parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | No | Optional tool name to filter pricing for a specific tool only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent, so the description's job is lighter. It adds context about what is returned (rates, wallet, instructions), which goes beyond annotations. 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?
Three sentences, each adding value: purpose, contents, optional filtering. No redundant phrases. Front-loaded with the core action.
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?
No output schema exists, but the description lists key output items (USDC rates, wallet/mint, free-tier limits, transaction instructions). It could mention response format, but given tool simplicity, it is sufficient.
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 clear description for the only parameter. The description simply restates the optional filtering. No additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Return current tool pricing and Solana payment details', clearly stating the verb and resource. It lists specific contents (USDC rates, wallet/mint, free-tier limits, transaction instructions) and mentions optional filtering. This distinguishes it from sibling tools like scan_token or verify_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when pricing or payment details are needed, and mentions optional filtering. It doesn't explicitly state when not to use or name alternatives, but the context is clear given sibling tools have different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast cached token risk check.
Returns score (0-100), risk band, and key token metadata for quick pre-trade screening.
Free: 10 calls/day; paid calls: 0.02 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| token_address | Yes | Contract address of the token to check | |
| chain | No | Blockchain network: solana, ethereum, base, etc. | solana |
| api_key | No | API key for authentication (alternative to tx_signature) | |
| tx_signature | No | Solana USDC payment transaction signature for pay-per-call auth | |
| client_id | No | Client identifier for free-tier rate limiting | anonymous |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds valuable behavioral details: it is 'cached' and 'fast', returns specific data (score, band, metadata), and has a pricing model. These disclosures help the agent understand latency and cost implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, immediately stating the core purpose and return values, followed by critical pricing info. No extraneous words, and the most important details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (5 parameters, no output schema), the description adequately covers purpose, return values, caching behavior, and pricing. It could mention what 'risk band' values are, but the agent likely infers from context. Sibling tools exist but differentiation is implicit.
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 each parameter is already described in the input schema. The tool description does not add further parameter-level context (e.g., how to use api_key vs tx_signature). Baseline is 3 per guidelines for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fast cached token risk check' and specifies it returns a score, risk band, and metadata for quick pre-trade screening. This distinguishes it from sibling tools like 'check_rug_risk' or 'scan_token' which likely offer more detailed or different analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use it ('quick pre-trade screening') and includes pricing details ('Free: 10 calls/day; paid calls: 0.02 USDC'), which helps an agent decide based on rate limits. However, it does not explicitly contrast with sibling tools or give conditions to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a shareable markdown report for a token. Includes score, risk level, security findings, and recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| token_address | Yes | Contract address of the token to generate a report for | |
| chain | No | Blockchain network: solana, ethereum, base, etc. | solana |
| api_key | No | API key for authentication (alternative to tx_signature) | |
| tx_signature | No | Solana USDC payment transaction signature for pay-per-call auth |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds value by specifying output format (markdown) and key report elements (score, risk level, findings, recommendations). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and contents. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations and rich schema, description is mostly complete. It covers purpose and output content, but could mention authentication methods (api_key vs tx_signature) or that results are shareable. Slight miss given sibling tools 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?
Schema description coverage is 100%, so parameters are already documented well. The description does not add extra meaning beyond schema, only implicitly ties 'shareable markdown' to output but not to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'generate', resource 'shareable markdown report', and specific contents (score, risk level, security findings, recommendations). This differentiates it from siblings like 'get_quick_score' (just score) and 'check_rug_risk' (rug-specific).
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 explicit guidance on when to use this tool vs alternatives. Context like 'token analysis' is implicit but no mention of when to prefer 'get_quick_score' for speed or 'check_rug_risk' for focused risk assessment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a full 6-agent VerdictSwarm risk scan. Returns consensus score, risk level, and agent-level findings for safe trading decisions.
| Name | Required | Description | Default |
|---|---|---|---|
| token_address | Yes | Contract address of the token to scan | |
| chain | No | Blockchain network: solana, ethereum, base, etc. | solana |
| depth | No | Scan depth: 'full' for all 6 agents, 'quick' for fast check | full |
| api_key | No | API key for authentication (alternative to tx_signature) | |
| tx_signature | No | Solana USDC payment transaction signature for pay-per-call auth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, non-destructive, idempotent, and open-world. The description adds context about using 6 agents and returning a consensus score, but does not disclose behavioral specifics like authentication requirements or rate limits, which are left to the schema. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the action and immediately stating the output. Every sentence is informative with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema. The description explains the output structure but does not mention parameter details like depth options or authentication methods, which are in the schema. While schema descriptions cover parameters, the description could be more complete for 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?
All parameters have descriptions in the schema (100% coverage). The tool description does not provide additional parameter semantics beyond the schema descriptions. It hints at depth but does not elaborate.
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 performs a comprehensive multi-agent risk scan, distinguishing it from sibling tools like get_quick_score and check_rug_risk. It specifies the output includes consensus score, risk level, and agent-level findings.
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 states the tool is for 'safe trading decisions', implying usage when a full risk scan is needed, but does not explicitly contrast with sibling tools like get_quick_score or check_rug_risk. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a Solana USDC payment for a tool call. Returns verification status, sender, and required vs received amount.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_signature | Yes | Solana transaction signature to verify | |
| tool_name | Yes | Name of the tool the payment is for (e.g. scan_token, get_quick_score) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, indicating safe, read-only, idempotent behavior. The description adds return value details (verification status, sender, amounts), which complements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a list of return values, no filler words. Every sentence adds value, making it highly concise and well-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 mentions return fields (status, sender, amounts) but lacks details on structure or types. Still, it provides sufficient context for a verification tool with simple responses. Adequate but not exhaustive.
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 each parameter having a description. The tool description adds minimal extra meaning beyond the schema, only contextualizing tool_name as 'the tool the payment is for'. This meets the baseline but does not elevate it.
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: verifying a Solana USDC payment for a tool call. It specifies the blockchain and currency, and lists the return values, making it distinct from sibling tools which focus on token analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, though the sibling tools are unrelated. No when-not-to-use or alternative tool names are mentioned, leaving some ambiguity for an AI agent.
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.
check_rug_risk4 fields changedInput schema / properties / api_key / descriptionAdded value: +"API key for authentication (alternative to tx_signature)"Input schema / properties / chain / descriptionAdded value: +"Blockchain network: solana, ethereum, base, etc."Input schema / properties / token_address / descriptionAdded value: +"Contract address of the token to check for rug-pull risk"Input schema / properties / tx_signature / descriptionAdded value: +"Solana USDC payment transaction signature for pay-per-call auth"get_pricing1 field changedInput schema / properties / tool_nameAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional tool name to filter pricing for a specific tool only",
+ "title": "Tool Name"
+}get_quick_score5 fields changedInput schema / properties / api_key / descriptionAdded value: +"API key for authentication (alternative to tx_signature)"Input schema / properties / chain / descriptionAdded value: +"Blockchain network: solana, ethereum, base, etc."Input schema / properties / client_id / descriptionAdded value: +"Client identifier for free-tier rate limiting"Input schema / properties / token_address / descriptionAdded value: +"Contract address of the token to check"Input schema / properties / tx_signature / descriptionAdded value: +"Solana USDC payment transaction signature for pay-per-call auth"get_token_report4 fields changedInput schema / properties / api_key / descriptionAdded value: +"API key for authentication (alternative to tx_signature)"Input schema / properties / chain / descriptionAdded value: +"Blockchain network: solana, ethereum, base, etc."Input schema / properties / token_address / descriptionAdded value: +"Contract address of the token to generate a report for"Input schema / properties / tx_signature / descriptionAdded value: +"Solana USDC payment transaction signature for pay-per-call auth"get_trending_riskyscan_token5 fields changedInput schema / properties / api_key / descriptionAdded value: +"API key for authentication (alternative to tx_signature)"Input schema / properties / chain / descriptionAdded value: +"Blockchain network: solana, ethereum, base, etc."Input schema / properties / depth / descriptionAdded value: +"Scan depth: 'full' for all 6 agents, 'quick' for fast check"Input schema / properties / token_address / descriptionAdded value: +"Contract address of the token to scan"Input schema / properties / tx_signature / descriptionAdded value: +"Solana USDC payment transaction signature for pay-per-call auth"verify_payment2 fields changedInput schema / properties / tool_name / descriptionAdded value: +"Name of the tool the payment is for (e.g. scan_token, get_quick_score)"Input schema / properties / tx_signature / descriptionAdded value: +"Solana transaction signature to verify"v0.1.0check_rug_riskget_pricingget_quick_scoreget_token_reportget_trending_riskyscan_tokenverify_paymentScored across 6 tools
Each tool has a clear, distinct purpose: rug-pull check, pricing, quick score, report generation, full scan, and payment verification. No two tools overlap in functionality.
All tool names follow the verb_noun pattern consistently using snake_case (e.g., check_rug_risk, get_quick_score, scan_token). No mixing of conventions.
6 tools is appropriate for a token risk assessment service, covering quick and full scans, specialized rug check, report generation, pricing, and payment verification. The scope is well-balanced.
The tool surface covers the full workflow: pricing info, multiple risk assessment levels, report generation, and payment verification. No obvious missing operations for the stated domain.
Solana token safety for AI agents — rug-pull, honeypot & Token-2022 trap detection before you buy.
Instant rug-check for any EVM or Solana token, distilled to one clear 0-10 risk verdict.
Rug-check & launch radar for trading agents: composite honeypot score, EVM+Solana, keyless x402.
Honeypot detection & token risk scan for ERC-20s. Risk score 0-100, tax, source verification.
