"Handshake" matching MCP tools:

• buy_domain_crypto

  instadomain

  Start the purchase flow for a domain using USDC crypto payment (x402 protocol). Autonomous two-step payment flow — no browser required: Step 1: Call this tool to reserve the domain and get a pay_url. Step 2: Pay the pay_url using your x402 wallet: - If you have Coinbase Payments MCP: call its x402 payment tool with the pay_url. - Otherwise: run `curl -L <pay_url>` — your x402-enabled HTTP client will handle the 402 handshake and USDC payment on Base automatically. After payment succeeds, call get_domain_status(order_id) to poll until registration is complete (usually under 60 seconds). The registrant contact details are required because the domain will be registered in the buyer's name (they become the legal owner). WHOIS privacy is enabled by default, so these details are not publicly visible. IMPORTANT: Before calling this tool, you MUST first call check_domain to get the price and confirm it with the user. Args: domain: The domain to purchase (e.g. "coolstartup.com"). first_name: Registrant's first name. last_name: Registrant's last name. email: Registrant's email address. address1: Registrant's street address. city: Registrant's city. state: Registrant's state or province. postal_code: Registrant's postal/zip code. country: 2-letter ISO country code (e.g. "US", "GB", "DE"). phone: Phone number in format +1.5551234567. org_name: Organization name (optional, leave empty for individuals). Returns: Dict with order_id, pay_url (full URL to pay via x402), price_usdc, price_cents, network, and USDC contract address.

  Connector

• dns_diagnose_sip_target

  Sipflow

  [cost: external_io (DNS via Cloudflare + Google; TLS handshake to public sips/_sips._tcp targets when applicable) | read-only | rate-limited per IP: 10/min, 200/day] Walk DNS the same way a SIP UA does (RFC 3263 §4.1): NAPTR → SRV → A/AAAA. Given a SIP URI ("sip:example.com"), bare hostname ("example.com"), or "host:port" string, return the records that exist and the resolution ladder a UA would try. When the queried target uses TLS (`sips:` URI, `transport=tls/wss`, or any `_sips._tcp` SRV record), the tool also performs a TLS handshake against each resolved sips target and reports the negotiated TLS version + cipher, the leaf certificate's subject / issuer / SANs / validity, the chain length and whether it validates against Node's default trust store, plus two cert-domain checks: RFC 5922 §7.2 strict (cert must cover the original SIP domain) and a lenient SAN match against the SRV target hostname. Egress safety: - Per-IP rate limited. - Hostnames that resolve only to RFC 1918 / loopback / link-local / documentation / multicast space are refused (SSRF guard). - Walk depth capped to prevent runaway NAPTR / CNAME chains. - TLS probes capped at 4 (host, port) tuples per call, 5 s handshake timeout each, public-IP only (we connect to the resolved IP, not the hostname, so the system resolver cannot redirect us into private space). Use to diagnose: - "carrier doesn't answer" / "wrong port" / "TLS instead of UDP" routing puzzles - "carrier rejects our target because no SRV is published" - when A/AAAA resolves but SRV is missing the tool synthesises a copy-pasteable suggested zone-record block pointing at the resolved canonical hostname - "TLS handshake works but cert isn't valid for the SIP domain" - RFC 5922 §7.2 compliance is checked separately from generic chain validation, since the SAN must cover the *original* SIP domain (not the SRV-redirected target) ACL caveat: this tool checks DNS + TLS only. Most carriers (Twilio, Telnyx, Bandwidth, …) authorize inbound SIP by source IP whitelist on the trunk (see https://www.twilio.com/docs/sip-trunking/api/ipaccesscontrollist-resource). Even if DNS resolves cleanly and the TLS cert is valid, INVITEs from any IP not on your trunk's IP ACL will be silently dropped or rejected. Verify reachability from the SBC itself. Pair with: `troubleshoot_response_code` when 503 / 408 / 480 are involved; `search_sip_docs(vendor=...)` for carrier-specific routing docs.

  Connector

• devops_check_certs

  devops-status-mcp-server

  Inspect SSL/TLS certificate health for one or more domains by performing a real TLS handshake. Works for any internet-accessible domain — no vendor registry required. Reports days to expiry (flagged at < 30 days warning and < 7 days critical), certificate subject and SANs, issuer, chain depth, TLS protocol version negotiated (flags TLS 1.0/1.1 as insecure), cipher suite, and HSTS presence.

  Connector

• ambr_agent_handshake

  Ambr

  Initiate a handshake on a contract on behalf of your delegating principal. Requires an API key with an active delegation (principal wallet registered via /api/v1/delegations). Records the agent's intent to accept, reject, or request changes on the contract. The principal must separately approve via wallet signature on the Reader Portal. Args: - contract_id (string, required): Contract ID (amb-YYYY-NNNN), SHA-256 hash, or UUID - intent (string, required): "accept" | "reject" | "request_changes" - message (string, optional): Note for the counterparty - visibility_preference (string, optional): "private" | "metadata_only" | "public" | "encrypted" Returns: Handshake status and next steps for principal approval. Legibility: the handshake itself is auditable — delegation scope, agent identity, and principal approval are recorded alongside the contract hash.

  Connector

• query_registry

  Arclan MCP Registry

  Search the Arclan registry for MCP servers. By default returns only connectable servers (active, mcp_partial, auth_gated). Use status=stdio to browse local-only servers available for installation. Use status=all to query the full index. Use production_safe=true to restrict to servers with uptime > 97% and handshake success > 95%. Use read_only=true to restrict to servers with no write or exec tools. Use this before connecting to an MCP server to check its validation status and score. After using a server, call report_server to contribute reliability data.

  Connector

• dossier_tls

  drwho.me developer tools

  Core dossier check: Fetch and inspect the TLS certificate presented by a domain on port 443, returning chain details and validity period. Use to verify certificate expiry, issuer, Subject Alternative Names, or detect mismatched or self-signed certs; not a full cipher-suite scanner. Performs a TLS handshake from the server edge, 5 s timeout; extracts the leaf certificate. Returns a CheckResult: on success, {status:"ok", subject, issuer, validFrom, validTo, daysRemaining, sans, fingerprint}; on failure, {status:"error", reason}.

  Connector

• dossier_tls

  drwho.me

  Core dossier check: Fetch and inspect the TLS certificate presented by a domain on port 443, returning chain details and validity period. Use to verify certificate expiry, issuer, Subject Alternative Names, or detect mismatched or self-signed certs; not a full cipher-suite scanner. Performs a TLS handshake from the server edge, 5 s timeout; extracts the leaf certificate. Returns a CheckResult: on success, {status:"ok", subject, issuer, validFrom, validTo, daysRemaining, sans, fingerprint}; on failure, {status:"error", reason}.

  Connector

• verify_guest_identity_for_check_in

  lilo Vacation Rentals

  Create a secure guest verification and check-in link for a confirmed vacation rental booking. Verifies guest identity via phone, presents house rules for acknowledgment, records consent with verified evidence, and provides access codes upon agreement. Returns a unique handshake link.

  Connector

• quantum_deal

  quantum

  Deal Handshake: propose a deal, get terms, rate. Agent-to-agent commerce.

  Connector