ipdata MCP by usefulapi
Look up location, network, company and threat data for IP addresses and ASNs in ipdata.
作者提供的说明(英文原文)
AI security scanner for Solidity + free CC0 dataset of Sherlock audit-competition acceptance rates.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
适用于网页版、桌面版和手机版 Claude:
https://wazir-x402.duckdns.org/api/bug-intel在终端中运行这条命令
claude mcp add --transport http bug-bounty-intelligence https://wazir-x402.duckdns.org/api/bug-intel粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"bug-bounty-intelligence": {
"url": "https://wazir-x402.duckdns.org/api/bug-intel"
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"bug-bounty-intelligence": {
"type": "http",
"url": "https://wazir-x402.duckdns.org/api/bug-intel"
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
ChatGPT 只能连接互联网上的服务器:
https://wazir-x402.duckdns.org/api/bug-intel菜单名称可能因套餐和版本不同而略有差异。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
我们还没有读取这个服务器的工具列表;我们会轮流检查各个端点。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
注册名称已通过 GitHub 账户 holistis 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
尚未检查;我们会轮流检查各个端点
尚未检查;我们会轮流检查各个端点
尚未检查;我们会在检查端点时读取工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在作者的云端运行。通过互联网连接,无需安装,但你发送的内容会经过作者的服务器。
GitHub 仓库最后更新于–,最新版本(1.0.3)于4个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。它通过 URL 连接,所以接受远程 MCP 服务器的应用也可以使用,例如开启开发者模式的 ChatGPT。
同一分类中有:ipdata MCP by usefulapi, MaxMind minFraud MCP by usefulapi, Lambda Labs MCP by usefulapi
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
Look up location, network, company and threat data for IP addresses and ASNs in ipdata.
MCP server for MaxMind minFraud — score transactions for fraud risk from your AI assistant.
Read GPU instances, types, images, filesystems and firewall rules; launch and terminate instances.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
AI-powered smart contract security analysis for AI agents and developers.
You need Node 22 or newer (what our recount workflow uses) and nothing else.
git clone https://github.com/holistis/bug-bounty-intelligence-mcp
cd bug-bounty-intelligence-mcp node results/2026-11-02-shop-setup-five-audits/check.mjs node tools/checker-selftest.mjs node tools/ranges-check.mjs
The first command recounts one result folder from its verdict files and checks its hashes. It runs offline.
The second command tests the checkers. It copies every result folder to a temp directory, plants a made-up finding id and a flipped verdict, and runs the check.mjs of that folder. CAUGHT is good. BLIND means the checker accepted the planted fault. Today no folder is BLIND. The last one, results/2026-10-26-evmbench, was fixed on 3 November 2026 in pull request 89. To see where we started, test the state before our fixes:
The third command checks the central index (results/README.md): every folder it names with a voided-answer count above zero must also be named under its "Ranges if the voided answers are counted" section. Tom Smart found that this was missing for five older folders on 4 November 2026 (issue 41). It covers that one index, not yet a newer folder's own README.
git worktree add ../selftest-before 0fafa23
node tools/checker-selftest.mjs ../selftest-before/results
Three of the five checkers a made-up id can reach were BLIND then.
First issues, each scoped to one folder or one audit: good first issues. How a change is reviewed and how credit works: CONTRIBUTING.md. The scan engine itself is not in this repository.
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.
The setup behind our deep scan found 14 of 20 known High findings on five public audits, one run each, graded by a copy of the benchmark's own judge. On the same five audits the leader's own report finds 15 of 20 under that copy. Every verdict, the exact reports the judge read and a script that recounts everything are in results/2026-11-02-shop-setup-five-audits, with the limits listed. All our result folders are listed in results/README.md, and the longer story is on our blog.
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.
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.
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.
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.
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.
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.
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.
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.
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:
只显示了开头部分;其余内容请在仓库中阅读