Provides unified access to abuse.ch projects including URLhaus for malware distribution URLs, MalwareBazaar for sample lookups by hash, ThreatFox for IOC sharing, and Feodo Tracker for identifying active botnet C2 infrastructure.
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., "@MCP Threat Intel Server Check if the IP 185.220.101.1 is flagged in any threat intel databases"
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 providing unified access to multiple threat intelligence sources for security research and analysis.
If you're doing security research, incident response, or threat analysis, this MCP server lets you:
Unified lookups - Query IPs, domains, hashes, and URLs across multiple sources simultaneously
Reduce context switching - No need to open multiple browser tabs for different intel sources
Correlate intelligence - See results from all configured sources in one response
Free tier friendly - Works with free API tiers, gracefully degrades when sources unavailable
Works without keys - Feodo Tracker (botnet C2s) works without any API keys
Related MCP server: Threat Intelligence MCP Server
Category | Capabilities |
Unified Lookups | Query IPs, domains, file hashes, URLs across all sources |
AlienVault OTX | Threat pulses, indicators of compromise, community intelligence |
AbuseIPDB | IP reputation, abuse reports, confidence scores |
GreyNoise | Internet noise vs targeted attacks, scanner identification |
abuse.ch | URLhaus, MalwareBazaar, ThreatFox, Feodo Tracker |
Node.js 18+
API keys for your preferred threat intelligence sources (see below)
npx mcp-threatintel-serverOr install globally:
npm install -g mcp-threatintel-servergit clone https://github.com/aplaceforallmystuff/mcp-threatintel.git
cd mcp-threatintel
npm install
npm run buildAdd to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"threatintel": {
"command": "npx",
"args": ["-y", "mcp-threatintel-server"],
"env": {
"OTX_API_KEY": "your-otx-api-key",
"ABUSEIPDB_API_KEY": "your-abuseipdb-api-key",
"GREYNOISE_API_KEY": "your-greynoise-api-key",
"ABUSECH_AUTH_KEY": "your-abusech-auth-key"
}
}
}
}Add to ~/.claude.json:
{
"mcpServers": {
"threatintel": {
"command": "npx",
"args": ["-y", "mcp-threatintel-server"],
"env": {
"OTX_API_KEY": "your-otx-api-key",
"ABUSEIPDB_API_KEY": "your-abuseipdb-api-key",
"GREYNOISE_API_KEY": "your-greynoise-api-key",
"ABUSECH_AUTH_KEY": "your-abusech-auth-key"
}
}
}
}Service | Required | Free Tier | Get Key |
AlienVault OTX | Optional | Yes (unlimited) | |
AbuseIPDB | Optional | Yes (1,000/day) | |
GreyNoise | Optional | Yes (limited) | |
abuse.ch | Optional | Yes | |
Feodo Tracker | No | Yes | Public JSON feeds |
Note: Tools are dynamically enabled based on which API keys you provide. Feodo Tracker works without authentication (public JSON feeds).
"What threat intel sources are configured?"
"Show me threatintel status"
"Check if 185.220.101.1 is malicious"
"Look up this IP across all threat intel sources"
"Is evil-domain.com known to be malicious?"
"Check domain reputation"
"Look up this SHA256 hash in threat intel"
"Is this file hash known malware?"
"Check if this URL is in any blocklists"
"Show me active botnet C2 servers"
"Get Feodo tracker data for Emotet"
"Search OTX for recent ransomware pulses"
"Get latest threat intelligence pulses"
Tool | Description |
| Check which threat intelligence sources are configured |
Tool | Description |
| Look up IP across all configured sources |
| Look up domain across all configured sources |
| Look up file hash (MD5/SHA1/SHA256) across sources |
| Look up URL across sources |
Tool | Description |
| Check IP reputation and abuse history |
Tool | Description |
| Get recent threat intelligence pulses |
| Search pulses by keyword |
Tool | Description |
| Check if IP is internet noise or targeted threat |
Tool | Description |
| Look up URL, domain, or IP in URLhaus |
| Get recent malware URLs |
Tool | Description |
| Look up malware sample by hash |
| Get recent malware samples |
| Search samples by tag |
Tool | Description |
| Get recent IOCs from ThreatFox |
| Search ThreatFox IOCs |
Tool | Description |
| Get active botnet C2 servers (QakBot, Emotet, Dridex, etc.) |
# Watch mode for development
npm run watch
# Build TypeScript
npm run build
# Run locally
node dist/index.jsYou can use the server without any API keys - Feodo Tracker will still work. For other sources, add the appropriate API keys to your configuration.
Your API key is invalid or expired. Generate a new one from the respective service.
You've exceeded the rate limit for a service. Wait a while or upgrade your API tier.
If some sources return errors, the unified lookup tools will still return results from working sources. Check threatintel_status to see which sources are configured correctly.
Open Threat Exchange - community-driven threat intelligence platform with pulses containing indicators of compromise.
Crowdsourced IP reputation database with abuse reports from network administrators worldwide.
Identifies IPs scanning the internet vs targeted attacks. Helps reduce false positives in threat detection.
URLhaus - Malware distribution URLs
MalwareBazaar - Malware sample repository
ThreatFox - IOC sharing platform
Feodo Tracker - Botnet C2 infrastructure tracking
Contributions are welcome! Please see CONTRIBUTING.md for guidelines.
MIT - see LICENSE for details.
For additional threat intelligence capabilities, consider:
@burtthecoder/mcp-shodan - Shodan internet scanning
@burtthecoder/mcp-virustotal - VirusTotal malware analysis
Get active botnet C2 servers from Feodo Tracker (Emotet, Dridex, QakBot, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states what the tool retrieves, but does not disclose behavioral traits like whether it's read-only, rate limits, data freshness, or output specifics.
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?
Single sentence, front-loaded with action and key subject, no extraneous words. Highly efficient.
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 zero-parameter tool, the description is adequate but minimal. It lacks output format or data reliability context, which could leave an agent slightly uncertain about what to expect.
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?
Input schema has 0 parameters, so no param info needed. Description covers the tool's purpose adequately, meeting the baseline for zero-parameter tools.
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 'Get', resource 'active botnet C2 servers', and source 'Feodo Tracker', with examples of botnet families. It distinguishes from sibling tools like 'greynoise_ip' or 'threatintel_lookup_*' by specifying a specific threat feed.
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?
Description implies usage for retrieving Feodo Tracker data but does not explicitly state when to use this tool versus alternatives, nor provide conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if an IP is internet background noise or a targeted threat (GreyNoise)
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IP address to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only implies a lookup operation but does not mention side effects, rate limits, authentication requirements, or whether results are cached.
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, focused sentence that front-loads the purpose. 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 simple tool with one parameter and no output schema, the description is complete enough to convey the core functionality. It could mention API key requirements, but the current text is adequate.
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%, and the description adds meaningful context by explaining the classification (noise vs. threat), which goes beyond the schema's simple 'IP address to check'.
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 action ('Check'), the resource (an IP), and the two possible outcomes (internet background noise or targeted threat). This distinguishes it from sibling tools that check domains, hashes, or URLs.
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 no guidance on when to use this tool versus alternatives, such as threatintel_lookup_ip. There is no mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a domain across threat intelligence sources (OTX, URLhaus)
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or error handling. It only states the action and sources, leaving the agent uncertain about side effects.
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 with 9 words, containing only essential information (verb, resource, sources). No wasteful or redundant content.
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 and no annotations, the description is short and does not explain the return format or any additional context. It is adequate for a simple lookup but leaves gaps for an agent expecting detailed guidance.
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 parameter description. The tool description adds context about threat intelligence sources, which provides slight additional meaning beyond the schema, earning the baseline score.
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 verb (look up), resource (domain), and specific sources (OTX, URLhaus), effectively distinguishing it from sibling tools for hash, IP, and URL lookups.
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 usage for domain threat intelligence but does not explicitly exclude other use cases or mention alternatives. The sibling tool names provide context, but no when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a file hash (MD5, SHA1, SHA256) across threat intelligence sources (OTX, MalwareBazaar)
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | File hash (MD5, SHA1, or SHA256) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It omits any mention of side effects (none expected as read-only), error conditions (e.g., hash not found), API rate limits, or authentication requirements. The description is minimal and does not prepare the agent for potential issues.
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 of 13 words, directly stating the action and key details (hash types, sources). It is efficiently front-loaded with the verb and resource, with no filler or redundant information.
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 (1 parameter, no output schema, no annotations), the description covers the essential purpose but fails to describe the return format or any error handling. It is adequate for a minimum viable description but lacks completeness in explaining what the agent will receive after invocation.
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 the hash parameter described. The description adds value by specifying the intelligence sources (OTX, MalwareBazaar), which is not in the schema. This additional context helps the agent understand the scope and reliability of the lookup, improving upon the schema alone.
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 action ('look up'), the resource ('file hash'), and specifies the supported hash types (MD5, SHA1, SHA256) and intelligence sources (OTX, MalwareBazaar). This distinguishes it from sibling tools like threatintel_lookup_domain or threatintel_lookup_ip, which are for different resource types.
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 usage for file hash lookups but does not explicitly state when to use this tool versus alternatives (e.g., threatintel_lookup_domain for domains). No guidance on prerequisites or when not to use is provided, leaving the agent to infer context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an IP address across all configured threat intelligence sources (OTX, AbuseIPDB, GreyNoise, Feodo Tracker)
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IP address to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions 'look up', a read operation. It does not disclose behaviors such as response format, error handling, or rate limits.
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, clear sentence with no extraneous information; highly concise and 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?
For a simple one-parameter tool with no output schema, the description is adequate but could mention typical return values or the union of source responses.
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?
Input schema coverage is 100%, and the description adds no new meaning beyond the schema's property description for 'ip'. Baseline score applies.
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 verb 'look up' and the resource 'IP address across all configured threat intelligence sources', distinguishing it from sibling tools like feodo_tracker or greynoise_ip that target specific sources.
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 when to use the tool (for a comprehensive lookup across all sources) but does not explicitly state when to use alternatives or exclude certain scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a URL for malware/phishing indicators (OTX, URLhaus)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the lookup function but does not describe what the tool returns, whether it requires authentication, rate limits, or any side effects, leaving significant ambiguity.
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 with no wasted words, clearly stating the purpose. However, it could benefit from slightly more context without becoming verbose.
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 and no annotations, the description should explain what the response contains (e.g., threat score, list of indicators). It only specifies the action and sources, leaving the agent uncertain about the tool's output and behavior.
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 schema has 100% coverage for the single parameter 'url' with description 'URL to check'. The description adds no extra meaning beyond the schema, so it meets the baseline but does not exceed 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 looks up a URL for malware/phishing indicators and names specific sources (OTX, URLhaus). This verb+resource+scope clearly distinguishes it from sibling tools which handle different data types (domain, IP, hash).
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 when-to-use or when-not-to-use guidance. While the tool name and sibling tools imply it's for URLs specifically, no explicit alternatives or context for exclusion are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check which threat intelligence sources are configured. Currently available: greynoise, feodo
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description indicates a read operation without side effects. It explicitly lists current sources, but could mention it's read-only and safe.
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?
Single sentence that concisely states purpose and includes example output. No unnecessary 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?
Adequate for a simple status tool. Hints at return value (list of sources) but does not specify format or data type. Could be improved with explicit output 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?
No parameters; schema coverage is 100%. The description does not need to add param meaning. Baseline score for 0 parameters is 4.
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 checks which threat intelligence sources are configured, with specific examples (greynoise, feodo). This distinguishes it from sibling lookup 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?
Implied usage to verify configured sources before using lookup tools, but no explicit when-to-use or when-not-to-use guidance, nor alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct IOC type or source: feodo_tracker for botnet C2s, greynoise_ip for noise classification, and threatintel_lookup_* for domain, hash, IP, and URL lookups. There is no confusion about which tool to use for a given input type.
Most tools follow a 'threatintel_lookup_<type>' pattern, but 'feodo_tracker' and 'greynoise_ip' break this convention, creating a mix of styles. The naming is not fully predictable.
With 7 tools, the server covers the core threat intelligence operations without being bloated. The count feels well-scoped for the domain.
The set covers common IOC types (IP, domain, hash, URL) but has redundancy: feodo_tracker and greynoise_ip overlap with the combined threatintel_lookup_ip. Missing IOC types like email or CVE, and no write/update operations, though acceptable for a lookup service.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Free no-key IP intelligence: geolocation, VPN detection, DNS, WHOIS, blacklists, breach checks
Enrich and search people and companies, resolve identities, and enrich IP addresses.
Threat intel + your scans/findings/Shield posture. CVE, EPSS, KEV, package vuln lookup, DAST.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aplaceforallmystuff/mcp-threatintel'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
