Skip to main content
Glama

PG1 Sovereign Threat Intelligence

by io.github.Project-Gifted1
OverviewDiscussionsAdmin

check_ip_abuse

PG1 Sovereign Threat Intelligence: looks up one public IPv4 or IPv6 address in AbuseIPDB using YOUR OWN AbuseIPDB API key (free or paid), and returns its abuse confidence score and report counts with attribution to AbuseIPDB. BRING YOUR OWN KEY: send the key in the X-AbuseIPDB-Key HTTP request header on /api/mcp or /api/a2a - never as a tool argument. PG1 has no AbuseIPDB key of its own; without the header the call returns an MCP tool error (isError: true, code abuseipdb_key_required) and AbuseIPDB is not contacted. No PG1 payment required - lookups count against your own AbuseIPDB quota. SIBLING DIFFERENTIATION: Use for a live AbuseIPDB report lookup on a single IP only. Do NOT use for PG1's own threat-feed lookups (use get_ioc_context), hostnames (use check_hostname_reputation) or domains (use check_domain_age). BEHAVIOR: Returns { ip, abuse_confidence_score, total_reports, distinct_reporters, last_reported_at, country_code, usage_type, isp, domain, is_tor, is_whitelisted, attribution }. STATUS: "no_flags" when AbuseIPDB marks the address whitelisted (informational reason IP_WHITELISTED: AbuseIPDB does not count its reports against it); otherwise "flagged" when abuse_confidence_score > 0 (reason IP_ABUSE_REPORTED, with the score, report and reporter counts); otherwise "no_flags" (with informational reason IP_REPORTS_SCORED_ZERO when reports exist but AbuseIPDB scores them 0); "unknown" when the score or report count is missing. IP_TOR_EXIT_NODE is informational. abuse_confidence_score is AbuseIPDB's 0-100 confidence that the address is abusive; a score of 0 is not proof the address is harmless - this tool never returns "safe" or "clean". Results are returned only to the caller whose key was used, are never stored or shared, and are cached in memory for 15 minutes per key. ERRORS (isError: true): abuseipdb_key_required, invalid_abuseipdb_key (AbuseIPDB rejected the key), abuseipdb_rate_limited (your AbuseIPDB quota; retry_after passed through when AbuseIPDB sends it), upstream_unavailable (AbuseIPDB error or timeout), invalid_ip (not exactly one public address: private, reserved or malformed input is rejected without calling AbuseIPDB), invalid_max_age. Rate-limited to 60 calls/hour per caller when unauthenticated; a valid Gumroad license key (X-API-KEY header) exempts the limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ipYesMandatory single public IPv4 or IPv6 address, e.g. '8.8.8.8' or '2001:4860:4860::8888'. No port, CIDR range, brackets or zone id.
max_age_in_daysNoOptional reporting window in days, 1 to 365. Only reports from this many days back are counted. Defaults to 90.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
ipYesThe address checked (IPv6 in canonical compressed lowercase form).
ispYes
noteNo
cachedYestrue when served from the 15-minute in-memory cache for your own key.
checksNoWhich underlying sources were checked for this result and whether each one completed.
domainYes
is_torYes
statusNo"unknown" whenever a source needed for this answer timed out, errored, or was skipped - never "no_flags" in that case.
reasonsNoMachine-readable reason codes for anything flagged in this result. Empty when nothing was flagged.
ip_versionYes
request_idNoUUID for this request, also sent as the X-Request-Id response header.
usage_typeYes
attributionYesAlways present: the data source and a link to its page for this address.
country_codeYes
test_fixtureNotrue only when the input was a documented integration test fixture and this response is canned; absent on real results.
total_reportsYesAbuse reports received in the window.
is_whitelistedYes
max_age_in_daysYesThe reporting window used.
last_reported_atYesISO timestamp of the most recent report, or null when there is none.
distinct_reportersYesDistinct users who reported the address in the window.
abuse_confidence_scoreYesAbuseIPDB's 0-100 confidence that the address is abusive. A score of 0 is not proof the address is harmless.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/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 behavioral burden and does so thoroughly: it discloses the BYOK requirement and header mechanism, error codes (abuseipdb_key_required, invalid_abuseipdb_key, etc.), caching (15 minutes per key), rate limits (60 calls/hour unauthenticated, exempt with license key), status semantics (no_flags, flagged, unknown), and data handling (results returned only to caller, never stored or shared). This is exceptional transparency.

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

Conciseness5/5

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

Despite its length, the description is organized with clear headings (SIBLING DIFFERENTIATION, BEHAVIOR, STATUS, ERRORS) and is front-loaded with the core purpose. Every sentence provides essential information for correctly invoking and interpreting the tool, with no filler.

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?

Given the tool's complexity (BYOK, numerous error codes, status logic, caching, rate limits) and the absence of annotations, the description is complete enough for an agent to call it correctly. The presence of an output schema means return fields need not be explained, but the description still adds useful interpretation of status values.

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%, meaning both parameters are fully documented in the schema. The description does not add any semantics for max_age_in_days and only restates the IP constraint already in the schema, so the baseline of 3 is appropriate.

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 verb and resource: 'looks up one public IPv4 or IPv6 address in AbuseIPDB' and returns its abuse confidence score and report counts. It explicitly distinguishes itself from siblings, naming get_ioc_context, check_hostname_reputation, and check_domain_age as alternatives for other lookup types.

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?

The description provides explicit when-to-use and when-not-to-use guidance with named alternatives: 'Use for a live AbuseIPDB report lookup on a single IP only. Do NOT use for PG1's own threat-feed lookups (use get_ioc_context), hostnames (use check_hostname_reputation) or domains (use check_domain_age).' This leaves no ambiguity about tool selection.

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