Straelo Relay

Scan a customer domain to detect vendors and technologies currently present using deterministic fingerprints; returns detected technologies with supporting evidence and observation details. Results are point-in-time observations; eligible CSI observations may be persisted best-effort. An empty detection means no supported fingerprint was observed in that scan — it does not prove the domain uses no technology. Side effect: eligible CSI observations may be persisted best-effort to maintain customer-vendor evidence. **USE WHEN:** an agent needs to determine which supported vendors or technologies are currently detected on a specific customer domain. **DO NOT USE WHEN:** the agent needs confirmed customer base of a vendor (use vendor-customer-confirmed-lookup), historical adoption/removal events (use vendor-customer-adoption-change-lookup), or customer transition signals (use vendor-customer-transition-signal-lookup). Parameter semantics: domain is the customer domain to inspect, not a vendor domain.

Compare read-only Base swap quotes obtained from 1inch and KyberSwap, evaluating output, minimum output, fees/gas, price impact, consensus, and divergence to return a deterministic economic route decision (EXECUTE_BEST, WAIT, or INSUFFICIENT_DATA). The product consults external providers during the request; quotes reflect the market state observed at that moment and identical calls can produce different results. Provider unavailability or failure can yield a partial result or insufficient data. The product does not execute, submit, sign, or authorize a swap or transaction. USE WHEN: an agent needs to compare available swap routes on Base and determine whether to execute the best route, wait, or treat the available market data as insufficient. DO NOT USE WHEN: the agent needs to execute or submit a swap, sign a transaction, or perform a transaction-safety authorization.

Inspect a public domain across DNS, HTTP/HTTPS/TLS, email posture and AI-agent discovery surfaces, including robots.txt, llms.txt, OpenAPI, MCP, x402 and Agent Card availability. USE WHEN: an agent needs a single-call observational check of a domain's surfaces or wants to compare with a previous state. DO NOT USE WHEN: protocol validation, Agent Card/A2A validation, MCP compliance validation, security certification, or a consumption guarantee. **USE `domain_risk_trust_decision` FOR:** merchant/domain trust. Operational behavior: no tool-specific auth or rate limit; remote surfaces may throttle requests.

Deterministic domain risk and trust evaluation returning ALLOW / REVIEW / BLOCK. Decision for observed evidence; external evidence may change between calls. Uses DNS, RDAP, TLS, HTTP/redirect, URLhaus threat reputation, local indicators. Read-only: external read queries only, no action on domain, no persistence, limited cache. USE WHEN: decide whether domain is safe enough for interaction, onboarding, outreach, or payment. DO NOT USE WHEN: consolidated domain health/operational inspection (use domain_agent_discovery_check) or email validation (use email_suitability_decision). Example: domain='example.com'.

Evaluate whether an email address is suitable for a specified use case using syntax, MX, SPF, DMARC, disposable-domain, and role-account signals. Decision for observed evidence; external DNS evidence may change between calls. Returns an ALLOW, REVIEW, or REJECT decision with deliverability score, risk level, confidence, checks, and reasons. Does not send email, probe the mailbox via SMTP, verify that the mailbox exists or is owned by a specific person, or guarantee delivery. Read-only DNS lookups may affect latency or availability; no tool-specific rate limit. **USE WHEN:** an agent needs to decide whether an email address is suitable for outbound sales, account signup, transactional email, CRM import, lead qualification, or another supported use case. **DO NOT USE WHEN:** the agent needs domain-level risk and trust assessment or proof that a mailbox exists. **USE `domain_risk_trust_decision` FOR:** domain-level risk and trust assessment.

Retrieve the current gas price for Ethereum or Base for transaction planning. Returns wei and gwei from a single `eth_gasPrice` JSON-RPC call; live network result may change between calls and does not estimate total transaction cost, submit a transaction, or provide execution authorization. USE WHEN: an agent needs the current EVM gas price before estimating fees or preparing a transaction. DO NOT USE WHEN: the agent needs to inspect an existing transaction by hash (use `evm_transaction_hash_lookup`) or retrieve a wallet balance (use `evm_wallet_balance_lookup`).

Retrieve the latest block number for Ethereum or Base using a single eth_blockNumber JSON-RPC call; live chain state may change between calls. USE WHEN: an agent needs the current chain height for Ethereum or Base as a synchronization, sequencing, or transaction-context reference. DO NOT USE WHEN: the agent needs block contents, transactions, wallet balances, gas prices, historical blocks, confirmations, or finality. Parameter semantics: chain accepts exactly ethereum or base and is case-sensitive. Returns chain, block_number as a decimal integer, and observed_at as a UTC timestamp.

Evaluate an intended EVM transaction before submission using deterministic RPC simulation signals and return a machine-readable STRAELO execution decision. The decision engine is deterministic for the same observed RPC evidence; live chain state may change between calls. USE WHEN: an agent needs to evaluate an EVM transaction before deciding whether to submit it. DO NOT USE WHEN: the transaction has already been submitted and the agent needs to look it up by transaction hash; use evm_transaction_hash_lookup instead. This product does not broadcast transactions and does not guarantee that an allowed transaction will execute successfully when later submitted. `from_address` is the sender whose execution context is simulated; `to_address`/`data`/`value` together form the intended transaction form. INCOMPLETE means simulation/provider evidence was insufficient for a conclusive execution decision and must not be treated as ALLOW. Returns ALLOW, WARN, BLOCK, or INCOMPLETE with the simulation evidence and execution signals produced by the current decision engine.

Look up an EVM transaction by transaction hash and return normalized transaction facts, including status, block number, sender, recipient, value, gas usage, and contract method selector. This is a factual post-transaction lookup on Ethereum or Base; live chain state may change between calls and does not simulate, send, sign, or evaluate whether the transaction was safe or appropriate to execute. USE WHEN: an agent already has an EVM transaction hash and needs to inspect the corresponding on-chain transaction. DO NOT USE WHEN: the agent needs a pre-execution transaction decision, a gas-price lookup, a wallet-balance lookup, or the latest block. A syntactically valid hash that is not found on the selected network returns NOT_FOUND as a factual result rather than a validation error.

Retrieve the current native ETH balance of a wallet on Ethereum or Base and, optionally, balances for up to 20 specified ERC-20 token contracts. Results are point-in-time observations of live chain state and may change between calls. Does not evaluate wallet ownership, solvency, transaction safety, or whether a transaction should be executed. USE WHEN: an agent needs the current ETH balance or balances of specific ERC-20 tokens for an EVM address. DO NOT USE WHEN: the agent needs transaction details (evm_transaction_hash_lookup), current gas price (evm_gas_price_lookup), historical balances, or a transaction execution decision.

Evaluate a crypto token for agent interaction using security evidence from GoPlus (primary) and Honeypot.is (complementary, EVM chains only) and return a STRAELO decision that is deterministic for the same observed provider evidence; provider evidence can change between calls and external provider calls may affect latency and availability. There is no tool-specific rate limit. USE WHEN: an agent needs a machine-readable security decision before interacting with a token on Base, Ethereum, BSC, or Solana. DO NOT USE WHEN: the agent needs a guarantee that a token is safe, legitimate, scam-free, or risk-free; provider evidence may be unavailable or incomplete. Returns ALLOW, REVIEW, AVOID, or INCOMPLETE with supporting evidence. Missing or insufficient provider evidence fails closed and never produces ALLOW.

Retrieve confirmed customer adoption changes for a specified vendor within a UTC time window, returning customer domains with `ADDED` or `REMOVED` events, supporting evidence, and timestamps. `ADDED` represents a confirmed `ABSENT -> PRESENT` transition and `REMOVED` represents a confirmed `PRESENT -> ABSENT` transition in STRAELO CSI observations; `REMOVED` does not by itself prove a vendor switch or contract cancellation. USE WHEN: an agent needs historical evidence of customers adopting or removing a specific vendor during a period. DO NOT USE WHEN: the agent needs customers currently confirmed as using a vendor (`vendor_customer_confirmed_lookup`), vendors currently detected on a specific customer domain (`customer_vendor_detection`), or potential vendor replacement signals (`vendor_customer_transition_signal_lookup`). Results reflect persisted CSI history and may change as new transitions are recorded; the tool does not perform live scans or modify state.

Retrieve confirmed customer domains currently using a specified vendor from STRAELO's persisted CSI coverage. Returns only confirmed `PRESENT` customer-vendor relationships with supporting evidence and confirmation timestamps, normalized and deduplicated. Results represent STRAELO's currently confirmed coverage, not the vendor's complete global customer base; an empty result means no confirmed customers are available within STRAELO coverage for that vendor, not that the vendor has no customers. **USE WHEN:** an agent needs to identify which customers are currently confirmed as using a specific vendor. **DO NOT USE WHEN:** scanning a specific customer domain for detectable vendors (`customer_vendor_detection`), retrieving historical adoption/removal events (`vendor_customer_adoption_change_lookup`), or identifying customer transition signals (`vendor_customer_transition_signal_lookup`).

Find customer domains with observed technology transition signals involving a specified vendor and return prioritized signals with supporting evidence. USE WHEN: an agent needs to identify customer-level technology transition signals related to a vendor for prospecting or change analysis. DO NOT USE WHEN: the agent needs confirmed proof that a customer switched from one vendor to another (`vendor_customer_confirmed_lookup`), historical ADDED/REMOVED adoption events (`vendor_customer_adoption_change_lookup`), or vendors currently detected on a specific customer domain (`customer_vendor_detection`); POSSIBLE_REPLACEMENT is a correlated signal, not a confirmed switch. Side effect: unsupported-vendor requests may persist aggregated demand telemetry. Results reflect CSI snapshots and may change between calls.

Check an x402 payment request before signing or paying and return a deterministic PAY, REVIEW or DO_NOT_PAY decision. USE WHEN: agent needs deterministic verification of a payment requirement before deciding whether to pay. DO NOT USE WHEN: agent expects this tool to execute the payment. Offline/read-only preflight: no network calls, signing, settlement, or payment execution. Decision derives from comparing declared intent against the supplied x402 v2 PAYMENT-REQUIRED; mismatches yield DO_NOT_PAY, material snapshot changes yield REVIEW, consistency yields PAY.