honeylabs-mcp
OfficialServer Quality Checklist
Latest release: v1.0.3
- Disambiguation5/5
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.
Naming Consistency5/5All tool names follow a consistent pattern: <purpose>_tool (e.g., asn_enrich_tool, attack_timeline_tool). This uniformity aids predictability.
Tool Count5/5With 7 tools, the server is well-scoped for honeypot data analysis. Each tool serves a clear purpose without being excessive or insufficient.
Completeness5/5The set covers essential operations: IOC lookup, fingerprint/payload/event search, timeline trends, top attackers, and ASN enrichment. No obvious gaps for the domain.
Average 4.3/5 across 7 of 7 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
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.
Conciseness4/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior3/5
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.
Conciseness4/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior3/5
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.
Conciseness4/5Is 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.
Completeness4/5Given 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.
Parameters5/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness4/5Is 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.
Completeness3/5Given 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.
Parameters5/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters5/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
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