bug-bounty-intelligence-mcp
Use this server to request paid AI-assisted Solidity security scans of public GitHub repos, poll scan reports, and query free historical vulnerability patterns.
scan_contract: Submit a public GitHub Solidity repo with optional protocol type; costs $5 USDC on Base via x402; returns ajob_id. The schema claims a 7-gate Al-Mizaan filter, but the README says the paid scan does not run that framework end-to-end.get_scan_report: Poll ajob_idfor queued/processing/complete status and, when done, retrieve the report URL and findings count.list_vulnerability_patterns: Free lookup of historical Sherlock vulnerability patterns and acceptance rates by protocol type, limited to exact-reconciled data.Scans apply only to public GitHub repos containing Solidity; results are hypotheses to review, not guaranteed audit findings.
Enables scanning of public GitHub repositories containing Solidity smart contracts to produce security vulnerability reports.
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., "@bug-bounty-intelligence-mcpscan https://github.com/myprotocol/contracts for vulnerabilities"
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.
Bug Bounty Intelligence: MCP Server
AI-powered smart contract security analysis for AI agents and developers.
Every public statement of ours that turned out wrong is listed, with the date and the fix, in ERRATA.md. The counting rule behind our results is MEASUREMENT-RULE-two-judge-strict.md.
Update, 25 October 2026, night: two free tools next to the scan
We ran Slither 0.11.6 and Aderyn 0.6.8 with default settings on the same contests and had the same two judges compare their output with the known High and Medium findings. They found none: Slither 0 of 34 and Aderyn 0 of 70, on the contests where our setup could run them. On the same contests our scan found 6 of 34 and 10 of 70 in its first 15 hypotheses. Static tools are not built for the business-logic flaws that contests reward, the older contests may be in the training data of the model behind our scan, and the judges are language models, so read it as a description and not as a ranking: results/2026-10-25-free-tools/README.md.
Related MCP server: agentshield-mcp
Update, 25 October 2026, night: a quick scan for 1 dollar
There are now two prices. The quick scan, POST https://x402.tokenizen.nl/api/bug-intel-quick for 1 USDC on Base, returns the 15 hypotheses the model is most confident about. The full scan, POST https://x402.tokenizen.nl/api/bug-intel for 5 USDC, adds 15 more with lower confidence. It is the same engine and the same kind of report. The hit rates we measured (8 of 105 and 5 of 66) are for the first 15 hypotheses, so they are the numbers of the quick scan; the second list is the extra of the full scan. The quick scan costs exactly 1 dollar because the official x402 client refuses payments above 1 dollar per request unless its owner raises the limit, and we checked with a real purchase that an agent with default settings can buy it: results/2026-10-25-v31/quick-scan-purchase/README.md. Both routes sign their offers.
Update, 25 October 2026, night: a standard x402 client can now buy the scan
Until today the scan endpoint accepted only a transaction hash from a payment you had made by hand, and it answered 400 to the signed authorization that standard x402 clients send, although its 402 answer said that would work. That is fixed. A standard client (@x402/fetch 2.28.0) bought the scan from a throwaway address, got the receipt in the response, and the six checks on the receipt pass: results/2026-10-25-v31/standard-client-purchase/README.md. It was a self test with our own money, one purchase. One thing a buyer needs to know: the official client refuses payments above 1 dollar per request unless its owner raises the limit, and the scan costs 5 dollars.
Update, 25 October 2026, night: the scan on contests from the last year
We ran the scan once on 9 Code4rena contests from September 2025 to March 2026 (66 known High and Medium findings), with the rule for reading the result written beforehand. The first 15 hypotheses of a report held 5 of the 66 (7.6 percent) and the first 30 held 8 (12.1 percent). That is the same rate as on the 8 Sherlock contests, so by our own rule the result holds on newer contests. It is still a low rate: 58 of the 66 known findings were not in the first 15. Numbers, judgements, the whole lists and the limits: results/2026-10-25-c4-fresh/README.md.
A report can now show up to 30 hypotheses, in two lists: the 15 the model is most confident about and 15 more with lower confidence. On the stored lists the second list held 8 known findings that the first list did not (5 on Sherlock, 3 on Code4rena), at a slightly lower precision. We chose this after seeing the numbers, so it is a product choice and not a pre-registered test.
Update, 25 October 2026, evening: the offer is signed
The paid endpoint now declares the x402 offer-receipt extension and signs its offer. You can check it yourself without paying: npx -y agent-receipt-verify https://x402.tokenizen.nl/api/bug-intel reaches level 2 (asks for payment the way x402 says, declares the extension, and the signature of the offer verifies). The signer is 0xf30b0706E78b3166745E6a2f351992321088058f. That key only signs offers and receipts and holds no funds. The key is bound to the service domain in DNS, the way section 4.5.1 of the offer-receipt specification describes: dig TXT _controllers.x402.tokenizen.nl lists it as a controller (set on 25 October 2026). The address that receives payments is the one in the payment section below.
After a payment the answer to the paid request carries a signed receipt for that payment transaction, in the body as receipt and in the PAYMENT-RESPONSE header (level 3). We have seen this on one real payment, a self test on Base mainnet with 5.1 USDC from the project's own address to the payment address of the service. The receipt, the transaction, the delivered report and a script that checks all of it are in results/2026-10-25-v31/first-real-payment/. Nobody else has used the receipt yet, and the conformance checker still shows level 3 as not measured because it checks without paying. A receipt says that our service saw payment transaction X for this resource. It says nothing about how good the report is.
Update, 25 October 2026: version 3.1 is live
Paid scans now run on a newer version, V3.1. On the same 8 contests as the sealed run it found 8 of 105 known High and Medium findings (7.6 percent), against 4 for the version before it and 1 for the scan that was in production until the evening of 25 October: results/2026-10-25-v31/README.md. Two things changed at once and those contests are no longer secret, so this is a doubling from a low level and not a proof. 97 of the 105 were still not found. A scan takes about 20 to 45 seconds and costs us 0.02 to 0.15 dollar. The earlier version stays in place as the fallback.
Update, 24 October 2026, evening: the sealed run
The one run on the sealed set is done, with the rule written before it: results/2026-10-24-sealed/README.md. On 8 contests that nobody here had run anything on, the scan as it runs today found 1 of 105 known High and Medium findings. A newer version, not in production, found 4 of 105. The rule needed at least 5 findings that production does not find, and it found 3, so production stays as it is. The scan still produces hypotheses to review by hand, and it has not been shown to find what a human audit finds.
Update, 24 October 2026, later the same day: version 2 of the scan
The defects described below were fixed and the new version is live. What changed: git submodules are fetched when they point to github.com, tests, mocks, scripts, interfaces and vendored libraries are left out, files are ranked by how likely they move funds and sent in at most six parts, every report states how much of the in-scope code was read, a scan without hypotheses is delivered as such and not as a normal report, hypotheses that name files or functions that are not in the code are dropped, and file links inside a repository are never followed. A free precheck at https://x402.tokenizen.nl/api/bug-intel/precheck?repo=owner/name says before you pay whether the scan counts any Solidity in your repository and roughly how much of it will be read.
The measurement of this version was pre-registered before it ran: PREREGISTRATION-v2-2026-10-24.md. The frozen files are in pipeline/v2.
Result, in RESULTS-v2-2026-10-24.md: none of the 40 known High and Medium findings was found, 0 of 31 on the four contests of the first run and 0 of 9 on three new contests, while 29 percent of the in-scope code was read (8 to 100 percent per contest). 15 of the 40 known findings sit in a file that was read, and none of those was found. The scan produces hypotheses to review by hand. It has not been shown to find the issues that audit contests reward.
Correction and limits (24 October 2026, before version 2)
Reading the production scan code on 24 October 2026 showed that earlier text on this page overstated what the paid scan does. What it does today:
It sends the model at most about 22,000 characters of Solidity source per job, taken from up to 60 files in directory order, and it does not skip test or mock folders. On three recent audit-contest repositories (code-423n4/2025-11-merkl, 2025-11-sukukfi and 2026-04-monetrix) that is 3 to 7 percent of the Solidity source.
The 7-gate filter is not part of the paid scan. It was taken out because the small model also eliminated real bugs. The report lists raw hypotheses with a self-reported confidence of 0.4 or higher, at most eight, and its disclaimer says so.
The sample below ran on a repository that belongs to the corpus the framework was built from. It does not show how the scan does on projects it has not seen, and its label "CONFIRMED by Al-Mizaan validation" does not apply to the scan as it runs today.
We have not measured how many real bugs the scan finds on contests it has not seen. A test on closed audit contests is pre-registered in PREREGISTRATION-2026-10-24.md. The baseline ran on 24 October 2026: 0 of 31 findings found, 2 hypotheses reported and neither matches, one job failed and two reports were empty. See RESULTS-2026-10-24.md. Until a changed version is pre-registered and measured, do not read this scan as something that finds bugs on projects it has not seen.
Official source: this repository and the payment address in the payment section below are the only official ones for Bug Bounty Intelligence. If a listing, a reply or a website gives a different payment address, it is not ours. Check the address against the one below before you pay.
Drawn from a corpus of 27,681 submitted findings across 105 Sherlock and Code4rena contests.
Cost: $5 USDC on Base (eip155:8453) via x402 for the full scan, $1 USDC for the quick scan.
Free tool: list_vulnerability_patterns, no payment needed.
list_vulnerability_patterns' acceptance-rate numbers are computed only from the subset where
results could be exactly reconciled against Sherlock's own published outcomes: 1,032 findings
across 10 contests. We'd rather show fewer, verified numbers than a bigger set we can't stand
behind. See METHODOLOGY.md for exactly why, and how to reproduce it.
Free dataset: no server, no MCP, no payment
vulnerability-acceptance-rates.json is the same data
list_vulnerability_patterns serves, as a static file. No API call, no account, no network
dependency at all. Download it, or copy it into your own tool's rule set. CC0 licensed, use it
however you want, credit optional.
curl -sO https://raw.githubusercontent.com/holistis/bug-bounty-intelligence-mcp/main/vulnerability-acceptance-rates.jsonIf you're building a local-first / offline security scanner and the paid scan_contract tool
below isn't a fit for your project's architecture, this file might still be useful on its own.
Just want pattern search, nothing paid? Use 3ilm-mcp instead
3ilm-mcp is a smaller, free-only MCP server built from
the same verified dataset. It has no paid tier at all, just pattern search
(search_vulnerabilities, get_pattern_details, list_patterns). Use this repo
(bug-bounty-intelligence-mcp) if you also want the paid scan_contract scan; use
3ilm-mcp if you only ever wanted the free lookup tools and prefer the lighter package.
Two more tools in the same Al-Mizaan toolkit, for the rest of the workflow: al-mizaan-judge is a local CLI that pressure-tests a candidate finding through the same 7-gate framework before you submit it, and DeFi Signal API exposes the same vuln-search/bug-intel routes as a pay-per-call HTTP API for anyone who wants this outside MCP.
Benchmark: vs Slither
On 3FLabs/grunt (ERC-4626 + Morpho vaults, 218 contracts): Slither reports 27 "High" findings. After analysis: 24 are in lib/solady (out-of-scope dependency with known Slither false positive patterns), and 3 are EIP-712 design patterns. False positive rate: 100%.
In that comparison Bug Bounty Intelligence was pointed at src/ only. The paid scan now leaves out tests, mocks, scripts, interfaces and vendored libraries by rule. It does not run the 7-gate filter.
We also reported a related divide-before-multiply pattern on the same lib/solady code directly to the Slither project: crytic/slither#3039. A maintainer merged a fix for part of it (crytic/slither#3040); see BENCHMARK.md for the honest scope of what that fix does and doesn't cover, we overclaimed in the original report.
What it does
Submit a public GitHub repo containing Solidity smart contracts. Receive a report of AI-generated hypotheses, usually within a few minutes, that states how much of the code was read (see the update and the limits at the top of this page).
Tools
Tool | Description | Cost |
| Submit repo for security analysis | $5 USDC |
| Poll status and get report URL | Free |
| Show acceptance rates from exact-reconciled Sherlock contests | Free |
Quick start (Claude Desktop / Claude Code)
Also listed in PuPu's MCP store as of release v0.1.11 (registration issue).
Add to your claude_desktop_config.json:
{
"mcpServers": {
"bug-bounty-intelligence": {
"command": "npx",
"args": ["-y", "bug-bounty-intelligence-mcp@latest"]
}
}
}Or run directly:
npx -y bug-bounty-intelligence-mcp@latestPayment
If scan_contract returns PAYMENT REQUIRED, send exactly $5 USDC on Base to the address shown, then retry. Payment = acceptance of service terms.
x402 info:
Network: Base mainnet (eip155:8453)
Amount: 5,000,000 (= 5 USDC, 6 decimals)
Asset: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 (USDC)
Wallet: 0x015Eb036560216B3051339061FF68A207E0fe88f
The wallet address can change. Always pay the address scan_contract actually returns in its PAYMENT REQUIRED response, not a copy of this README. This document is updated when the address changes, but the live tool response is the source of truth.
Example session
> list_vulnerability_patterns({ protocol_type: "LENDING" })
Vulnerability patterns for LENDING protocols (from Sherlock audit findings, exact-reconciled contests only):
oracle-manipulation 36% accepted (131 cases)
liquidation 29% accepted (14 cases)
staleness 49% accepted (174 cases)
rounding 40% accepted (63 cases)
flash-loan 46% accepted (13 cases)
access-control 47% accepted (74 cases)
> scan_contract({ repo_url: "https://github.com/myprotocol/contracts", protocol_type: "LENDING" })
PAYMENT REQUIRED to start the scan.
Amount: 5.00 USDC
Network: Base mainnet (eip155:8453)
Pay to: 0x015Eb036560216B3051339061FF68A207E0fe88f
Asset: USDC — 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
After paying, retry scan_contract with the same repo_url.Sample scan output
Real scan of sherlock-audit/2025-03-crestal-network (Derivatives protocol, 29 contracts):
Summary: 0 Critical | 1 High | 0 Medium | 0 Low
Analyzed: 29 contracts | Model: qwen2.5:7b | Duration: 25min
FINDING #1 — HIGH
Title: Owner Can Arbitrarily Set Payment Addresses
File: Blueprint.sol
Functions: setCreateAgentTokenCost, setUpdateCreateAgentTokenCost,
addPaymentAddress, removePaymentAddress
Category: ACCESS
Description:
The owner can arbitrarily set payment addresses and costs without
any external validation or timelock.
Attack path:
An attacker with ownership calls setCreateAgentTokenCost or
addPaymentAddress to modify fees or redirect user payments to
an attacker-controlled wallet.
Impact:
Extremely high costs (griefing) or redirection of user funds.
Recommendation:
Implement a governance mechanism or timelock to restrict fee
and address changes.
Confidence: 0.90 (CONFIRMED by Al-Mizaan validation)About the analysis
The Al-Mizaan v3 framework defines 7 gates:
Code reading (literal, not docs)
Reachability chain (entry to exploit)
Threat model (who can trigger it)
Invariant breach (what rule is violated)
Protocol intent (was this intended?)
Impact (real financial damage)
Formal proof (reproducible PoC)
This is the framework used for manual review (the al-mizaan-judge CLI). The paid scan does not run it end to end, see the correction at the top of this page.
Service info
API endpoint: https://x402.tokenizen.nl/api/bug-intel
Free precheck: https://x402.tokenizen.nl/api/bug-intel/precheck?repo=owner/name
Delivery: usually within the hour, at most 48 hours according to the terms
If it fails or does not help: write to info@holistischadviseur.nl with the job id for a new attempt or a refund, see the terms
Source code: deleted after analysis
Support this project
This is a free, open-source MCP server maintained in my spare time. If it caught something useful before you shipped, tips are welcome and appreciated (never expected):
0xdffcC75a674257be6FE1b5549FE52e8f8a6A3A5A (USDC, Base)
Available Tools
3 toolsget_scan_reportAInspect
Poll the status of a job_id returned by scan_contract. Call this every minute or two after submitting — real runs have taken around 25 minutes, delivery is guaranteed within 24h, so polling faster than that just re-checks a job that is still processing. Returns status (queued/processing/complete), the repo under scan, and — once complete — reportUrl (the full Al-Mizaan-validated findings report) and findingsCount. A 404 means the job_id does not exist — double-check what scan_contract actually returned rather than retrying blindly.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job_id returned by scan_contract |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses all return fields (status, repo, reportUrl, findingsCount), mentions the 404 error case, and provides realistic timeframes. The mention of 'Al-Mizaan-validated' adds context. 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?
Well-structured: main action first, then timing, return info, and error handling. Each sentence adds value, though slightly verbose for the content. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter polling tool with no output schema, the description provides all necessary information: what it returns, when to call, and error behavior. Nothing essential is missing.
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 the schema fully documents job_id. The description repeats that it comes from scan_contract but adds no new format or validation details. 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 states a specific verb ('Poll') and resource ('job_id returned by scan_contract'), and clearly distinguishes from siblings by referencing scan_contract as the source of the job_id. It leaves no ambiguity about 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?
Provides explicit timing guidance ('every minute or two'), expected durations (25 min to 24h), and warns against polling faster. It also advises on 404 handling, telling the agent to verify the job_id rather than retry blindly. This is complete usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_vulnerability_patternsAInspect
Returns historical vulnerability patterns and acceptance rates from Sherlock audit-competition findings. Numbers are limited to contests where results could be exactly reconciled against Sherlock's own published outcomes (1,032 findings across 10 contests) — no estimated or unverifiable figures. Useful for understanding what types of bugs are most likely to be valid in a given protocol type. This tool is FREE — no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol_type | No | Protocol type to filter patterns (default GENERAL) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does well by explaining data provenance, exact reconciliation limits, and that no estimated or unverifiable figures are included, plus noting the tool is free. It does not cover return format, but for a read-only list tool this is sufficient context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action. The following sentences earn their place by clarifying data reliability, use case, and cost. The 'FREE' note is slightly tangential but still useful for agent decision-making.
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 low-complexity tool with one optional parameter and no output schema, the description covers what the tool returns, the scope of the data, a use case, and pricing. It could specify the exact output shape, but the absence of an output schema and the simplicity of the tool make this a minor gap.
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 single optional enum parameter that already documents 'protocol_type' and its default. The description adds only a passing implication of filtering by protocol type, so it does not meaningfully supplement what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and a clear resource ('historical vulnerability patterns and acceptance rates from Sherlock audit-competition findings'). The 'historical' qualifier and mention of statistical patterns clearly distinguish this analytics tool from the sibling scan_contract and get_scan_report tools.
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 a clear use case: 'useful for understanding what types of bugs are most likely to be valid in a given protocol type.' It does not explicitly list exclusions or alternatives, but the analytical framing and sibling tool names make the intended selection obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_contractAInspect
Submit a public GitHub repository for an automated smart contract security analysis. Runs the Al-Mizaan v3 7-gate framework (code, reachability, threat-model, invariant, protocol-intent, impact, formal proof) to filter out false positives before reporting anything — on a real benchmark run (3FLabs/grunt, 218 contracts) plain Slither reported 27 "High" findings with a 100% false-positive rate; see BENCHMARK.md for the full comparison. Pattern awareness is drawn from a corpus of 27,681 submitted Sherlock/Code4rena findings; the acceptance-rate numbers used elsewhere in this server (list_vulnerability_patterns) are limited to the 1,032 findings that could be exact-reconciled against contest outcomes — see METHODOLOGY.md. Cost: $5 USDC on Base (eip155:8453) via x402. Delivery is guaranteed within 24h — the sample run documented in README.md took about 25 minutes. Returns a job_id. Use get_scan_report to poll for results. If payment_required is true, pay $5 USDC to the payTo address on Base, then retry scan_contract with the same repo_url.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes | Public GitHub repo URL containing Solidity contracts (e.g. https://github.com/org/repo) | |
| protocol_type | No | Protocol category for targeted analysis (optional, default GENERAL) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden — and it delivers comprehensively: disclosed cost ($5 USDC on Base via x402), guaranteed 24h delivery with a ~25min sample, async job semantics (returns job_id), the payment retry flow, and the false-positive filtering behavior of the framework. Nothing about side effects or requirements is hidden. No contradiction with annotations (none exist).
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 actionable purpose is front-loaded, but the description carries meaningful extraneous weight — the Slither 100%-FP benchmark stat and the 27,681/1,032 corpus reconciliation figures are trust-building context rather than invocation-critical information. It's dense and well-organized, but not every sentence earns its place for the core task of calling the tool.
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 payment-gated, asynchronous tool with no output schema and no annotations, the description covers every invocation concern: cost and payment rail, expected delivery time, return value (job_id), the polling sibling, and the retry-after-payment branch. The get_scan_report sibling fills the result-format gap. Nothing an agent needs to invoke correctly is missing.
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 the schema already documents both parameters (repo_url with an example, protocol_type with its enum and default). The description adds a repo URL example and global workflow context but no per-parameter semantics beyond what the schema gives, so the baseline of 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 opens with a specific verb+resource: 'Submit a public GitHub repository for an automated smart contract security analysis.' It names the 7-gate framework and references both siblings (get_scan_report for polling, list_vulnerability_patterns for pattern data), so an agent can distinguish this from alternatives without reopening schemas.
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?
It explicitly instructs 'Use get_scan_report to poll for results' and lays out the end-to-end workflow including the payment-and-retry path when payment_required is true. It references list_vulnerability_patterns to disambiguate acceptance-rate numbers. It falls short only by not explicitly stating conditions under which this tool should NOT be used.
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.
3 tool updates
v1.0.4- First observed
get_scan_report - First observed
list_vulnerability_patterns - First observed
scan_contract
TDQS
Scored across 3 tools
Each tool has a clearly distinct role: list_vulnerability_patterns provides historical data, scan_contract starts a new analysis, and get_scan_report polls for results. There is no ambiguity or overlap between them.
All tool names follow a consistent verb_noun snake_case pattern: list_vulnerability_patterns, scan_contract, and get_scan_report. The naming clearly communicates the action and resource.
With only 3 tools the server feels slightly minimal, but the count is appropriate for a focused scan-and-report workflow. Each tool serves a distinct step in the user journey, so the size is reasonable rather than inadequate.
The server covers the full lifecycle from querying historical patterns to submitting a scan and retrieving the report. A minor gap is the lack of a way to list past jobs or cancel a scan, but this is not essential for the core purpose.
Maintenance
Related MCP Connectors
Solidity vulnerability scan (Slither) for AI agents. Free preview; full report 1 USDC on Solana x402
Token rug-risk scans, Know Your Agent wallet checks and deployer reputation for AI agents.
Read-only smart-contract security intelligence for autonomous agents.
Smart-contract risk reports for AI agents on 20 EVM chains, paid per call via x402 ($0.02 USDC).
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI coding agents to scan smart contracts and code for vulnerabilities, check against 12 famous-hack patterns, and return public security receipts directly in the IDE.412 npmMIT
- AlicenseBqualityDmaintenanceReal-time smart contract security for autonomous AI agents, offering tools for contract verification, wallet monitoring, drain detection, threat reporting, and leaderboards.1923 npmMIT
- AlicenseAqualityCmaintenanceEnables static security audit of Solidity smart contracts by analyzing source code or deployed bytecode for vulnerabilities, providing risk scores and detailed findings.1MIT

Draugrofficial
AlicenseAqualityAmaintenanceSecurity scanning for AI agents: SAST, SCA, secrets, IaC, DAST, ranked by real risk.6139Apache 2.0