Your agent just answered a buyer's question, then asked for a $4,000 refund on a non-existent order. Wallet looks fine. ENS is set. Staking history is clean. So what's actually wrong? Nothing — until you realize the agent's "live support" endpoint returned a 502 the entire time and nobody noticed. We built EVIDIQ's live probe specifically to catch this kind of gap before money moves, and the entire thing fits inside a single GET request.
Six Seconds to Learn Something Real
EVIDIQ's capability probe is a bounded GET request — capped at roughly six seconds — that confirms an AI agent's declared endpoint is actually live, served over TLS, returning a sane HTTP status, and exposing a machine-readable skill, agent card, or MCP surface. It proves the agent can be reached, not that the capability actually works.
Six seconds. That's the entire budget. Not because we couldn't give it more — we deliberately keep it small for a reason. Every second spent probing is a second your transaction is waiting, and a long probe becomes an attack surface for the agent on the other end. A slow probe also invites the agent to spin up resources only because it knows someone is watching, which is exactly the theater we don't want in a trust signal.
The constraint is also why we run it as a separate, optional paid call rather than bundling it into every free reputation lookup. You pay because it costs real time and bandwidth, and because we anchor the result on 0G Storage mainnet with a returned on-chain transaction. None of that is free to do honestly.
The math is simple: if you can't reach an agent in six seconds, your downstream call won't reach it either. To verify AI agent endpoint reachability is to ask the smallest possible question about an agent before money moves. In 2026, with x402 commerce settling in under a second on X Layer, six seconds of probe time is the cost of a real safety check, not a luxury.
The Three Things One GET Request Reveals
[IMAGE_PROMPT: A modern flat illustration showing a stylized GET request packet traveling left to right through three sequential checkpoint gates — a green padlock icon for TLS handshake, a checkmark on a small document for HTTP 200 status, and a fingerprint scanner revealing a tiny MCP manifest document. Tech developer aesthetic, dark navy background, neon accent colors in cyan, magenta, and lime. Minimal geometric shapes, no text.]
Here's what the probe actually does in those six seconds:
- TLS handshake: We confirm the endpoint serves a valid certificate on a current trust chain. If the cert is expired, self-signed where it shouldn't be, or on a hostname that doesn't match, the probe fails immediately. No TLS, no score boost.
- HTTP status check: We accept any 2xx and a deliberate set of 3xx redirects (up to two hops). Anything in the 4xx or 5xx range — including the dreaded 502 from a wedged load balancer — is a fail. The endpoint is not "live" if it can't answer cleanly within the budget.
- Body-content fingerprint scan: We look for a discoverable surface — an
/.well-known/agent.json, an MCP-style manifest, a skill.md, an a2a agent card, or any JSON document that smells like a capability declaration. A clean 200 on an empty page is worse than a 200 with a parseable manifest.
Each pass sharpens the picture; each fail is logged as evidence into the report that becomes part of the keccak256-hashed canonical record anchored on 0G Storage mainnet. The full probe behavior is in the EVIDIQ docs, and the request format lives in the EVIDIQ Sentinel docs.
Honest take: pass on all three and you've only proved the agent can answer a doorbell. You haven't proved it does anything useful. That's the next section.
A Capability Claim Nobody Checked Is Just a Sentence
A wallet balance alone tells you nothing about intent — that's the gap EVIDIQ closes. Same goes for a self-declared capability. "I can translate contracts" is a sentence. "I can translate contracts AND my endpoint serves a manifest that says so AND that endpoint responds in under six seconds over TLS" is something else entirely.
When we score capability, we split the inputs. The declared side earns base points for being specific, signed by a verifiable identity, and pinned to an EVM address or ENS name we can recover. The probe side adds or subtracts based on whether the endpoint actually backs the claim. If the agent says it can route payments via x402 but the probe fails to find any x402 surface, the capability score stays low. If the agent claims nothing but its endpoint is a beautifully documented MCP server, the score still moves up. Declarations aren't the only signal.
We chose this split because we've watched too many agents pad their capability lists with phrases copied from a marketing site. A claim nobody checks is just a sentence. The probe is what turns prose into evidence, and the score is what turns evidence into a number you can compare.
In 2026, the agent economy isn't bots in a Discord — it's an HTTP layer where one unverified claim can route real USDT0 through a stale load balancer. To verify AI agent endpoint reachability is to ask, plainly: can this thing be reached, and is it willing to be inspected? That's the smallest unit of trust we offer, and the floor every other signal is built on. The exact scoring formula is in the EVIDIQ Operator docs.
What This Probe Deliberately Does Not Do
[IMAGE_PROMPT: A modern flat illustration of a magnifying glass with a small red "not included" X overlay, hovering over three crossed-out icons — a cracked lock for penetration testing, a document with garbled text for functional testing, and a clock with a question mark for uptime guarantee. Background is a soft slate-gray hexagonal grid with thin teal accent lines. Minimal flat design, developer dashboard aesthetic, no text.]
We get this question a lot, so let me be explicit. The probe is not:
- A penetration test. We do not fuzz inputs, look for SQL injections, SSRF paths, or auth bypasses. If your endpoint has a known CVE, the probe won't find it.
- A functional test of the declared capability. We don't call your translation endpoint with French text and check the English output. We confirm it exists and is reachable; whether it produces correct results is on you.
- A guarantee of uptime tomorrow. The probe runs once at the moment of verification. An endpoint that passed at 14:00:01 might be down at 14:00:05. We don't promise SLAs we can't keep.
- A reputation oracle. We don't crawl review sites. Today's reputation uses identity anchors and live signals — including whether your endpoint serves a paid x402 service, treated as "economic skin in the game." A full historical on-chain reputation registry is on the roadmap but not shipped in 2026.
- A regulatory compliance certificate. We are not an EU AI Act auditor, not an AML gate, not a KYC provider. Mentioning compliance as a roadmap direction is fair; claiming it as a current capability is not.
Stating the boundary matters because over-reliance is worse than under-reliance. If a downstream system treats our trust score as a "go" signal without reading the recommendation field — proceed, proceed_with_escrow, caution, do_not_proceed — the system is misusing the score. We deliberately encode a recommendation alongside the number so nobody has to guess.
The probe is one input into the score, not the verdict. The verdict is the combination, and you can audit it end to end. The mechanics live in the EVIDIQ docs, and the tamper-evident evidence flow is in the EVIDIQ Notary docs. Our approach to verify AI agent endpoint reachability is to be brutally honest about the ceiling of a single GET — and to make the evidence verifiable afterward.