PG1 Sovereign Threat Intelligence

check_hostname_reputation

PG1 Sovereign Threat Intelligence: checks a single hostname against the MetaMask eth-phishing-detect blocklist/allowlist and a lookalike/typosquat detector, synced daily by the sovereign-threat-pipeline. No payment required — this tool is always free. SIBLING DIFFERENTIATION: Use for phishing/lookalike-domain screening of a hostname only. Do NOT use for domain registration age (use check_domain_age), general threat-feed indicator lookups (use get_ioc_context), or wallet sanctions screening (use check_wallet_sanctions). BEHAVIOR: Returns { hostname, verdict, sources, lookalike_of, list_synced_at, checked_at, attribution }. verdict is one of "allowlisted", "listed", "lookalike", or "not_listed" — this tool never returns "safe" or "clean", and a not_listed result means the hostname is not on the eth-phishing-detect lists, not that it is safe. "listed" results include match_type "exact" or "parent_domain" in sources. "lookalike" flags a probable typosquat/homoglyph of a known brand — via confusable-character skeleton matching within the stored tolerance, or a brand keyword embedded with extra words (e.g. metamask-login.com) — even when the hostname itself is not directly listed, and sets lookalike_of to the matched brand domain. A brand's own real domain or a subdomain of it is never flagged as its own lookalike. VALIDATION: accepts exactly one bare hostname per call (no bulk input); a value containing a URL scheme, path, port, spaces, or a wildcard returns an MCP tool error (isError: true, code invalid_hostname) instead of a verdict. Fails loudly (returns an error) if the phishing list data is unreachable or times out, rather than ever reporting not_listed on a data failure. Rate-limited to 60 calls/hour per caller when unauthenticated; a valid Gumroad license key (X-API-KEY header) exempts the limit, same as check_domain_age. List contents are never exposed beyond the single matched entry.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`hostname`	Yes	Mandatory bare hostname to screen, e.g. 'example.com'. Not a URL — no scheme, path, port, spaces, or wildcards. One hostname per call.

Output Schema

TableJSON Schema

Name	Required	Description
`checks`	No	Which underlying sources were checked for this result and whether each one completed.
`status`	No	"unknown" whenever a source needed for this answer timed out, errored, or was skipped - never "no_flags" in that case.
`reasons`	No	Machine-readable reason codes for anything flagged in this result. Empty when nothing was flagged.
`sources`	Yes
`verdict`	Yes	Never "safe" or "clean".
`hostname`	Yes	The hostname after normalization (trimmed, lowercased, trailing dot stripped, IDN converted to punycode).
`checked_at`	Yes
`request_id`	No	UUID for this request, also sent as the X-Request-Id response header.
`attribution`	Yes
`lookalike_of`	Yes	The matched brand/fuzzylist domain for a "lookalike" verdict, otherwise null.
`test_fixture`	No	true only when the input was a documented integration test fixture and this response is canned; absent on real results.
`list_synced_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 1, 2026

addedOutput schema / properties / checks

Added value: +{
+  "description": "Which underlying sources were checked for this result and whether each one completed.",
+  "items": {
+    "properties": {
+      "checked_at": {
+        "type": "string"
+      },
+      "data_as_of": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "result": {
+        "enum": [
+          "ok",
+          "timeout",
+          "error",
+          "skipped"
+        ],
+        "type": "string"
+      },
+      "source": {
+        "description": "Generic label for the data source checked, never a vendor name.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "source",
+      "result",
+      "checked_at",
+      "data_as_of"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / reasons

Added value: +{
+  "description": "Machine-readable reason codes for anything flagged in this result. Empty when nothing was flagged.",
+  "items": {
+    "properties": {
+      "code": {
+        "type": "string"
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "code",
+      "message"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / request_id

Added value: +{
+  "description": "UUID for this request, also sent as the X-Request-Id response header.",
+  "type": "string"
+}

addedOutput schema / properties / status

Added value: +{
+  "description": "\"unknown\" whenever a source needed for this answer timed out, errored, or was skipped - never \"no_flags\" in that case.",
+  "enum": [
+    "flagged",
+    "no_flags",
+    "unknown"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / test_fixture

Added value: +{
+  "description": "true only when the input was a documented integration test fixture and this response is canned; absent on real results.",
+  "type": "boolean"
+}

AddedSep 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the exact return shape, the verdict enum, the crucial semantic that not_listed is not 'safe', parent_domain/exact match types, lookalike matching mechanics, failure behavior (errors instead of false not_listed), 60 calls/hour rate limit with license-key exemption, and that list contents are never exposed.

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?

Long but front-loaded and sectioned (sibling differentiation, behavior, validation), so each block is scannable. Slightly dense in places but nearly every sentence carries actionable information.

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?

Despite an output schema existing, the description adds the verdict semantics and failure modes an agent needs to interpret results, and covers validation, rate limits, and scope. Nothing required to call or interpret this tool correctly is missing.

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 100% and the single parameter is documented, so the baseline is 3. The description goes further by stating the accepted/rejected forms (no scheme, path, port, spaces, wildcard) and that violations produce an isError invalid_hostname rather than a verdict, adding error semantics the schema does not.

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 ('checks a single hostname against the MetaMask eth-phishing-detect blocklist/allowlist and a lookalike/typosquat detector') and explicitly names the three siblings it is not (check_domain_age, get_ioc_context, check_wallet_sanctions). An agent can route to it without opening any 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 when-to-use ('phishing/lookalike-domain screening of a hostname only') plus a when-not list naming each alternative and its conditio. Nothing is left to inference.

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

All PG1 Sovereign Threat Intelligence tools Inspect

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.