Skip to main content
Glama

Hackertarget

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Whois

whois
Read-onlyIdempotent

"Who owns [domain]" / "when does [X] expire" / "whois lookup" / "registrar for [site]" — WHOIS record via HackerTarget for a domain or IP: registrar, creation and expiry dates, nameservers, and whatever contact fields the registry still publishes. REQUIRES AN API KEY: HackerTarget gates this endpoint, and the keyless tier answers "error valid key required" (verified 2026-09-16). For keyless WHOIS use ripe_stat_whois.

Input Schema

NameRequiredDescriptionDefault
targetYesDomain name or IP address, e.g. "pipeworx.io".
_apiKeyYesYour HackerTarget API key, from the member dashboard. HackerTarget requires an API key for whois, mtr and traceroute — its free tier refuses those three with "error valid key required". Pipeworx supplies no key for this pack. Membership and API docs: https://hackertarget.com/ip-tools/

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "target": "pipeworx.io"
+  }
+]
    • addedInput schema / properties / _apiKey
      Added value: +{
+  "description": "Your HackerTarget API key, from the member dashboard. HackerTarget requires an API key for whois, mtr and traceroute — its free tier refuses those three with \"error valid key required\". Pipeworx supplies no key for this pack. Membership and API docs: https://hackertarget.com/ip-tools/",
+  "type": "string"
+}
    • addedInput schema / properties / target / description
      Added value: +"Domain name or IP address, e.g. \"pipeworx.io\"."
    • changedInput schema / required
      Previous value: -[
-  "target"
-]New value: +[
+  "target",
+  "_apiKey"
+]
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds real behavioral context on auth gating and the keyless failure mode, plus a caveat that contact fields are only 'whatever the registry still publishes'. Credit is reduced slightly because the API-key requirement is largely duplicated in the _apiKey schema description rather than being purely additive.

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 leading slash-separated user phrasings efficiently map intent to the tool, followed by the resource definition and then the hard constraint. It runs slightly long, with the API-key requirement restated across description and schema, but every sentence still does work.

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?

With no output schema, the description compensates by naming the data an agent should expect back (registrar, dates, nameservers, contact fields) and by fully covering the auth prerequisite and its fallback path. Nothing needed to call this tool correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, with both target and _apiKey fully documented, so the description carries no additional burden. It restates that target is a domain or IP but adds no format, normalization, or validation detail beyond the schema—baseline 3 is correct.

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 verb+resource (WHOIS record for a domain or IP), enumerates the returned fields (registrar, creation/expiry, nameservers, contact fields), and anchors it to a named provider (HackerTarget). It also names the sibling alternative (ripe_stat_whois) for keyless lookups, so an agent can distinguish it without opening the schema.

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?

Explicit routing rule: use ripe_stat_whois when no key is available; this tool requires a HackerTarget API key. The condition that selects the alternative (keyless vs keyed) is unambiguous, and the description even supplies the exact failure string the keyless tier returns.

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

All Hackertarget 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