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., "@3ilm-mcp What is the acceptance rate for oracle manipulation?"
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.
MCP server exposing 3ilm — a curated knowledge base of 1,032 smart contract vulnerability findings from 10 fully-reconciled Sherlock audit contests.
Built for AI agents, security researchers, and audit tools that need structured data on which bug classes get paid, at what rates, and why.
3ilm (Arabic: علم, "knowledge") contains:
1,032 verified findings from 10 Sherlock contests (fully reconciled against contest outcomes)
12 vulnerability pattern categories with real acceptance rates, not estimates
Accepted and rejected examples per category — learn what passes triage
Related MCP server: Elytra Security MCP Server
Tool | Description |
| Keyword search across all 12 categories. Returns matching patterns with acceptance rates and examples. |
| Full stats table for one specific pattern: totals, acceptance rate, Sherlock-specific note, examples. |
| All 12 patterns ranked by volume with 🟢🟡🔴 acceptance indicators. |
npx 3ilm-mcpClaude Desktop — add to claude_desktop_config.json:
{
"mcpServers": {
"3ilm": {
"command": "npx",
"args": ["-y", "3ilm-mcp"]
}
}
}Cursor — add to .cursor/mcp.json:
{
"mcpServers": {
"3ilm": {
"command": "npx",
"args": ["-y", "3ilm-mcp"]
}
}
}Ask your AI assistant:
"What is the acceptance rate for oracle manipulation findings on Sherlock?"
"Show me all vulnerability patterns and their payout rates"
"Search for reentrancy vulnerabilities — what percentage get accepted?"
"What does a accepted flash loan finding look like vs a rejected one?"
Same underlying dataset as vulnerability-acceptance-rates.json — CC0, downloadable directly, no server required. That file is the canonical, publicly reproducible source; the numbers here are copied from it, not independently computed. Findings are reconciled against actual contest outcomes — no scraping, no estimates. See METHODOLOGY.md for the exact reconciliation method.
The 12 patterns: fee-miscalculation, dos-griefing, reentrancy, trusted-actor, overflow, staleness, rounding, access-control, oracle-manipulation, mev-slippage, liquidation, flash-loan.
Both MCP servers read the same verified data — they differ in scope:
3ilm-mcp (this repo) | ||
Pattern search / acceptance rates | Free | Free ( |
Full-repo contract scan | Not offered | $5 USDC via x402 ( |
Cost | Always free, no paid tier | Free tools + one paid tool |
Best for | Just want the pattern data via MCP, nothing else | Also want an actual scan of your own contracts |
If you only need to query acceptance rates, either server works identically for that. Use 3ilm-mcp if you want the smaller, free-only package; use bug-bounty-intelligence-mcp if you also want the paid full-repo scan tool.
HTTP API (pay-per-query, USDC on Base): https://wazir-x402.duckdns.org/api/vuln-search?q=oracle
x402 Tollbooth: all endpoints listed at /api/status
MIT
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Exact pattern name (kebab-case). One of: fee-miscalculation, dos-griefing, reentrancy, trusted-actor, overflow, staleness, rounding, access-control, oracle-manipulation, mev-slippage, liquidation, flash-loan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keyword search query. Examples: "oracle price manipulation", "reentrancy", "fee calculation", "flash loan", "access control", "rounding error" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.1get_pattern_detailslist_patternssearch_vulnerabilitiesScored across 3 tools
The tools appear distinct: search_vulnerabilities focuses on finding vulnerabilities, list_patterns enumerates patterns, and get_pattern_details retrieves specifics for a single pattern. Minor ambiguity exists as 'patterns' could relate to vulnerabilities, but the action verbs (search/list/get) clarify intent.
All names follow the snake_case verb_noun pattern: search_vulnerabilities, get_pattern_details, list_patterns. The verb (search/get/list) and noun (vulnerabilities/pattern) placement is consistent and predictable.
Three tools is within the well-scoped range (3-15) and fits a focused read-only knowledge base for vulnerabilities and patterns. Each tool serves a distinct purpose without unnecessary redundancy.
The set covers search, list, and get-details operations, which covers typical read-only workflows. A minor gap is the lack of a dedicated 'get_vulnerability_details' tool, but search_vulnerabilities may return sufficient details to compensate.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI security scanner for Solidity + free CC0 dataset of Sherlock audit-competition acceptance rates.
Read-only smart-contract security intelligence for autonomous agents.
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
Curated knowledge API for AI agents - skill packs, semantic search, validated patterns.
