Preflight for AI agents, signed: one call; wallet, domain, IP abuse, package checks and CVEs.
Scored across 21 tools
Almost every tool carries an explicit SIBLING DIFFERENTIATION paragraph naming the alternative to use instead (e.g. check_domain_age vs get_ioc_context vs check_wallet_sanctions), which makes selection unusually clear. The remaining overlap is deliberate layering: preflight_check re-runs the individual checks, and check_agent_card duplicates the trust_agent branch of preflight, so an agent must decide between the orchestrator and the primitives rather than between genuinely different capabilities.
Names are uniformly snake_case and follow a verb_noun shape with predictable prefixes (check_* for per-target screening, get_* for lookups, submit_/verify_ for lifecycle actions). The one outlier is hosting_advisor, a bare noun phrase that deviates from the verb_noun pattern and also references a different product name than the rest of the server.
21 tools is on the heavy side, and not all of them earn their place: get_ioc_context, get_ioc_batch and get_threat_indicators form a triplet whose underlying dataset currently holds only CVEs, so IP/domain/URL/hash lookups are near-dead ends. hosting_advisor sits outside the stated threat-intelligence scope, while preflight_check already subsumes much of the per-target check surface.
The lifecycle is broadly covered across domains: screening for domains, hostnames, IPs, wallets, packages, CVEs, agent cards, messages and x402 endpoints, plus orchestration, signed-result verification and usage status. Gaps are moderate — no batch wallet/hostname screening, no listing or search of threat actors (profile lookup only by name), no way to review or manage previously submitted indicators, and the IOC lookup path returns no findings for non-CVE indicator types.
PG1 Sovereign Threat Intelligence: checks another agent before you trust it. Fetches its /.well-known/agent-card.json (https only; private addresses and redirects refused): is it a valid A2A agent card, does its name claim a well-known brand the domain does not belong to, how old is the domain, is the hostname on the phishing blocklist or a look-alike. Always free (60/hour per caller). Give url or domain. Returns status flagged / no_flags / unknown; no_flags means no flags found, never "safe".
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The agent's https URL or its agent card URL. | |
| domain | No | Or just the agent's domain. |
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: https-only enforcement, refusal of private addresses and redirects, a 60/hour per-caller rate limit, always free, and the exact return vocabulary (flagged / no_flags / unknown) plus the critical caveat that no_flags never means 'safe'. These are exactly the operational constraints an agent cannot get 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?
A single dense paragraph, front-loaded with the tool's identity and trust purpose, then the mechanics and the return vocabulary. The parentheticals (https only, rate limit) each carry payload rather than filler; nothing is redundant.
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 and no annotations, yet the description supplies the return enum, the meaning of each value, the safety caveat on no_flags, the transport restrictions, and the rate limit. There is no obvious gap an agent would need to guess at before calling it.
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 both url and domain are already fully documented, making 3 the correct baseline. The description's 'Give url or domain' mildly reinforces that either form is accepted but adds no format or precedence detail beyond the schema.
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 another agent', fetches its /.well-known/agent-card.json) and frames the scope as a trust decision, which cleanly separates it from siblings like check_domain_age, check_hostname_reputation, and check_ip_abuse that a single endpoint might otherwise overlap with.
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?
'Checks another agent before you trust it' gives a clear when-to-use context, and 'Give url or domain' tells the caller what input is expected. It does not, however, explicitly name which sibling to use for narrower questions (domain age alone, hostname reputation alone) or state exclusions.
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-read check for a message from another agent or a seller's skill.md. Call it BEFORE your own model reads the content, to catch prompt injection and wallet or payment manipulation. Give exactly one of text (up to 64 KB) or url (https only; fetched once with the same private-address and no-redirect rules as check_x402_endpoint, 6 s timeout, text/markdown or text/plain only, up to 64 KB), and optionally kind (skill_md, message or other). PG1's own deterministic rules, no AI model: instruction override and role hijack (ignore previous instructions, "you are now", developer or jailbreak modes, claims to come from a system, an admin, an AI company or the wallet's developer); hidden content (zero-width and bidirectional control characters, Unicode tag characters, instructions in HTML comments, mixed-script look-alike words, long base64 or hex blobs, data: URIs; base64, hex and tag-character text is decoded and checked too); exfiltration (requests to reveal or send environment variables, keys, seed phrases, .env or ~/.ssh; image or link URLs carrying templated or secret-like values; curl | sh); wallet and payment manipulation (sign, approve, transfer or bridge instructions, unlimited allowances, a changed payTo or recipient, raised spending limits, presign-guard or other checks turned off); tool hijack (use your own tools or shell, install packages). Then, within 4 s, up to 5 domains and 5 wallet addresses named in the content go through check_domain_age, check_hostname_reputation, check_wallet_sanctions and check_wallet_age; if that does not finish, the rule results come back anyway (AGENT_MESSAGE_ENRICHMENT_INCOMPLETE). Returns verdict malicious (any high-severity finding: hidden tag characters, a secret-exfiltration instruction, a payment redirect, a sanctioned address), suspicious (medium findings only) or no_findings ("checked: no findings"), each finding with its reason code, severity, line and a masked excerpt (120 characters at most; keys, tokens and seed phrases masked), plus the URLs, domains and wallet addresses found and the sha256 and byte length of what was checked. No findings does not prove the content is harmless. The content is never stored; only its sha256, length, kind, verdict and reason codes are logged. Always free (60/hour per caller).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | An https URL serving the content as text/markdown or text/plain (up to 65536 bytes). Give this or text, not both. | |
| kind | No | What the content is: skill_md, message or other. Recorded and echoed; the rules are the same for every kind. | other |
| text | No | The message or skill.md content, up to 65536 bytes of UTF-8. Give this or url, not both. |
| Name | Required | Description |
|---|---|---|
| url | No | |
| kind | Yes | |
| note | No | |
| urls | Yes | |
| bytes | Yes | |
| checks | No | Which underlying sources were checked for this result and whether each one completed. |
| sha256 | Yes | Lowercase hex SHA-256 of the UTF-8 content checked. |
| source | Yes | |
| status | No | "unknown" whenever a source needed for this answer timed out, errored, or was skipped - never "no_flags" in that case. |
| domains | Yes | |
| reasons | No | Machine-readable reason codes for anything flagged in this result. Empty when nothing was flagged. |
| summary | Yes | "checked: no findings", or the number of findings by severity. |
| verdict | Yes | |
| findings | Yes | |
| enrichment | No | Results of PG1's domain and wallet checks on what the content names: ran, budget_ms, timed_out, note, domains[], wallets[]. |
| request_id | No | UUID for this request, also sent as the X-Request-Id response header. |
| content_type | No | |
| rules_version | No | |
| wallet_addresses | Yes | |
| findings_truncated | 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: deterministic rules (no AI model), the 4 s enrichment window with an explicit fallback code AGENT_MESSAGE_ENRICHMENT_INCOMPLETE, verdict tiers, data retention (content never stored, only sha256/length/kind/verdict logged), and a rate limit (60/hour, free). Fetch policy (https only, private-address blocking, no redirects, 6 s timeout) is also disclosed.
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?
Purpose is front-loaded and the long rule enumeration is at least parenthetically organized, but the description runs several hundred words for a 3-parameter tool. Much of the exhaustive detection taxonomy (zero-width chars, data: URIs, curl | sh, presign-guard) does not help an agent decide to call the tool and bloats the scan.
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?
Output schema exists, yet the description still summarizes verdicts, finding fields (reason code, severity, line, masked excerpt) and the caveat that no_findings is not proof of safety. Coupled with logging and rate-limit disclosures, an agent has everything needed to call and interpret it.
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 already 100%, so the baseline is 3, but the description reinforces the exactly-one-of text/url constraint and adds fetch semantics (private-address/no-redirect, 6 s timeout, allowed MIME types) beyond the schema. It clarifies the kind enum is recorded only and does not change the 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 and resource: a pre-read injection/manipulation check for a message from another agent or a seller's skill.md. The scope (content inspection, not URL/domain/wallet reputation) separates it cleanly from siblings like check_agent_card, check_x402_endpoint and the check_* reputation tools.
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?
"Call it BEFORE your own model reads the content" gives an explicit timing rule, and the reference to check_x402_endpoint's fetch rules anchors it against a sibling. It does not explicitly say when to skip it (e.g. vs check_agent_card for agent cards), so usage is clear but not fully exclusionary.
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 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. |
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 thoroughly: status semantics (flagged/no_flags/unknown), the important null-vs-false distinction for failed lookups, explicit warning that 'safe'/'clean' is never returned, caching TTLs, a 60 calls/hour rate limit, the X-API-KEY auth exemption, and the exact error codes on malformed input. This is far beyond what any annotation would provide.
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 deliberately structured with front-loaded labeled sections (SIBLING DIFFERENTIATION, BEHAVIOR, STATUS, VALIDATION) so an agent can scan to the relevant part. Some density is unavoidable given the disambiguation and status logic, though the full return-shape listing is partly redundant with the output schema.
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 tool with an output schema, a 3-param schema, and no annotations, the description covers routing, status interpretation, failure modes, rate limits, auth, and data provenance. Nothing an agent needs to call this correctly or interpret the result 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%, so the schema already documents all three parameters and the enum; baseline would be 3. The description adds meaningful semantics beyond it: 'with no version, the latest version is checked' clarifies the null default, 'one package per call' sets cardinality, and the invalid_ecosystem/invalid_package_name/invalid_version codes tie malformed inputs back to specific parameters.
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 ('pre-install check for one npm or PyPI package') and explicitly distinguishes itself from four sibling categories (domains, hostnames, CVE ids, vendor products) by naming the exact alternatives. 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?
Gives explicit when-to-use ('before installing or recommending a software package') and when-not-to-use with the correct sibling for each excluded case ('use check_domain_age / check_hostname_reputation', 'get_cve_details', 'get_cve_by_product'). No inference required.
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: 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: checks an x402-paid URL before you pay it. Fetches the URL once (https only; private addresses and redirects refused) and reads its x402 payment request: each option's network must be a known settlement network and its asset the known USDC contract there; the receiving wallet (payTo) is screened against the OFAC SDN list and its on-chain age read; TLS and the domain's age are checked. Always free (60/hour per caller). Returns status flagged / no_flags / unknown with reasons (X402_UNKNOWN_NETWORK, X402_UNKNOWN_ASSET, WALLET_SANCTIONED, WALLET_NEW_7D, ENDPOINT_TLS_FAILED, DOMAIN_NEWLY_REGISTERED_30D, X402_NO_PAYMENT_REQUEST). no_flags means no flags found, never "safe".
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The https URL of the paid resource. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the entire burden and does so thoroughly: it discloses the fetch policy (single fetch, https only, private addresses and redirects refused), exactly what is validated, the free rate limit (60/hour per caller), the three return statuses, all seven reason codes, and the critical caveat that no_flags means 'no flags found, never safe.' This is unusually complete 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?
The purpose is front-loaded in the first clause, and every subsequent sentence adds substantive information (checks performed, rate limit, return values, caveat). It is dense but not padded; a slightly more scannable structure for the reason-code list would make it a 5.
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 complex, composite security check with no output schema and no annotations, the description is complete: it explains the mechanics, constraints, cost, rate limit, exact return statuses and reason codes, and the interpretation caveat. An agent needs nothing else to call and interpret 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% and the single url parameter is documented there, so a baseline of 3 applies. The description adds meaningful input constraints not in the schema — https only and private addresses/redirects refused — which directly govern which URLs are acceptable, pushing it above the baseline.
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 ('checks an x402-paid URL before you pay it') and immediately distinguishes itself from every sibling by naming the composite checks it performs (x402 payment request parsing, settlement network/asset validation, payTo OFAC screening, wallet age, TLS, domain age). An agent can separate it from check_wallet_sanctions, check_domain_age, or preflight_check 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?
The phrase 'before you pay it' gives a clear triggering context for the tool, so an agent knows when to reach for it. It does not, however, name alternatives or state when-not to use it (e.g., use check_wallet_sanctions alone when only the wallet matters), so it falls short of full routing 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: looks up multiple CVE identifiers in a single call, each enriched with NVD description/CVSS and CISA KEV status (plus the FIRST.org EPSS score when this server serves EPSS in paid responses) — 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 to lean on, the description carries the full burden and does so: payment is required ($0.01 via x402 in params._meta['x402/payment'], alternative PAYMENT-SIGNATURE header, or Gumroad license key in X-API-KEY), the batch cap is 20 ids, and malformed/not-found ids degrade per-entry rather than failing the whole batch. It also flags a conditional capability (EPSS only in paid responses), which prevents a wrong expectation about results.
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 enrichment, then segmented into payment, sibling differentiation and behavior, so an agent can stop reading once it has what it needs. It is somewhat long and the all-caps section labels add bulk, but every sentence carries 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?
No output schema and no annotations, yet the description covers what is returned (per-entry enrichment and per-entry error reporting), what it costs and how to pay, the input ceiling, and how it differs from siblings. Nothing needed to invoke 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% – the cve_ids array, its 'CVE-YYYY-NNNN' format and the 20-per-call cap are already documented in the schema. The description restates the batch context but adds no format, ordering, or error semantics beyond what the schema provides, 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 in one call) and explicitly frames the scope as a batched version of get_cve_details. It also names the exact enrichment returned (NVD description/CVSS, CISA KEV, EPSS), so the agent knows what it gets 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?
Explicitly prescribes when to use it (several known CVE ids at once, e.g. from an SBOM or scan report) and when not to, naming the two correct alternatives (get_cve_details for a single id, get_cve_by_product for vendor/product discovery) with the selecting condition for each.
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 and CISA KEV status (plus EPSS when this server serves EPSS in paid responses), 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 well: it discloses the payment gate ($0.01 x402, PAYMENT-SIGNATURE header, or Gumroad X-API-KEY), the 50-result cap, the cost of the call, and the near-match caveat from keyword search. It omits rate limits, error/insufficient-payment behavior, and whether the version parameter is exact or fuzzy, so not quite a 5.
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 core purpose, then cleanly labeled sections for differentiation, exclusions, and behavior. Every section earns its place, though the branding prefix and all-caps labels add minor noise.
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, and the description compensates by naming the returned fields (CVSS, CISA KEV, EPSS where offered), the sort order, and the result cap. Payment, usage boundaries, and caveats are all covered for a 4-param discovery 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 description coverage is 100%, so all four parameters are already documented with examples. The description adds only that version is optional and that KEV status is part of the enrichment; it adds no syntax or matching-semantics detail (e.g. whether version is exact) 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 ('returns CVEs affecting a given vendor/product'), names the enrichment (CVSS, KEV, EPSS) and ordering, and explicitly distinguishes itself from get_cve_details and get_cve_batch. 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-to-use ('discovering CVEs by vendor/product when you do not already have an exact CVE id'), when-not-to-use, and named alternatives for the exclusion case. The NVD-keyword-vs-CPE caveat further clarifies the appropriate context.
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) and the CISA Known Exploited Vulnerabilities catalog (active wild exploitation status). The epss field (FIRST.org EPSS exploit-probability score and percentile) is present only when this server serves EPSS in paid responses. 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?
No annotations are provided, so the description carries the full behavioral burden, and it does: payment amount and mechanism ($0.01 via x402 in params._meta, header or Gumroad key), failure behavior (isError:true with PaymentRequired in structuredContent and content text), success receipt location, and 404 on not-found. This is unusually complete disclosure for a mutation-free paid lookup.
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 its sources, then sibling differentiation and behavioral notes in clearly labeled blocks. Dense but each sentence (payment, failure mode, 404) carries information an agent needs; 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?
With no output schema and no annotations, the description compensates by describing what is returned (NVD + KEV, conditional EPSS), the error/structuredContent shape, and the settlement receipt path. An agent can invoke and interpret this 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?
Only one parameter with 100% schema description coverage — the schema already documents the strict 'CVE-YYYY-NNNN' format. The description adds no syntax or format 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 and resource (enriched CVE lookup) and names the exact data sources combined: NVD description/CVSS and CISA KEV exploitation status, plus conditional EPSS. This clearly distinguishes it from the many sibling get_* and check_* tools.
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 scopes usage: 'Use ONLY for specific CVE lookups,' with named alternatives for the two adjacent cases — get_ioc_context for IP/domain/hash enrichment and get_threat_indicators for bulk feed ingestion. Adds exclusions for wildcard search and threat-actor profiling, 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: 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 PG1's commercially licensed records, which currently hold only CVE identifiers from NVD (IPs, domains, URLs and hashes return found: false). 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 the full burden and delivers: a 20-indicator cap, the critical interpretation caveat that found:false means 'nothing recorded', not 'safe', the free-batch rule when nothing is found, and the payment gate mechanics (x402 via _meta, PAYMENT-SIGNATURE header, or Gumroad X-API-KEY). This is exactly the non-obvious behavioral context an agent needs before calling.
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 and uses explicit SIBLING DIFFERENTIATION and BEHAVIOR labels, which aids scanning. It is dense and somewhat long, but nearly every sentence (payment gate, found:false semantics) carries operational weight.
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 the return semantics (aggregated provenance, found:false behavior), the batch-size limit, pricing, and auth. Combined with a fully described schema, an agent has everything needed 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 coverage is 100% for the single 'values' parameter, so the schema already documents its type and content. The description restates the accepted indicator types and the max-20 limit, which is largely duplicative; baseline 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?
States a specific verb and resource ('looks up multiple indicators (IPs, domains, URLs, hashes) in a single call') and immediately frames the use case as a batched pre-action safety check. It names the sibling it is not (get_ioc_context) and the bulk alternative (get_threat_indicators), so an agent can distinguish it without opening another 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 ('checking several indicators at once, e.g. all URLs an agent is about to visit') plus two explicit when-NOT cases routing to get_ioc_context for singles and get_threat_indicators for bulk feed sync. 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. PG1's commercially licensed records currently hold only CVE identifiers from NVD, so an IP, domain, URL or hash returns found: false (free) until other licensed sources are added. A match returns aggregated provenance — 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 current data limitation (only CVE identifiers, so most lookups return found:false), the exact result shapes for found/not-found, the fact that not-found is never an error and does not mean 'safe', the free-vs-paid payment model (x402, PAYMENT-SIGNATURE header, Gumroad key), and the failure shape with isError and structuredContent. This is unusually complete.
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 core purpose and structured under explicit SIBLING DIFFERENTIATION and BEHAVIOR labels, which aids scanning. It is dense and somewhat long, but nearly every sentence carries non-redundant information given the absence of annotations and output schema.
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 and no annotations exist, so the description must cover return values and operational behavior — and it does, including result shapes, payment triggers, and error handling. Nothing an agent needs to invoke this 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 there is a single required parameter, so the schema already documents the value format thoroughly. The description reinforces the accepted indicator types but adds no syntax or format 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 (looks up) and resource (a single indicator value) and names the exact scope: IP, domain, URL, or hash. It explicitly contrasts itself against get_ioc_batch, get_threat_indicators, and get_cve_details, 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?
Gives explicit when-to-use ('recommended pre-action safety check before visiting, downloading, or connecting') and when-not-to-use with named alternatives for bulk, multi-indicator, and vulnerability cases. The conditions that select each sibling are 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: 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 CVE records from NIST NVD, the only source PG1 may currently redistribute commercially. Today it contains no IP, domain, URL or file-hash indicators: every object is a STIX vulnerability with the CVE id and an NVD reference, without scores (use get_cve_details for CVSS and known-exploited status). FREE (CVE records from NIST NVD); does not use the 5 free paid calls a day; no payment, no licence key (the operator's PG1_FEED_PAID switch can make it paid). 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).
| 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?
No annotations are provided, so the description carries the full burden and does so: it discloses the cost model (FREE, does not consume the 5 daily paid calls, no payment or licence key, but the operator's PG1_FEED_PAID switch can make it paid), pagination via limit up to 1000, and the active-window restriction on history. This is unusually rich operational context for a zero-annotation tool.
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 purpose leads the description, which is good, but the all-caps section labels (SIBLING DIFFERENTIATION, USAGE EXCLUSIONS, BEHAVIOR) and repeated cost phrasing ('FREE ... no payment, no licence key') create redundancy, and the 1000 max in BEHAVIOR duplicates the limit parameter's own schema text. Dense and informative, but a tighter version would shed a sentence or two.
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 must cover the return shape, cost, and limits, and it does: it names the STIX 2.1 bundle format, its object type (STIX vulnerability with CVE id and NVD reference), the absence of scores and indicator types, the free/paid switch, and pagination. Slightly short only on whether the long-term plan is to add non-CVE indicators, which matters given the schema's indicator-oriented parameters.
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 baseline is 3, but the description adds material meaning the schema does not: the payload today holds no IP/domain/URL/file-hash objects and no scores, which tells the agent that the `type` and `min_score` filters are effectively inert despite being valid enum/threshold values in the schema. That caveat is genuinely additive rather than a restatement of the schema.
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 CVE records from NIST NVD. It explicitly disambiguates from siblings by naming get_ioc_context and get_cve_details as the correct tools for other jobs, and it clarifies what the payload does NOT contain today.
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 routing: 'Use ONLY for bulk feed synchronizations. Do NOT use for single-item lookups (use get_ioc_context) or CVE analysis (use get_cve_details).' It also states the archival limitation ('no historical query archival beyond the active ingestion window'), so both when-to-use and when-not are covered.
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 hosting advisor: ranked regions and providers for a workload, with reasons: data-protection regime, published government data-access frameworks (factual, cited), provider acceptable-use fit, sanctions and export-control compliance, estimated latency, a multi-region/multi-provider redundancy and resilience plan, and privacy-by-design guidance. Every fact cites its official source and date; unverified facts and facts older than 180 days are flagged. Structured input only. Not legal advice. Lawful use only: requests to ignore abuse reports, evade lawful process or bypass sanctions are refused. Payment: $0.01 via x402 (params._meta["x402/payment"]) or a Gumroad licence key, after 5 free calls a day per caller shared with every other paid tool.
| Name | Required | Description | Default |
|---|---|---|---|
| requirements | No | Any of customer_managed_keys, no_us_parent, dedicated_hardware, multi_provider. | |
| uptime_target | No | Percent, default 99.9. | |
| workload_type | Yes | ||
| data_residency | No | Where data may live: any, eu, eea, eu_adequate, or ISO country codes (default any). | |
| latency_regions | Yes | Where the users or callers are. | |
| budget_usd_month | No | Monthly budget in USD. | |
| privacy_priority | No | Default medium. |
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 unusually well: it discloses pricing ($0.01 via x402 or Gumroad licence key), a 5-calls/day free tier shared across all paid tools, source-citation and 180-day staleness flagging, and refusal conditions. It stops short of 5 because it never states what a failed payment or refused request returns, nor anything about call latency or result size.
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 purpose and returned artifacts are front-loaded, with the constraints and payment mechanics trailing. The enumerated factor list is long but each item is a distinct deliverable, so it earns its length; only the payment/free-tier sentence could be tightened.
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?
There is no output schema, and the description compensates by enumerating what comes back (ranked regions/providers with cited reasons, redundancy plan, privacy guidance) plus payment, limits and disclaimers. What is missing is the output shape and payment-failure behavior, which keeps it from a 5.
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 86%, so the schema already documents nearly every parameter (residency values, uptime default, budget units, requirements keywords). The description adds no parameter-level syntax or format guidance, 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 and resource: it ranks regions and providers for a workload, and enumerates the exact decision factors it returns (data-protection regime, sanctions/export control, latency, redundancy plan). No sibling tool touches hosting/infrastructure selection, so the agent can distinguish it immediately from the check_*/get_* family.
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 clear triggering context ('for a workload', structured input only) and explicit when-not-to-use boundaries via the lawful-use clause (requests to evade process or bypass sanctions are refused). It cannot name an alternative because none exists among the siblings, so it falls just short of a 5.
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: ONE call before an agent acts. Give the action you are about to take and its target; PG1 runs every relevant check in parallel and returns one decision: no_flags, flagged or unknown, with merged reasons, per-check results and latency. no_flags means no flags found in the checks run, never "safe". Fail closed: any check that does not finish makes the decision unknown, never no_flags. Actions: pay (a wallet address: sanctions + wallet age; or an https x402 URL: the endpoint's payTo sanctions and age, network/asset sanity, TLS, domain age), open (a URL or hostname: phishing/look-alike reputation + domain age), install (a package: give ecosystem npm or pypi; target name or name@version), patch (a CVE id, or "vendor product version"), trust_agent (an agent's URL or domain: its A2A agent card, domain age and reputation). Payment: $0.01 via x402 (params._meta["x402/payment"]) or a Gumroad licence key, after 5 free calls a day per caller shared with every other paid tool. Results are signed (see verify_result).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | For pay to a wallet: the chain (default base). | |
| action | Yes | What you are about to do. | |
| target | Yes | What you are about to do it to: a wallet address, URL, hostname, package name (name or name@version), CVE id or "vendor product version", or an agent URL/domain. | |
| ecosystem | No | For install: the package registry. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so: it defines the exact decision vocabulary (no_flags/flagged/unknown), states that no_flags never means 'safe', and commits to fail-closed semantics where any unfinished check forces 'unknown'. It also discloses latency, signed results, and payment/rate-limit mechanics.
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 core contract (one call, action+target in, one decision out) before drilling into action-specific rules and pricing. The middle is dense with stacked parentheticals, which costs a little readability, but every sentence carries distinct 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?
No output schema exists, yet the description fully specifies the return shape (single decision, merged reasons, per-check results, latency). It also covers pricing, the 5-free-calls-per-day shared limit, and points to verify_result for signature validation, leaving no material gap for a 4-parameter 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%, but the description goes well beyond the terse enum descriptions by giving per-action target semantics (wallet address vs x402 URL for pay, URL/hostname for open, ecosystem plus name@version for install, CVE or 'vendor product version' for patch, agent URL/domain for trust_agent) and notes chain defaults to base for wallet pay.
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: takes an action+target and runs all relevant PG1 checks in parallel, returning one merged decision. It explicitly positions itself against the sibling single-check tools by promising 'every relevant check' in 'ONE call before an agent acts'.
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?
Clearly frames the use context (a preflight decision before an agent acts) and details which action values are supported and what target each expects. It does not, however, explicitly tell the agent when to prefer it over the granular sibling checks (check_wallet_sanctions, check_package, etc.) or when a single-purpose check is enough.
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: verifies that a result really came from PG1, unchanged. Every PG1 tool result is signed (Ed25519) over its request hash, result, sources, timestamp and PG1 version; the signature is in result._meta["pg1/signature"] (MCP), the task's metadata["pg1.signature"] (A2A) or "signature" (REST). Give the result object and the signature block; optionally tool and arguments to check it answers that exact request. Public keys: https://pg1-ai-agent.vercel.app/.well-known/pg1-signing-key (JWKS); you can verify offline without this tool. Always free.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | Optional: the tool that was called. | |
| result | Yes | The tool result as received (its signature field, if any, is ignored). | |
| arguments | No | Optional: the arguments it was called with. | |
| signature | Yes | The signature block. |
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 names the signature algorithm (Ed25519), the signed payload (request hash, result, sources, timestamp, PG1 version), and where the signature lives per transport (MCP _meta, A2A metadata, REST field). It also discloses cost ('Always free') and that verification can be done offline. The only gap is the shape/semantics of the verification outcome, which is neither described nor provided by an output 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?
Purpose is front-loaded in the first sentence, followed by the signature scheme, the per-transport signature locations, the input instructions, and the key/offline note. Four dense sentences, all earning their place, though the transport-location and key-URL details could be pushed to linked docs without losing meaning.
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 read-only verification tool with a fully documented 2-required/2-optional parameter set, the description covers inputs, signature provenance, key retrieval and an offline alternative. With no output schema, it leaves the verification response format (pass/fail, error reasons) unstated, which is the one meaningful omission.
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 baseline is 3, but the description adds genuine meaning: it explains that passing tool and arguments binds the check to a specific request hash ('to check it answers that exact request'), and that the result's own signature field is ignored in favor of the supplied block. That is more than the schema's terse 'Optional: the tool that was called.'
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 (verifies) and resource (a PG1 result's authenticity/integrity) with the scope spelled out: 'really came from PG1, unchanged'. No sibling tool in the list performs signature verification, so it is unambiguously distinguishable from check_*/get_* tools.
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?
Explains exactly what to pass (the result object and signature block, optionally tool and arguments to bind the result to a specific request) and notes the alternative path: 'you can verify offline without this tool' with the JWKS URL. It stops short of stating when verification is required versus optional, so it is clear context rather than an explicit when/when-not rule.
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_agent_messagesubscribe_alertscheck_agent_cardcheck_x402_endpointhosting_advisorpreflight_checkverify_resultcheck_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"
+}Pay-per-call safety checks for AI agents: screen a crypto address or URL before you transact.
Safety checks before you sign, pay or install: contract, token and package scans, phishing, OFAC.
Token rug-risk scans, Know Your Agent wallet checks and deployer reputation for AI agents.
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
Add one secure layer between your agents and this server.