Skip to main content
Glama
Sign In

HoneyLabs

by net.honeylabs
OverviewDiscussionsAdmin

UDP probes: DNS, QUIC and more

udp_activity_tool
Read-onlyIdempotent

UDP datagrams sent to the sensors: DNS questions, QUIC client fingerprints and other UDP probes, with the ports, networks and countries involved.

Use for "who is sending DNS ANY queries", "is anyone querying version.bind", "have you seen this QUIC JA4", "which UDP ports are probed", "what hits 5060/udp". Every other tool reads TCP only, so UDP questions belong here. A UDP source address can be forged: treat each address as claimed, never as evidence against it, and do not feed it to ioc_lookup_tool as proof.

query uses the /udp search grammar: 'qtype:ANY', 'qname:version.bind', 'proto:quic', 'port:5060 country:CN', 'ja4:q13d0310h3_55b375c5d22e_cd85d2d88918' or 'quic:3f1a9c2b7d40'; leave it empty for the overview. window: 24h, 7d (default) or 30d, shortened to the plan's query window when that is shorter (window_notice then says so). samples: 0 to 25 example datagrams, default 10.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "udp_activity_tool"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNo
windowNo7d
samplesNo

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.9/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent profile, and the description adds genuinely non-obvious behavior: UDP source addresses can be forged and must be treated as claimed, and the window is silently shortened to the plan's query window with a window_notice explaining it. Both are operational traits an agent could otherwise get wrong.

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?

Front-loaded with purpose and routing in the first two sentences, then grammar and parameter notes. The five example trigger phrases and five grammar clauses are dense but each maps to a distinct filterable field; slightly more enumeration than strictly necessary.

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?

Output schema exists so return shape needn't be explained. For a 3-parameter search tool with an opaque grammar, the description covers filtering syntax, defaults, limits, and the trust caveat on results — an agent can call it correctly without opening the schema.

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

Parameters5/5

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

Schema coverage is 0%, so the description carries the full burden and does: query uses the /udp search grammar with five concrete clause examples, window accepts 24h/7d (default)/30d with the plan-window shortening and window_notice disclosure, samples is bounded 0–25 with default 10. Nothing needed to construct a call is missing.

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?

States a specific resource (UDP datagrams seen by sensors: DNS questions, QUIC fingerprints, other UDP probes) rather than restating the name. Explicitly positions itself against siblings: "Every other tool reads TCP only, so UDP questions belong here."

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?

Gives concrete triggering questions ("who is sending DNS ANY queries", "what hits 5060/udp") plus an explicit exclusion — do not feed results to ioc_lookup_tool as proof. It also says an empty query returns the overview, removing ambiguity about the default path.

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