The HoneyLabs MCP server lets you query 90 days of real-world honeypot threat intelligence data — including IP reputation, attack trends, fingerprints, and raw events — directly from any MCP-compatible AI client.
ioc_lookup: Check if an IP/domain has been observed in honeypot data, including first/last seen timestamps, targeted ports, user agents, URL paths, and TLS/HTTP/SSH fingerprints.
top_attackers: Ranked leaderboard of attack sources grouped by IP, ASN, country, port, user agent, JA4 fingerprint, or URL path over a specified time window, with optional filters.
search_events: Retrieve raw honeypot event records filtered by source IP, country, ASN, destination port, protocol, or HTTP method.
attack_timeline: Hourly or daily attack volume trends over a time range, optionally filtered by protocol, country, or destination port — useful for spotting spikes or tracking scanning campaigns.
asn_enrich: Full profile of an ASN (hosting provider/network), including total events, unique IPs, top targeted ports, source countries, and user agents.
fingerprint_search: Find honeypot activity matching a specific TLS (JA4), HTTP (JA4H), or SSH (HASSH) fingerprint to identify shared infrastructure or track specific scanning tools.
payload_search (Pro/Team only): Full-text search across HTTP URL paths and user agents to find exploit attempts, CVE probing, or specific attack payloads.
Honeypot threat intelligence as MCP tools. Query 90 days of probe data from our honeypot sensor network: IP reputation, scanner classification, CVE probing trends, TLS/SSH fingerprints (JA4, JA3, JA4H, HASSH), mTLS client certificates, Community ID flow hashes, and attack timelines. Use it straight from Claude, Cursor, Gemini, Cline, or any other Model Context Protocol client.
🌐 Web: https://honeylabs.net
🔌 MCP endpoint: https://mcp.honeylabs.net/mcp (streamable HTTP)
🧰 Tool catalog & worked prompts: https://honeylabs.net/mcp
📖 Docs: https://honeylabs.net/docs
🔑 Access: free with a key, within fair-use limits
claude mcp add honeylabs \
--transport http \
https://mcp.honeylabs.net/mcp \
--header "Authorization: Bearer <your-key>"Get a key at https://honeylabs.net/dashboard (magic-link sign-in, no password).
Add to your MCP config:
{
"mcpServers": {
"honeylabs": {
"url": "https://mcp.honeylabs.net/mcp",
"headers": {
"Authorization": "Bearer <your-key>"
}
}
}
}Same JSON config as Claude Desktop / Cursor. Install via the MCP Marketplace listing or paste the config block above into your settings.
gemini /mcp add honeylabs https://mcp.honeylabs.net/mcp
gemini /mcp auth honeylabs # OAuth flow, no static keyOAuth 2.1 with PKCE + DCR is supported at /oauth/authorize. Any MCP
client that speaks standard OAuth (Gemini, MCP Inspector, Smithery,
Cline's OAuth flow) works out of the box.
Related MCP server: Google Threat Intelligence MCP Server
Tool | What it answers |
| Is this IP / domain known to be probing? Returns our verdict, whether it is a recognised benign scanner, the CVEs it probed, plus ports / paths / fingerprints. |
| Ranked leaderboard of source IPs, ASNs, countries, ports, user-agents, or CVEs ( |
| Raw honeypot events matching filters (IP, ASN, country, dest_port, protocol, http_method, ja4/ja3, community_id, has_client_cert). |
| Hourly / daily attack volume over a window, with protocol / country / port filters. |
| Full profile for an ASN: total events, unique IPs, top ports, source countries, user-agents, org name. |
| Search by TLS JA4 / JA3 / HTTP JA4H / SSH HASSH fingerprint to find shared infrastructure. |
| Who is probing a named CVE: severity, KEV status, top probing IPs with ASN and scanner tag, fingerprints, sample paths, daily timeline. |
| Full-text URL-path + user-agent search across attack traffic. |
Every tool is free to call. Plans differ by how much you can pull, not by which tools exist: each row in a response counts as one credit, and a free key gives 500 credits a day, with higher limits for heavier use. See https://honeylabs.net/docs#plans for the breakdown.
HoneyLabs runs a fleet of honeypots that get probed by the public
internet all day. Every probe, meaning every connection, TLS
handshake, and HTTP request, is logged with the source IP, ASN,
geo, TLS/HTTP/SSH fingerprints, and full URL path. We retain the
last 90 days and expose it through this MCP server, a JSON API, a
public lookup web UI at /lookup/<ip>, and CSV / STIX exports.
This is our own ground-truth record of what is actively scanning the internet right now, gathered first-hand rather than copied from a CVSS database or a third-party reputation feed.
Things to ask Claude / Cursor / Gemini once HoneyLabs is wired in:
"Is 80.82.77.202 a known scanner? When was it last seen and what does it probe?"
"Pull every IP that hit port 445 with a non-Windows User-Agent in the last 24 hours."
"Show CVE-2024-4577 probing volume per day for the last 7 days, broken down by ASN."
"Which CVEs are being mass-scanned this week, and who is behind the top one?"
"167.94.146.63 is hammering my firewall logs. Is that an attack or a research scanner?"
"For the top 10 attackers on port 6379 right now, what TLS JA4 fingerprints do they share?"
More worked examples at https://honeylabs.net/mcp.
The honeypot fleet itself (Spip-Go) and the enrichment pipeline (Loom) are public. This repo (the MCP / API surface) is closed.
Full honeypot profile for an ASN (autonomous system / hosting provider). Use for: 'tell me about AS202425', 'what is Vultr doing in my honeypots?', 'attacks from this hosting provider', 'attribute this IP to its network'. asn format: 'AS12345'. Returns: total events, unique IPs, top targeted ports, top source countries, top user agents, org name. since/until are ISO-8601 UTC strings.
| Name | Required | Description | Default |
|---|---|---|---|
| asn | Yes | ||
| since | Yes | ||
| until | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the return structure (total events, top ports, etc.) and states the input format requirements (ISO-8601 for dates, ASN format). This is adequate for a read-only enrichment tool.
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?
Two sentences plus a list of return fields. No redundant content; all information serves a purpose. The most critical info (purpose, usage, format) comes first.
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?
The description covers purpose, usage examples, parameter formats, and return fields. It does not discuss error handling or data limits, but with an output schema present, the agent can infer structure. Reasonably complete for this tool's complexity.
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 input schema has 0% description coverage, so the description must compensate. It specifies that 'asn' format is 'AS12345' and 'since/until' are ISO-8601 UTC strings. These format hints add meaningful semantics beyond the bare schema.
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 it provides a 'full honeypot profile for an ASN' and lists specific return fields. The usage examples differentiate from sibling tools like attack_timeline_tool or ioc_lookup_tool by focusing on ASN enrichment.
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 gives clear example queries ('tell me about AS202425', 'attribute this IP to its network'), showing when to use it. It does not explicitly contrast with siblings or state when not to use, but the examples sufficiently convey appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attack volume over time, bucketed by hour or day. Use for: 'show attack trends this week', 'was there a spike on port 22?', 'how has SSH scanning changed?', 'attack volume from China over 30 days'. bucket: 'hour' or 'day'. Optional filters: filter_protocol ('tls'/'''), filter_country (2-letter code), filter_dest_port. since/until ISO-8601 UTC.
| Name | Required | Description | Default |
|---|---|---|---|
| since | Yes | ||
| until | Yes | ||
| bucket | No | day | |
| filter_protocol | No | ||
| filter_country | No | ||
| filter_dest_port | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the core behavior (returns bucketed attack volume) and mentions optional filters, but does not disclose whether it is read-only, any rate limits, data freshness, or potential side effects. This is adequate but not thorough.
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 concise (two sentences plus a list of use cases and parameter notes) and front-loaded with the main purpose. It could be slightly more organized, but every sentence adds value without redundancy.
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 presence of an output schema (which covers return values) and the description's coverage of filters and use cases, the tool is well-specified for an agent to invoke correctly. Missing details like pagination or limits are minor given the context.
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 0%, and the description compensates fully by explaining each parameter's purpose and format: bucket ('hour' or 'day'), filter_protocol ('tls' or ''), filter_country (2-letter code), filter_dest_port, and since/until as ISO-8601 UTC. This provides essential context missing from the raw schema.
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's purpose: 'Attack volume over time, bucketed by hour or day.' It provides specific use-case examples ('show attack trends this week', 'was there a spike on port 22?') and distinguishes itself from sibling tools by focusing on temporal volume trends rather than enrichment or search.
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 includes concrete query examples like 'how has SSH scanning changed?' that implicitly guide usage. However, it does not explicitly state when not to use this tool or contrast with alternatives like search_events_tool, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search honeypot activity by TLS, HTTP, or SSH fingerprint. Use when a user asks: 'have you seen this JA4 fingerprint?', 'which IPs share this TLS fingerprint?', 'how common is this HASSH?', 'find all scanners with this SSH client fingerprint'. fp_type: 'ja4' (TLS client, 3.7M events), 'ja4h' (HTTP client, 3.2M events), 'hassh' (SSH client, 26K events). since/until are ISO-8601 UTC strings.
| Name | Required | Description | Default |
|---|---|---|---|
| fingerprint | Yes | ||
| fp_type | Yes | ||
| since | Yes | ||
| until | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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. It lacks details on behavioral traits such as read-only nature, rate limits, or whether results are real-time. The output schema covers return format, but the description does not mention it.
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, packing purpose, usage triggers, and parameter details in a single paragraph. It could be more structured (e.g., listing fp_types), but it is 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?
Given the complexity of 5 parameters and no annotations, the description provides enough context to use the tool, covering key parameters and usage scenarios. It does not explain the limit parameter or result format, but the output schema compensates.
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 0%. The description adds value for fp_type (with examples and counts), since, and until (ISO-8601 format), but does not explain the 'fingerprint' or 'limit' parameters, leaving gaps.
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 searches honeypot activity by TLS, HTTP, or SSH fingerprint, with specific user query examples. It distinguishes from siblings like ioc_lookup_tool by focusing on fingerprints.
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 explicitly provides usage triggers via example queries and explains fp_type options with event counts. It does not explicitly state when not to use it, but the examples cover common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up any IP address or domain in the honeypot dataset. Use this FIRST whenever the user asks: 'is this IP malicious?', 'is this a known scanner?', 'have you seen this IP?', 'what does this IP do?', 'when was it last seen?', 'is this IP in your data?'. Returns: total_events (0 = never observed), first_seen, last_seen, country, ASN, all ports targeted, top user agents, top URL paths, TLS/HTTP/SSH fingerprints. Covers both IPv4 and domains.
| Name | Required | Description | Default |
|---|---|---|---|
| ioc | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details return fields with meanings (e.g., 'total_events (0 = never observed)'), covers both IPv4 and domains, and implies read-only behavior for a lookup tool.
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?
Three well-structured sentences: action, example queries, return list. No redundant information, and purpose is 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?
Output schema exists, but description still covers return values. With one parameter fully explained and low complexity, the description provides complete context for selecting and invoking the 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 0%, but description fully explains the single parameter 'ioc' as 'any IP address or domain', adding clear meaning beyond the type definition.
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 it looks up IPs or domains in a honeypot dataset, with specific verbs ('look up') and resources. It includes example queries and differentiates by suggesting 'Use this FIRST', distinguishing it from sibling tools like fingerprint_search_tool or payload_search_tool.
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 usage context with example user questions and instruction 'Use this FIRST'. Lacks explicit when-not-to-use or alternatives, but the context strongly implies appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across HTTP URL paths and user agents in attack traffic. Use for: 'find attacks targeting /wp-admin', 'show exploit attempts for CVE-2024-XXXX', 'find requests with this user agent string', 'what payloads hit port 80 last week'. Pro/Team plan only. since/until are ISO-8601 UTC strings.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| since | Yes | ||
| until | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It explains that it searches payloads and requires a query, since, until, and optional limit. However, it does not describe what the output looks like, pagination, rate limits, or other side effects, which would be helpful.
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 fairly concise and front-loaded with the main purpose. It includes usage examples and format hints without excessive verbiage. Minor improvement could be structuring it as a list for readability.
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 there are 4 parameters, no annotations, and an output schema (not shown), the description provides sufficient context for an agent to understand the tool's purpose, usage context, and parameter constraints. It lacks some behavioral details, but overall it is complete enough for typical use.
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 0%, so the description must compensate. It explains that since/until are ISO-8601 UTC strings, which is valuable. However, it does not clarify the query parameter (though examples help) or the limit parameter. This partial coverage makes it adequate but not excellent.
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 it does full-text search across HTTP URL paths and user agents in attack traffic. This distinguishes it from sibling tools like search_events_tool or ioc_lookup_tool, which likely cover different data 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 provides concrete usage examples ('find attacks targeting /wp-admin', 'show exploit attempts for CVE-2024-XXXX') and mentions plan restrictions and date format. However, it lacks explicit guidance on when not to use it or comparison with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return individual raw honeypot events with all fields. Use when the user wants to see actual records: 'show me events from this IP', 'what hit port 443 last week', 'events from Russia yesterday'. Filters: source_ip, country (2-letter code), asn (e.g. 'AS12345'), dest_port, protocol ('tls' or ''), http_method. since/until are ISO-8601 UTC strings. Each record includes: source_ip, country, asn, dest_port, user_agent, url_path, tls_client_ja4, http_request_ja4h, ssh_client_hassh, network_protocol, timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| since | Yes | ||
| until | Yes | ||
| source_ip | No | ||
| country | No | ||
| asn | No | ||
| dest_port | No | ||
| protocol | No | ||
| http_method | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains that the tool returns raw events, lists the fields returned, and specifies filter parameter formats (ISO-8601 for dates, 2-letter country codes, ASN format). It doesn't mention any destructive actions, rate limits, or pagination, but the behavior is well-described for a query tool.
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 concise and well-structured: it starts with the core purpose, provides usage examples, then details parameters and output fields. Every sentence adds value with no redundancy or fluff.
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 that an output schema exists, the description still lists the output fields (source_ip, country, etc.), making the return format clear. All 9 parameters are addressed in the description, and the required parameters are clearly indicated. The tool's complexity is fully covered.
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 input schema has 0% description coverage, so the description must add meaning. It explains all parameters except 'limit': source_ip, country (2-letter code), asn (e.g., 'AS12345'), dest_port, protocol ('tls' or ''), http_method, and since/until (ISO-8601 UTC). This adds significant value beyond the schema.
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 it returns 'individual raw honeypot events with all fields' and provides concrete usage examples like 'show me events from this IP' or 'what hit port 443 last week'. This distinguishes it from sibling tools that likely provide aggregated or enriched data.
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 gives explicit contexts for using the tool (e.g., raw event queries) via examples. It doesn't explicitly state when not to use it, but the context is clear enough for an AI agent to decide. No alternatives are mentioned, but the examples imply unaggregated data use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked leaderboard of attack sources. Use for: 'who is attacking the most?', 'top attacking countries', 'most targeted ports', 'most common user agents', 'top ASNs by attack volume', 'top IPs from China', 'top attackers hitting port 22'. 'by' controls grouping: ip, asn, country, port, user_agent, ja4, url_path. Optional filters: country (2-letter ISO, e.g. 'CN'), dest_port, asn (e.g. 'AS12345'). Adding a filter is required for large time ranges to stay within memory limits. since/until are ISO-8601 UTC strings.
| Name | Required | Description | Default |
|---|---|---|---|
| since | Yes | ||
| until | Yes | ||
| by | No | ip | |
| limit | No | ||
| country | No | ||
| dest_port | No | ||
| asn | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses a behavioral constraint (memory limits requiring filters for large ranges) and explains the grouping parameter. 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?
The description is a single paragraph but efficiently packs purpose, examples, and parameter details. It front-loads the key purpose and is not overly verbose, though more structured formatting (e.g., bullet points) could improve readability.
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?
The description covers most parameters and usage details but omits the 'limit' parameter (default 20) and does not explain the output schema. Since an output schema exists, return value documentation is less critical, but the missing 'limit' mention is a 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 description coverage is 0%, so the description adds significant value by explaining 'by' options (ip, asn, country, port, user_agent, ja4, url_path), filter formats (2-letter ISO for country, 'AS12345' for ASN), and that since/until are ISO-8601 UTC strings. This effectively compensates for the lack of schema descriptions.
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 it's a 'Ranked leaderboard of attack sources' and provides specific example queries like 'who is attacking the most?', 'top attacking countries', etc., which differentiate it from siblings like attack_timeline_tool (timeline) and search_events_tool (general search).
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 lists example use cases and explicitly states when to add filters ('Adding a filter is required for large time ranges to stay within memory limits'). It doesn't directly contrast with siblings, but the guidance is clear enough.
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 use case: ASN enrichment, timeline, fingerprint search, IOC lookup, payload search, raw events, and top attackers. There is no overlap in functionality, making selection unambiguous.
All tool names follow a consistent pattern: <purpose>_tool (e.g., asn_enrich_tool, attack_timeline_tool). This uniformity aids predictability.
With 7 tools, the server is well-scoped for honeypot data analysis. Each tool serves a clear purpose without being excessive or insufficient.
The set covers essential operations: IOC lookup, fingerprint/payload/event search, timeline trends, top attackers, and ASN enrichment. No obvious gaps for the domain.
Security intelligence for AI agents. 27 x402 endpoints: honeypot, forensics, CAPTCHA, preflight.
GreyNoise Community MCP — internet scanner classification (free tier with key)
Free no-key IP intelligence: geolocation, VPN detection, DNS, WHOIS, blacklists, breach checks
Public data intelligence for AI agents — CVE, compliance, patents, contracts, domains.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/honeylabshq/honeylabs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
