Threat intel for AI agents: IOCs, CVEs (EPSS/KEV), wallet sanctions and age, domain and URL checks.
Scored across 15 tools
Every tool targets a distinct resource+action, and the descriptions go further by embedding explicit SIBLING DIFFERENTIATION sections that tell the agent exactly when to use each tool and which sibling to prefer. Overlapping-looking pairs (get_ioc_context vs get_ioc_batch vs get_threat_indicators; get_cve_details vs get_cve_batch vs get_cve_by_product; check_domain_age vs check_hostname_reputation vs check_ip_abuse) have crisp boundaries. An agent can reliably select the right tool without guessing.
All 15 tools follow a strict snake_case verb_noun pattern with a small, predictable verb set: check_* for point screenings, get_* for lookups/feeds, submit_* and subscribe_* for write operations. No camelCase mixing, no vague verbs, no ad-hoc suffixes beyond clear batch/context distinctions.
15 tools is well-scoped for a threat-intelligence surface spanning domain, hostname, IP, wallet, CVE, IOC, and actor domains, plus account management. Each tool maps to a distinct lookup granularity or workflow (single, batch, bulk feed, discovery) and earns its place, with no filler.
Broad coverage: point lookups and batches for IOCs and CVEs, bulk STIX feed, actor dossiers, wallet age and sanctions, domain/hostname/IP screening, plus submission, alert subscription, and usage status. Minor gaps remain (e.g., no way to list or delete existing alert subscriptions, no strict CPE-based CVE matching), and hash handling is only implied via generic IOC tools.
PG1 Sovereign Threat Intelligence: looks up a domain's registration age via RDAP (the IANA-standardized WHOIS successor), resolved through the IANA bootstrap registry for the correct per-TLD RDAP server. No payment required — this tool is always free. SIBLING DIFFERENTIATION: Use for domain registration/age checks only. Do NOT use for reputation/threat-feed lookups (use get_ioc_context) or sanctions screening (use check_wallet_sanctions). BEHAVIOR: Returns { found: true, available: true, registration_date, age_days, expiration_date, registrar, newly_registered, source } when available, or { found: false, available: false, reason, reason_code } when the lookup does not resolve — this tool never estimates or guesses an age. "available" is a deprecated alias of "found", kept for backward compatibility. reason_code is "unsupported_tld" when the TLD has no RDAP server in the IANA bootstrap registry, or "timeout" / "lookup_failed" for other lookup failures. A newly registered domain (age_days < 30) is reported as a common phishing signal, not as proof of malicious intent.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Mandatory domain name or URL to check, e.g. 'example.com' or 'https://example.com/path'. The registrable domain is extracted automatically. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| found | Yes | Whether a registration record was found. Same meaning as the deprecated "available" field. |
| checks | No | Which underlying sources were checked for this result and whether each one completed. |
| domain | Yes | |
| reason | No | |
| source | No | |
| 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. |
| age_days | No | |
| available | Yes | Deprecated — use "found" instead. Kept for backward compatibility. |
| registrar | No | |
| request_id | No | UUID for this request, also sent as the X-Request-Id response header. |
| reason_code | No | |
| test_fixture | No | true only when the input was a documented integration test fixture and this response is canned; absent on real results. |
| expiration_date | No | |
| newly_registered | No | |
| registration_date | No |
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 documents both success and failure response shapes, enumerates reason_code values ('unsupported_tld', 'timeout', 'lookup_failed'), flags 'available' as a deprecated alias, and commits to never estimating an age. It also frames newly_registered as a signal, not proof of malice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the operation and uses clear SIBLING DIFFERENTIATION / BEHAVIOR labels to make scanning easy. Slightly padded by branding ('PG1 Sovereign Threat Intelligence') and the 'No payment required — always free' line, which is useful pricing context but costs space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description still explains both return branches and reason codes, and it covers failure modes an agent must handle. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is fully documented in the schema, including the URL form and automatic registrable-domain extraction. The description adds nothing beyond that on the parameter side, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (looks up a domain's registration age) plus the mechanism (RDAP via IANA bootstrap), and explicitly distinguishes itself from get_ioc_context and check_wallet_sanctions. An agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains an explicit 'Use for ... only' scope plus two named exclusions with the exact sibling to use instead ('Do NOT use for reputation/threat-feed lookups (use get_ioc_context) or sanctions screening (use check_wallet_sanctions)'). This is the when/when-not/alternative pattern at full strength.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | Mandatory 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_days | No | Optional reporting window in days, 1 to 365. Only reports from this many days back are counted. Defaults to 90. |
| Name | Required | Description |
|---|---|---|
| ip | Yes | The address checked (IPv6 in canonical compressed lowercase form). |
| isp | Yes | |
| note | No | |
| cached | Yes | true when served from the 15-minute in-memory cache for your own key. |
| checks | No | Which underlying sources were checked for this result and whether each one completed. |
| domain | Yes | |
| is_tor | Yes | |
| 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. |
| ip_version | Yes | |
| request_id | No | UUID for this request, also sent as the X-Request-Id response header. |
| usage_type | Yes | |
| attribution | Yes | Always present: the data source and a link to its page for this address. |
| country_code | Yes | |
| test_fixture | No | true only when the input was a documented integration test fixture and this response is canned; absent on real results. |
| total_reports | Yes | Abuse reports received in the window. |
| is_whitelisted | Yes | |
| max_age_in_days | Yes | The reporting window used. |
| last_reported_at | Yes | ISO timestamp of the most recent report, or null when there is none. |
| distinct_reporters | Yes | Distinct users who reported the address in the window. |
| abuse_confidence_score | Yes | AbuseIPDB's 0-100 confidence that the address is abusive. A score of 0 is not proof the address is harmless. |
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.
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.
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.
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.
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.
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.
PG1 Sovereign Threat Intelligence: a pre-install check for one npm or PyPI package - check before you install. No payment required - this tool is always free, and no AI model is involved. SIBLING DIFFERENTIATION: Use before installing or recommending a software package (npm or PyPI) only. Do NOT use for domains (use check_domain_age / check_hostname_reputation), CVE ids (use get_cve_details) or products by vendor name (use get_cve_by_product). BEHAVIOR: Returns { ecosystem, name, version_checked, exists, version_exists, first_published, age_days, latest_version, latest_published, reported_malicious, malicious_reports, vulnerabilities, lookalike_of, deprecated, install_scripts, attribution }. Signals: whether the package (and the version, if given) exists in the registry - a package that does not exist is a key signal, since names AI assistants invent get registered by attackers; first and latest publish dates; public malicious-package reports (OpenSSF Malicious Packages, via OSV.dev) for the version checked; known vulnerabilities for that version (OSV.dev: ids and severity only); whether the name looks like a popular package's (typosquat patterns); and, for npm only, the deprecated flag and install scripts (preinstall/install/postinstall). With no version, the latest version is checked. STATUS: "flagged" when the version is reported malicious (PACKAGE_REPORTED_MALICIOUS - worded "reported malicious" because such reports can be false positives), the package or version does not exist (PACKAGE_NOT_FOUND / PACKAGE_VERSION_NOT_FOUND), or the package is under 30 days old AND its name looks like a popular package's (PACKAGE_NEW_LOOKALIKE); otherwise "unknown" if any lookup did not complete (a failed registry lookup gives exists: null, never false); otherwise "no_flags". A look-alike name alone, a new package alone, known vulnerabilities, deprecation and install scripts are informational reasons that never flag on their own. This tool never returns "safe" or "clean"; no_flags means nothing was found in the sources checked. VALIDATION: one package per call; malformed input returns an MCP tool error (isError: true, code invalid_ecosystem, invalid_package_name or invalid_version). Registry answers are cached for 1 hour and malicious/vulnerability answers for 15 minutes. Rate-limited to 60 calls/hour per caller when unauthenticated; a valid Gumroad license key (X-API-KEY header) exempts the limit. Data sources and licences: https://pg1-ai-agent.vercel.app/docs/attributions
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Mandatory package name, exactly one, e.g. 'lodash', '@types/node' or 'requests'. | |
| version | No | Optional exact version to check, e.g. '4.17.21'. No ranges or tags. Defaults to the latest published version. | |
| ecosystem | Yes | Mandatory package ecosystem: 'npm' or 'pypi'. |
| Name | Required | Description |
|---|---|---|
| name | Yes | The name as given (trimmed). |
| note | No | |
| cached | Yes | |
| checks | No | Which underlying sources were checked for this result and whether each one completed. |
| exists | Yes | Whether the package exists in the registry; null when the registry lookup did not complete (never false on a failure). |
| 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. |
| age_days | Yes | Days since the first publish. |
| ecosystem | Yes | |
| deprecated | Yes | npm only: whether version_checked is deprecated. null for PyPI or when unknown. |
| request_id | No | UUID for this request, also sent as the X-Request-Id response header. |
| attribution | Yes | Always present: the data sources and a link to their licences. |
| lookalike_of | Yes | The popular package this name looks like, if any. |
| test_fixture | No | true only when the input was a documented integration test fixture and this response is canned; absent on real results. |
| canonical_name | No | The name as the registry spells it, when the package exists. |
| latest_version | Yes | |
| version_exists | Yes | Whether version_checked is published; null when unknown. |
| first_published | Yes | ISO timestamp of the first publish. |
| install_scripts | Yes | npm only: the install-time scripts version_checked runs. null for PyPI or when unknown. |
| version_checked | Yes | The version the malicious-report, vulnerability, deprecation and install-script signals describe: the requested version, or the latest one. |
| vulnerabilities | Yes | Known vulnerabilities for version_checked: id and severity only. null when not checked. |
| latest_published | Yes | ISO timestamp of the latest version's publish. |
| lookalike_pattern | No | |
| malicious_reports | Yes | Report ids (MAL-...). |
| version_requested | Yes | |
| reported_malicious | Yes | true when a public malicious-package report covers the version checked (or the package, when no version could be determined); null when that lookup did not complete. Reports can be false positives. |
| deprecation_message | No | npm only: the publisher's deprecation message (untrusted text, cut to 300 characters). |
| vulnerabilities_omitted | No | Advisories left out because they come from a source outside PG1's licence-checked list. |
PG1 Sovereign Threat Intelligence: reports when an EVM wallet address first appeared on a given chain, based on its earliest on-chain transfer history (in or out), plus whether the address is a contract. No payment required — this tool is always free. SIBLING DIFFERENTIATION: Use for wallet age/history only. Do NOT use for sanctions screening (use check_wallet_sanctions), domain age (use check_domain_age), or hostname/phishing reputation (use check_hostname_reputation). BEHAVIOR: Returns { address, chain, found, first_seen, age_days, first_seen_block, first_direction, is_contract, note, source: "on-chain transfer history", cached }. A found:false result (with all other fields null except is_contract) means the address has no transfer history on that chain — a normal, common result for a brand-new or never-used address, not an error, and not evidence of legitimacy either way; this tool reports age and history only. Upstream lookup failures or timeouts return an MCP tool error (isError: true) instead of found:false, since a data-source outage must never be read as "brand-new wallet". VALIDATION: address must be a 0x-prefixed 40-hex-character EVM address (case-insensitive); chain, if given, must be one of the supported enum values. Malformed input returns an MCP tool error (isError: true, code invalid_address or invalid_chain) instead of a result. 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. A found result is cached permanently (it never changes); a found:false result is cached for 10 minutes only, since a wallet can become active at any time.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Optional chain to check: 'base', 'ethereum', 'arbitrum', 'optimism', 'polygon', or 'bsc'. Defaults to 'base'. | base |
| address | Yes | Mandatory EVM wallet address to check, formatted '0x' followed by 40 hex characters (case-insensitive). |
| Name | Required | Description |
|---|---|---|
| note | No | |
| chain | Yes | |
| found | Yes | |
| cached | Yes | |
| checks | No | Which underlying sources were checked for this result and whether each one completed. |
| source | Yes | |
| status | No | "unknown" whenever a source needed for this answer timed out, errored, or was skipped - never "no_flags" in that case. |
| address | Yes | The address, lowercased. |
| reasons | No | Machine-readable reason codes for anything flagged in this result. Empty when nothing was flagged. |
| age_days | Yes | |
| delegated | No | true when the address currently has an EIP-7702 delegation on this chain (its code is exactly 0xef0100 followed by a 20-byte delegate address), false when it does not, null when the code check did not complete. Checked live on every call, never cached. is_contract is unchanged and is still true for a delegated address. |
| first_seen | Yes | ISO timestamp of the earliest observed transfer in or out, or null if none found. |
| request_id | No | UUID for this request, also sent as the X-Request-Id response header. |
| is_contract | Yes | |
| test_fixture | No | true only when the input was a documented integration test fixture and this response is canned; absent on real results. |
| first_direction | Yes | |
| delegate_address | No | The lowercased delegate contract address when delegated is true, otherwise null. |
| first_seen_block | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and delivers: exact return shape, the semantic meaning of found:false (normal, not an error, not evidence of legitimacy), errors vs found:false for upstream outages, validation rules, rate limits with license-key exemption, and caching TTLs per result type. This is comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and organized into labeled sections (SIBLING DIFFERENTIATION, BEHAVIOR, VALIDATION), which aids scanning. It is on the long side, but nearly every sentence adds distinct operational information; slight redundancy around 'always free' appears twice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still explains return-value semantics (especially found:false), error behavior, caching, and rate limits. For a tool with this complexity, nothing an agent needs to call it correctly and interpret results is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds meaningful behavioral context beyond the schema: validation failure returns isError with specific codes (invalid_address, invalid_chain), case-insensitivity, and per-result caching tied to found vs found:false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: reports when an EVM wallet first appeared on a chain, based on earliest transfer history, plus contract status. It explicitly differentiates from siblings (check_wallet_sanctions, check_domain_age, check_hostname_reputation), so an agent can distinguish it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives when-to-use ('wallet age/history only') and when-not-to-use (sanctions screening, domain age, hostname reputation) with alternative tool names. Also clarifies it is always free, removing a possible selection hesitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PG1 Sovereign Threat Intelligence: checks a cryptocurrency wallet address against the OFAC SDN (Specially Designated Nationals) sanctions list, synced daily from US Treasury data. No payment required — this tool is always free. SIBLING DIFFERENTIATION: Use for wallet/address sanctions screening only. Do NOT use for IP/domain/hash/URL threat lookups (use get_ioc_context) or CVE data (use get_cve_details). BEHAVIOR: Returns { listed: true|false, matches, source, list_last_synced }. A listed:false result means the address is not on the OFAC SDN list as of the reported sync time — it is informational only, not legal or sanctions-compliance advice, and is never phrased as "safe" or "clean". Fails loudly (returns an error) if the sanctions data is empty or unreachable, rather than ever reporting listed:false on a data failure. VALIDATION: if the address does not match a recognised format for any supported currency (EVM, BTC/LTC/BCH/DOGE/DASH/ZEC base58 or bech32/cashaddr, TRON, Monero, Solana), returns an MCP tool error (isError: true, code invalid_address) instead of a result — it never reports listed:false for malformed input.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Mandatory wallet address to screen, e.g. an EVM 0x address, a bech32 (bc1/tb1/ltc1...) address, or a base58 address. | |
| currency | No | Optional currency/chain filter to narrow the match, e.g. 'BTC', 'ETH', 'XMR'. |
| Name | Required | Description |
|---|---|---|
| checks | No | Which underlying sources were checked for this result and whether each one completed. |
| listed | Yes | |
| source | Yes | |
| status | No | "unknown" whenever a source needed for this answer timed out, errored, or was skipped - never "no_flags" in that case. |
| address | Yes | The address exactly as submitted. |
| matches | Yes | |
| message | No | |
| reasons | No | Machine-readable reason codes for anything flagged in this result. Empty when nothing was flagged. |
| disclaimer | No | |
| request_id | No | UUID for this request, also sent as the X-Request-Id response header. |
| test_fixture | No | true only when the input was a documented integration test fixture and this response is canned; absent on real results. |
| list_last_synced | Yes | |
| address_normalized | Yes | The address after normalization, used to match against sanctioned_wallets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries full burden and does so richly: discloses it is always free, the exact return shape, that listed:false is informational and never phrased 'safe'/'clean', that it fails loudly on empty/unreachable data rather than reporting listed:false, and that malformed input returns an isError with code invalid_address. This is unusually thorough behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose, then uses labeled sections (SIBLING DIFFERENTIATION, BEHAVIOR, VALIDATION) that earn their space. Despite its length, every sentence conveys distinct operational information; nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has an output schema, so return-value documentation is not strictly needed, yet the description still adds interpretation (listed:false semantics, failure mode, validation behavior). For a sanctions-screening tool where misreading a false result is high-stakes, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters; baseline would be 3. The description adds value by enumerating supported address formats (EVM, BTC/LTC/BCH/DOGE/DASH/ZEC base58/bech32/cashaddr, TRON, Monero, Solana), which clarifies what 'address' and 'currency' accept beyond the schema's brief examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'checks a cryptocurrency wallet address against the OFAC SDN sanctions list.' It also explicitly names the sibling tools it is NOT for (get_ioc_context for IP/domain/hash/URL, get_cve_details for CVE), letting an agent route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit 'Use for wallet/address sanctions screening only' clause plus named alternatives and the conditions that select them. This is textbook when/when-not guidance with alternatives spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PG1 Sovereign Threat Intelligence: looks up multiple CVE identifiers in a single call, each enriched with NVD description/CVSS, FIRST.org EPSS score, and CISA KEV status — same enrichment as get_cve_details, batched. Payment required: $0.01 via x402, sent in params._meta['x402/payment'] (the PAYMENT-SIGNATURE header is also accepted), or a valid Gumroad license key (X-API-KEY header). SIBLING DIFFERENTIATION: Use for looking up several known CVE ids at once (e.g. from an SBOM or scan report). Do NOT use for a single CVE (use get_cve_details, lower overhead) or for discovering CVEs by vendor/product (use get_cve_by_product). BEHAVIOR: Accepts up to 20 ids per call; malformed or not-found ids are reported per-entry rather than failing the whole batch.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_ids | Yes | Array of CVE identifiers, each formatted 'CVE-YYYY-NNNN'. Max 20 per call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so: it discloses the payment requirement ($0.01 via x402 in params._meta['x402/payment']), the alternate PAYMENT-SIGNATURE header and Gumroad license key paths, the 20-id per-call cap, and the critical partial-failure behavior that malformed or missing ids are reported per-entry rather than failing the batch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with identity and enrichment before payment and routing, and the labeled SIBLING DIFFERENTIATION / BEHAVIOR sections make it scannable. The payment sentence is dense but each clause (x402 token location, alternate header, license key) is operationally necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description supplies everything needed: enrichment contents (NVD description/CVSS, EPSS, CISA KEV), auth/payment mechanics, batch limits, and failure semantics. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single cve_ids parameter and the schema already documents the 'CVE-YYYY-NNNN' format and the max-20 limit. The description reinforces batch size and per-entry reporting but adds no format details beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (looks up) and resource (multiple CVE identifiers) with clear scope, and explicitly names the sibling get_cve_details as carrying the same enrichment in a batched form. An agent can distinguish it from all eleven siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit positive trigger (several known CVE ids at once, e.g. from an SBOM or scan report) plus two named exclusions routing to get_cve_details for a single CVE and get_cve_by_product for discovery by vendor/product. This is the full when/when-not/alternatives pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PG1 Sovereign Threat Intelligence: returns CVEs affecting a given vendor/product (optionally a specific version), enriched with CVSS, EPSS, and CISA KEV status, sorted by exploitation risk. Sourced from NVD keyword search. Payment required: $0.01 via x402, sent in params._meta["x402/payment"] (the PAYMENT-SIGNATURE header is also accepted), or a valid Gumroad license key (X-API-KEY header). SIBLING DIFFERENTIATION: Use for discovering CVEs by vendor/product when you do not already have an exact CVE id. Do NOT use for a known CVE id (use get_cve_details / get_cve_batch). USAGE EXCLUSIONS: Uses NVD keyword search, not strict CPE matching — results may include near-matches. BEHAVIOR: Returns up to 50 results per call.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor | Yes | Vendor name, e.g. 'apache'. | |
| product | Yes | Product name, e.g. 'log4j'. | |
| version | No | Optional specific version, e.g. '2.14.1'. | |
| only_kev | No | If true, only return CVEs on the CISA KEV list. |
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 payment mechanics ($0.01 x402 in params._meta, PAYMENT-SIGNATURE header, or Gumroad X-API-KEY), the NVD keyword-search accuracy caveat, and the 50-result cap. These are exactly the non-obvious traits an agent needs before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose, then labeled sections for differentiation, exclusions, and behavior. Every sentence is substantive, though the payment/auth detail is dense and slightly long relative to the rest.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explains the return contents (CVSS, EPSS, CISA KEV status, sorted by exploitation risk, max 50), the auth requirements, and the accuracy limits. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so vendor, product, version, and only_kev are already documented in the schema; baseline is 3. The description adds only that version filtering is optional and that results are enriched/sorted, without new semantics for any individual parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('returns CVEs affecting a given vendor/product') plus the enrichment and ordering. It explicitly differentiates from get_cve_details and get_cve_batch by CVE-id vs vendor/product discovery, so an agent can route 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit SIBLING DIFFERENTIATION and USAGE EXCLUSIONS sections: use when you lack an exact CVE id, do not use for a known CVE id, and be aware results are NVD keyword search near-matches rather than strict CPE matches. That is textbook when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PG1 Sovereign Threat Intelligence: enriched CVE lookup combining NVD (description, CVSS score/vector), FIRST.org EPSS (exploit-probability score and percentile), and the CISA Known Exploited Vulnerabilities catalog (active wild exploitation status). Payment required: $0.01 via x402, sent in params._meta["x402/payment"] (the PAYMENT-SIGNATURE header is also accepted), or a valid Gumroad license key (X-API-KEY header). SIBLING DIFFERENTIATION: Use ONLY for specific CVE lookups. Do NOT use for IP/domain/hash enrichment (use get_ioc_context) or bulk feed ingestion (use get_threat_indicators). USAGE EXCLUSIONS: Does not support wildcard search or threat-actor dossier profiling. BEHAVIOR: If payment is missing or fails, returns a normal tool result with isError: true, the x402 v2 PaymentRequired object in structuredContent and the same JSON in content[0].text; on success the settlement receipt is in result._meta["x402/payment-response"]. Returns 404 if CVE is not found.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | Mandatory official CVE identifier string strictly formatted as 'CVE-YYYY-NNNN' (e.g., 'CVE-2021-44228'). |
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: payment amount/mechanism, that failures still return a normal tool result with isError:true and a PaymentRequired object, where the settlement receipt appears, and the 404-on-missing-CVE case. This is exactly the operational detail an agent needs before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite covering payment, routing, exclusions and error behavior, it is front-loaded and segmented with explicit labels (SIBLING DIFFERENTIATION, USAGE EXCLUSIONS, BEHAVIOR). Every sentence carries operational value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, multi-source enrichment tool with no output schema, the description covers invocation, routing, payment/auth, and both success and failure outcomes. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single cve_id parameter is already fully documented in the schema, including the strict CVE-YYYY-NNNN format. The description adds no format or constraint detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('enriched CVE lookup') and enumerates the exact data sources combined (NVD, EPSS, CISA KEV). It explicitly names the siblings it must not be confused with (get_ioc_context, get_threat_indicators), so an agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when ('specific CVE lookups') plus named alternatives for other cases (get_ioc_context for IP/domain/hash, get_threat_indicators for bulk feeds) and exclusions (no wildcard search, no threat-actor profiling). This is a complete routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PG1 Sovereign Threat Intelligence: looks up multiple indicators (IPs, domains, URLs, hashes) in a single call — a batched pre-action safety check for AI agents. Each returns the same aggregated provenance as get_ioc_context from OTX. SIBLING DIFFERENTIATION: Use for checking several indicators at once (e.g. all URLs an agent is about to visit). Do NOT use for a single indicator (use get_ioc_context, lower overhead) or bulk feed synchronization (use get_threat_indicators). BEHAVIOR: Accepts up to 20 indicators per call. A found:false result for any indicator means nothing bad is recorded in PG1's sources — NOT that it's safe. If NONE of the submitted indicators are found, the whole batch is FREE — no payment or free-tier quota consumed. If at least one indicator is found, the normal payment gate (x402 via params._meta['x402/payment'], with the PAYMENT-SIGNATURE header also accepted, or a Gumroad X-API-KEY license) applies to the full batch result.
| Name | Required | Description | Default |
|---|---|---|---|
| values | Yes | Array of indicator values (IPv4 addresses, domains, URLs, or hashes) to look up. Max 20 per call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so: 20-indicator cap, the critical caveat that found:false means 'not recorded', not 'safe', the conditional free-batch behavior, and the full payment path (x402 via params._meta and PAYMENT-SIGNATURE header, or Gumroad X-API-KEY). This is material behavior an agent cannot infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose before routing and behavior; the labeled sections (SIBLING DIFFERENTIATION, BEHAVIOR) aid scanning. Somewhat dense with ALL-CAPS labels and payment detail that could be marginally tighter, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description covers return parity with get_ioc_context (same aggregated provenance), the batch semantics of found:false, capacity limits, and the payment/quota model. An agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single required 'values' parameter is already documented in the schema including the max-20 limit. The description's mention of 'up to 20 indicators per call' largely restates the schema rather than adding format or per-element semantics (e.g. mixed-type batches, normalization rules).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (looks up) and resource (multiple indicators) with the exact accepted types (IPs, domains, URLs, hashes) and framing (batched pre-action safety check). It explicitly separates itself from get_ioc_context (single indicator) and get_threat_indicators (bulk feed sync).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('checking several indicators at once, e.g. all URLs an agent is about to visit'), when-not-to-use ('Do NOT use for a single indicator', 'or bulk feed synchronization'), and names the replacement sibling for each case. 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.
PG1 Sovereign Threat Intelligence: looks up a single specific indicator value (IP, domain, URL, or hash) — the recommended pre-action safety check for AI agents before visiting, downloading, or connecting to something. Returns aggregated provenance from OTX — reporting sources, observation count, aggregated confidence score, known malware families, tags, and first/last seen timestamps. SIBLING DIFFERENTIATION: Use ONLY for point-lookup enrichment of a single indicator. Do NOT use for bulk intelligence downloads (use get_threat_indicators), multiple indicators at once (use get_ioc_batch), or software vulnerability analysis (use get_cve_details). BEHAVIOR: Returns a normal result shaped { found: true, indicator_type, provenance } or { found: false } — never an error for 'not found'. A found:false result means nothing bad is recorded in PG1's sources; it does NOT mean the indicator is safe, only that it isn't in this dataset. Lookups that return found:false are FREE — no payment or free-tier quota is consumed. Payment (x402 via params._meta['x402/payment'], with the PAYMENT-SIGNATURE header also accepted, or a Gumroad X-API-KEY license) is only required when a real record is found. If payment is required but missing or fails, the result has isError: true with the x402 v2 PaymentRequired object in structuredContent.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Mandatory exact indicator string value to look up, such as an IPv4 address (198.51.100.1), fully qualified domain, complete URL, or SHA-256 hash string. |
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 shapes ({found:true,...} vs {found:false}), that not-found never errors, that found:false does NOT mean safe, that such lookups are free, and the payment paths (x402 params._meta, PAYMENT-SIGNATURE header, Gumroad X-API-KEY) plus the error shape (isError + PaymentRequired object). This is unusually rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then clearly sectioned into SIBLING DIFFERENTIATION and BEHAVIOR. It is long, but the payment and found:false semantics justify the length; only minor trimming (e.g., payment path enumeration) could tighten it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-param tool with no annotations and no output schema, the description supplies everything an agent needs: return shape, error/free-vs-paid behavior, and routing to siblings. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is only one parameter, so the schema already documents 'value' thoroughly. The description reinforces that it must be a single indicator (not a list) but adds no syntax or format detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'looks up a single specific indicator value (IP, domain, URL, or hash)' and positions it as the pre-action safety check. It explicitly names the siblings it is NOT for (get_threat_indicators, get_ioc_batch, get_cve_details), so an agent can distinguish 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('recommended pre-action safety check before visiting, downloading, or connecting') and when-not-to-use with named alternatives for each exclusion (bulk, multi-indicator, vulnerability). 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.
PG1 Sovereign Threat Intelligence: returns a dossier for a known threat actor / APT group — aliases, description, associated MITRE ATT&CK techniques, and associated malware/tooling. Sourced from MITRE ATT&CK Enterprise. Payment required: $0.01 via x402, sent in params._meta['x402/payment'] (the PAYMENT-SIGNATURE header is also accepted), or a valid Gumroad license key (X-API-KEY header). SIBLING DIFFERENTIATION: Use for actor/group-level profiling. Do NOT use for single-indicator lookups (use get_ioc_context) or vulnerability data (use get_cve_details / get_cve_batch). USAGE EXCLUSIONS: Coverage is limited to groups tracked in MITRE ATT&CK — not all threat actors have an entry. BEHAVIOR: Returns 404 if no matching group or alias is found.
| Name | Required | Description | Default |
|---|---|---|---|
| actor_name | Yes | Group name or known alias, e.g. 'APT29' or 'Cozy Bear'. Matching is case-insensitive against both the group's primary name and its known aliases. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden and does so well: it discloses paid access ($0.01 via x402 in params._meta['x402/payment'] or PAYMENT-SIGNATURE header), Gumroad license key auth (X-API-KEY), data source (MITRE ATT&CK Enterprise), and 404 error behavior for unknown groups/aliases. This is unusually complete for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and return contents, followed by payment, sibling differentiation, exclusions, and error behavior. It is information-dense and structured with caps labels, though the branding prefix and some payment detail make it longer than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description still covers return fields, data source, payment/auth requirements, coverage limits, and error behavior. An agent has enough to decide when to call it and how to authenticate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the actor_name parameter already documents case-insensitive matching against primary names and aliases with examples. The description adds no syntax, format, or matching detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('returns a dossier') and resource ('known threat actor / APT group'), enumerates returned fields (aliases, description, MITRE ATT&CK techniques, malware/tooling), and explicitly distinguishes from get_ioc_context, get_cve_details, and get_cve_batch. An agent can route correctly without opening any other schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it for actor/group-level profiling and names three alternatives for adjacent tasks: get_ioc_context for single-indicator lookups, get_cve_details / get_cve_batch for vulnerability data. It also states a coverage exclusion (only groups tracked in MITRE ATT&CK), making the when-not condition concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PG1 Sovereign Threat Intelligence: returns a STIX 2.1 bundle of verified threat indicators (IPs, domains, URLs, file hashes) sourced from OTX and NVD. Payment required: $0.01 via x402, sent in params._meta["x402/payment"] (the PAYMENT-SIGNATURE header is also accepted), or a valid Gumroad license key (X-API-KEY header). SIBLING DIFFERENTIATION: Use ONLY for bulk feed synchronizations. Do NOT use for single-item lookups (use get_ioc_context) or CVE analysis (use get_cve_details). USAGE EXCLUSIONS: Does not provide historical query archival beyond the active ingestion window. BEHAVIOR: Pagination is handled via the limit parameter (max 1000). If payment is missing or fails, returns a normal tool result with isError: true, the x402 v2 PaymentRequired object in structuredContent and the same JSON in content[0].text; on success the settlement receipt is in result._meta["x402/payment-response"].
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Indicator category filter. Allowed enum-style values: 'IPv4', 'domain', 'URL', 'FileHash-MD5', 'FileHash-SHA1', or 'FileHash-SHA256'. | |
| limit | No | Pagination boundary constraint defining the maximum number of indicators to return in a single payload (integer between 1 and 1000, defaulting to 500). | |
| since | No | ISO timestamp constraint (e.g., 2026-09-20T00:00:00Z); strictly filters and returns only indicators last seen after this exact timestamp. | |
| min_score | No | Confidence score threshold integer ranging inclusively from 0 to 100 to filter low-confidence noise. |
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 well: it discloses the paid access model ($0.01 via x402, PAYMENT-SIGNATURE header, or Gumroad X-API-KEY), the exact failure behavior (isError: true with a PaymentRequired object in structuredContent and content[0].text), and where the settlement receipt lands on success. It also documents pagination limits and the archival exclusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then payment, then sibling routing, then behavior, so an agent can stop reading once it has what it needs. It is dense and all-caps section labels are slightly heavy, but nearly every clause conveys actionable information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter read tool with no output schema, the description supplies the missing return-shape information (STIX 2.1 bundle contents, error payload structure, receipt location) plus auth requirements. Nothing an agent needs to call it correctly or handle its failures is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the enum values, limit bounds, ISO timestamp format, and min_score range are already fully documented in the schema; the baseline is 3. The description adds only marginal value by reiterating that pagination is handled via limit (max 1000) and by mentioning the _meta payment key, which is not itself a schema parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('returns a STIX 2.1 bundle of verified threat indicators (IPs, domains, URLs, file hashes)') and names its data sources (OTX, NVD). It explicitly distinguishes itself from siblings get_ioc_context and get_cve_details, so an agent can route correctly without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('Use ONLY for bulk feed synchronizations') and when-not-to-use with named alternatives ('Do NOT use for single-item lookups (use get_ioc_context) or CVE analysis (use get_cve_details)'). It also states a usage exclusion (no historical archival beyond the active ingestion window), leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PG1 Sovereign Threat Intelligence: returns your remaining free-tier calls for today and current Gumroad license status. No payment required — this tool is always free.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | No | Optional — the X-API-KEY or identifier to check usage for; defaults to the calling identifier if omitted. | |
| license_key | No | Optional — check Gumroad license status alongside free-tier usage. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds key safety/operational context: 'No payment required — this tool is always free,' signaling a low-risk, read-only operation. It could further disclose whether the call consumes quota or returns error details, but the provided transparency is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The phrase 'No payment required — this tool is always free' is slightly redundant, but the overall size and structure are efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-required-parameter status tool, the description is largely complete. It states what is returned and the free nature of the tool. Without an output schema, it could clarify the response format, but the agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description aligns with the schema by mentioning 'remaining free-tier calls' and 'license status,' which maps to identifier and license_key, but it adds no meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'returns your remaining free-tier calls for today and current Gumroad license status,' using a specific verb and resource. It also sets it apart from the sibling threat-intelligence tools by focusing on usage and license state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context obvious: it is for checking usage and license status, not for retrieving threat data like the sibling tools. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for an agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PG1 Sovereign Threat Intelligence: submit an observed indicator for validation and possible inclusion in future query results. Requires a valid Gumroad license key (X-API-KEY header) — this tool is NOT available via per-query x402. Submissions are staged for review, not immediately added to the live feed.
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | Yes | ||
| confidence | No | Submitter's own confidence, 0-100. | |
| source_note | No | Optional free-text on how this was observed. | |
| indicator_type | Yes | ||
| malware_family | No | Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and delivers: submissions are 'staged for review, not immediately added to the live feed', and inclusion is only 'possible', not guaranteed. It also discloses the auth prerequisite and the x402 exclusion. It stops short of describing response format or rejection outcomes, but the most decision-relevant behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose in sentence one, auth/access constraint in sentence two, staging behavior in sentence three. The most critical facts are front-loaded before constraints, with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description wisely explains post-submission behavior (staged, not live) and the auth path, which are the essentials for calling a submission tool correctly. The one notable gap is the absence of valid indicator_type values, a schema deficiency the description could have patched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% — confidence, source_note, and malware_family are documented in the schema, but the two required parameters (indicator, indicator_type) lack descriptions. The description's phrase 'observed indicator' adds only situational context and gives no format guidance for indicator_type values. It neither meaningfully compensates for the gap nor makes it worse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('submit'), a resource ('an observed indicator'), and a clear outcome ('validation and possible inclusion in future query results'). The domain framing ('PG1 Sovereign Threat Intelligence') plus the submit-vs-get contrast against all nine sibling tools makes the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear use case — submitting an observed indicator for validation — and explicit operating constraints (Gumroad license key required, NOT available via per-query x402). It never names an alternative or says when not to use it; the contrast with the read-only get_* siblings is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PG1 Sovereign Threat Intelligence: registers a standing filter (indicator type, min EPSS, or KEV-only). Matching new indicators are POSTed to the given webhook URL as they're ingested. Requires a valid Gumroad license key (X-API-KEY header) — this tool is NOT available via per-query x402, since it establishes a recurring subscription rather than a single paid call.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional filter object: { indicator_type, min_epss, kev_only } | |
| webhook_url | Yes | HTTPS URL to receive POSTed alert payloads. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the auth requirement (X-API-KEY header), the recurring subscription nature, and the delivery behavior (POSTed to the given webhook as new indicators are ingested). It does not cover unsubscription or response details, but the core behavioral contract is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: it front-loads the tool's purpose, then covers filter semantics, delivery behavior, and auth constraints in two sentences. Every clause earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a nested optional filter, the description provides enough context to invoke it correctly: what the filter selects, where payloads go, and what auth is needed. It lacks only optional details like response format or how to cancel the subscription, but nothing critical blocks correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: it explains that filter can be composed of indicator type, min EPSS, or KEV-only, and that webhook_url is the delivery target. This reinforces the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: registers a standing filter that POSTs matching indicators to a webhook. It also distinguishes itself from the sibling get_* tools by establishing a recurring subscription rather than performing a one-time retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool is appropriate: when an ongoing subscription of matching indicators is needed. It explicitly notes that this tool is NOT available via per-query x402 and requires a Gumroad license key, providing a useful exclusion, though it does not name specific alternative tools for one-off queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_packagecheck_ip_abusecheck_wallet_age2 fields changedOutput schema / properties / delegate_addressAdded value: +{
+ "description": "The lowercased delegate contract address when delegated is true, otherwise null.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / delegatedAdded value: +{
+ "description": "true when the address currently has an EIP-7702 delegation on this chain (its code is exactly 0xef0100 followed by a 20-byte delegate address), false when it does not, null when the code check did not complete. Checked live on every call, never cached. is_contract is unchanged and is still true for a delegated address.",
+ "type": [
+ "boolean",
+ "null"
+ ]
+}check_domain_age5 fields changedOutput schema / properties / checksAdded 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"
+}Output schema / properties / reasonsAdded 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"
+}Output schema / properties / request_idAdded value: +{
+ "description": "UUID for this request, also sent as the X-Request-Id response header.",
+ "type": "string"
+}Output schema / properties / statusAdded 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"
+}Output schema / properties / test_fixtureAdded value: +{
+ "description": "true only when the input was a documented integration test fixture and this response is canned; absent on real results.",
+ "type": "boolean"
+}check_hostname_reputation5 fields changedOutput schema / properties / checksAdded 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"
+}Output schema / properties / reasonsAdded 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"
+}Output schema / properties / request_idAdded value: +{
+ "description": "UUID for this request, also sent as the X-Request-Id response header.",
+ "type": "string"
+}Output schema / properties / statusAdded 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"
+}Output schema / properties / test_fixtureAdded value: +{
+ "description": "true only when the input was a documented integration test fixture and this response is canned; absent on real results.",
+ "type": "boolean"
+}check_wallet_age5 fields changedOutput schema / properties / checksAdded 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"
+}Output schema / properties / reasonsAdded 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"
+}Output schema / properties / request_idAdded value: +{
+ "description": "UUID for this request, also sent as the X-Request-Id response header.",
+ "type": "string"
+}Output schema / properties / statusAdded 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"
+}Output schema / properties / test_fixtureAdded value: +{
+ "description": "true only when the input was a documented integration test fixture and this response is canned; absent on real results.",
+ "type": "boolean"
+}check_wallet_sanctions5 fields changedOutput schema / properties / checksAdded 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"
+}Output schema / properties / reasonsAdded 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"
+}Output schema / properties / request_idAdded value: +{
+ "description": "UUID for this request, also sent as the X-Request-Id response header.",
+ "type": "string"
+}Output schema / properties / statusAdded 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"
+}Output schema / properties / test_fixtureAdded value: +{
+ "description": "true only when the input was a documented integration test fixture and this response is canned; absent on real results.",
+ "type": "boolean"
+}check_wallet_agecheck_hostname_reputationcheck_domain_age1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "age_days": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "available": {
+ "description": "Deprecated — use \"found\" instead. Kept for backward compatibility.",
+ "type": "boolean"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "expiration_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "found": {
+ "description": "Whether a registration record was found. Same meaning as the deprecated \"available\" field.",
+ "type": "boolean"
+ },
+ "newly_registered": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "note": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "reason_code": {
+ "enum": [
+ "invalid_domain",
+ "bootstrap_unavailable",
+ "unsupported_tld",
+ "timeout",
+ "lookup_failed",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "registrar": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "registration_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "found",
+ "available",
+ "domain"
+ ],
+ "type": "object"
+}check_wallet_sanctions1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "address": {
+ "description": "The address exactly as submitted.",
+ "type": "string"
+ },
+ "address_normalized": {
+ "description": "The address after normalization, used to match against sanctioned_wallets.",
+ "type": "string"
+ },
+ "disclaimer": {
+ "type": "string"
+ },
+ "list_last_synced": {
+ "type": "string"
+ },
+ "listed": {
+ "type": "boolean"
+ },
+ "matches": {
+ "items": {
+ "properties": {
+ "currency": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "programs": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sdn_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sdn_uid": {
+ "type": [
+ "string",
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "message": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "address",
+ "address_normalized",
+ "listed",
+ "matches",
+ "source",
+ "list_last_synced"
+ ],
+ "type": "object"
+}check_domain_agecheck_wallet_sanctionsget_threat_indicators1 field changedInput schema / properties / type / descriptionPrevious value: -"Indicator category filter. Allowed enum-style values: 'IPv4', 'domain', 'URL', or 'hash'."New value: +"Indicator category filter. Allowed enum-style values: 'IPv4', 'domain', 'URL', 'FileHash-MD5', 'FileHash-SHA1', or 'FileHash-SHA256'."get_cve_by_productget_usage_statussubmit_indicatorsubscribe_alertsget_ioc_batchReal-time threat intel for AI agents: 890K+ IOCs incl. prompt-injection & AI-skill threats
Live threat intel for agents: incidents, actors, CVEs with KEV/EPSS, ransomware leak-site victims.
Pay-per-call cybersecurity for AI agents: vuln scans, threat intel, compliance, code security.
One-call briefings for AI agents: dependency risk (KEV/EPSS), SEC companies, domains, US places.
Add one secure layer between your agents and this server.
