Provides security auditing for Solana programs and Anchor frameworks, with static vulnerability detection and x402 payment invoice generation for 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., "@solana-auditor run a security audit on this Anchor program code"
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.
An autonomous security audit MCP server and CLI utility designed for Solana programs, Anchor frameworks, and AI Agent Wallets.
Supports automated x402 payment headers and micropayments in USDC for pay-per-audit AI workflows.
Program Vulnerability Scanner: Static analysis detecting missing Signer checks on authority accounts, unconstrained PDA derivations in invoke_signed, unverified external CPI program targets, and unsafe account closure resurrect vectors.
x402 Micropayment Protocol: Built-in paywall invoice generator that creates standardized x402 payment memos for automated agent-to-agent transactions.
Standard MCP Protocol: Implements Model Context Protocol tools (audit_solana_code and get_payment_invoice) compatible with Claude Code, Cursor, Codex, and OpenClaw.
Related MCP server: solidity-sentinel
All generated audit invoices route payments directly to the designated Solana recipient address:
FCGFGq1WRawg4oQ8zicwt3qX3FdsJPBZzAoC1ZSfp7oDnpm install
npm run build
npm testAdd to your MCP configuration:
{
"mcpServers": {
"solana-auditor": {
"command": "node",
"args": ["dist/index.js"]
}
}
}audit_solana_code({ sourceCode, programName }): Performs static security audit returning structured findings, severity, recommendations, and security score (0-100).
get_payment_invoice({ serviceName, amountUsdc }): Generates an x402 payment request invoice with recipient address and unique transaction memo.
MIT
Runs static security vulnerability audit on Solana Rust/Anchor source code.
| Name | Required | Description | Default |
|---|---|---|---|
| sourceCode | Yes | Rust/Anchor code to audit | |
| programName | No | Identifier of the program |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden; it does disclose the key behavioral trait 'static,' implying no code execution. However, it does not mention side effects, output format, potential latency, or limitations of the audit, so transparency is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence states the core function with no filler. The verb and object are front-loaded, making the purpose immediately clear.
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 simple two-parameter schema, the description is sufficient for basic selection and invocation. However, there is no output schema and no mention of what the audit returns or how programName is used, leaving some context missing for a security-audit tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: sourceCode and programName each have descriptions. The tool description adds no parameter detail beyond that, so it meets the baseline but does not enrich parameter understanding.
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 uses a specific verb ('Runs') and resource ('static security vulnerability audit on Solana Rust/Anchor source code'), unambiguously distinguishing the tool from get_payment_invoice. Even without a title, an agent can know exactly what this tool does.
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 clearly frames when to use it: when a static security audit of Solana/Anchor source code is needed. It does not spell out exclusions or alternatives, but the only sibling is an unrelated payment-invoice tool, so the usage context is effectively clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates an x402 payment invoice for automated agent micropayments in USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| amountUsdc | No | Amount in USDC (default 0.50) | |
| serviceName | No | Name of the audit tier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Generates an invoice' implies a creation action, but it does not disclose whether this triggers a payment, requires wallet authorization, creates an on-chain transaction, or is safe/idempotent. The return value and any side effects are left entirely unspecified.
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 front-loaded sentence conveys the core action, resource type, currency, and target audience with zero filler. It is appropriately sized for the tool's complexity.
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 no output schema and no annotations, the description should explain return format and side effects, but it does neither. It also fails to connect the invoice to the sibling audit_solana_code workflow, leaving an agent without enough context to know what happens after generating the invoice.
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%, and both parameters already have meaningful descriptions ('Amount in USDC' and 'Name of the audit tier'). The tool description adds only the USDC and audit-tier context already present in the schema, so it neither improves nor harms parameter understanding.
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?
Names a specific verb ('Generates'), a specific resource ('x402 payment invoice'), and a clear domain ('automated agent micropayments in USDC'). It is immediately distinguishable from the sibling audit_solana_code, which audits code rather than producing payment artifacts.
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 is for payment in an agentic micropayment flow and the serviceName parameter references an 'audit tier', suggesting use alongside an audit workflow. However, it never explicitly states when to use this versus audit_solana_code or whether the invoice must be paid before auditing.
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.
v1.0.0audit_solana_codeget_payment_invoiceScored across 2 tools
The two tools have completely distinct purposes: one audits Solana code, the other generates payment invoices. There is no overlap or ambiguity between them.
Both tools follow a consistent verb_noun pattern (audit_solana_code, get_payment_invoice), making the naming predictable and clear.
With only two tools, the server feels thin. The payment invoice tool is tangential to the core auditing purpose, making the tool count borderline for the stated domain.
The audit surface is minimal with only a single audit operation, lacking supporting features like audit history or status retrieval. The inclusion of payment invoicing is odd and doesn't fill functional gaps in the auditing workflow.
AI code security audits via x402 USDC: $0.01 scans, $0.50 audits, $5 auto-fixes. SAST/SCA.
Solana wallet forensics SDK, x402 pay-per-call, AI agents.
Solana address risk grades and token scans for AI agents. Pay-per-call via x402 (USDC on Base).
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.