Skip to main content
Glama
Sign In

HoneyLabs

by net.honeylabs
OverviewDiscussionsAdmin

Who carries a fingerprint

fingerprint_population_tool
Read-onlyIdempotent

The population behind one client fingerprint over the full retained window: how many source addresses carry it, across how many networks and countries, the ports they hit, the top networks, a sample of addresses, and a read on its shape.

Use for "is this JA4 one botnet or a common tool", "how many networks use this HASSH", "how concentrated is this fingerprint". The concentration field says concentrated (many addresses on few networks), dispersed (many networks in one short burst on one or two ports, a coordinated operation spread thinly on purpose), spread (a common client) or mixed; concentrated and dispersed both point to one operator. For the individual events, use fingerprint_search_tool with a time window.

fp_type: 'ja4' (TLS; a QUIC JA4 starting with q is answered from UDP traffic, whose sources can be forged), 'akin' (HTTP request shape) or 'hassh' (SSH). No date range: it reads everything retained.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "fingerprint": "<fingerprint>",
      "fp_type": "<fp_type>"
    },
    "name": "fingerprint_population_tool"
  }
}

Input Schema

NameRequiredDescriptionDefault
fp_typeYes
fingerprintYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds important operational context: there is no date range and it reads everything retained. It also discloses the QUIC/JA4 UDP caveat that sources can be forged, and explains what concentration categories mean behaviorally.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and is information-dense, but it includes a long list of returned fields even though an output schema exists. That return-value recap is somewhat redundant, though the concentration interpretation earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, read-only aggregate tool with an output schema, the description is complete enough: it explains scope, allowed fp_type values, the no-date-range behavior, interpretation of concentration, and when to use the sibling event search instead.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning. It does this well for fp_type by enumerating 'ja4', 'akin', and 'hassh' and explaining the QUIC/JA4 nuance; it is less explicit about the expected format of the fingerprint string itself, though context makes it reasonably inferable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and scope: the population behind one client fingerprint over the retained window, including source addresses, networks, countries, ports, and concentration shape. It clearly distinguishes this aggregate/population view from fingerprint_search_tool, which is for individual events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit example questions that select this tool (botnet vs common tool, network count for a HASSH, concentration) and explicitly routes event-level lookup to fingerprint_search_tool. The only minor omission is that fingerprint_similar_tool is not mentioned, but the primary usage boundary is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All HoneyLabs toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources