What EVIDIQ Probes to Verify AI Agent Endpoint Reachability

Your agent says it can settle cross-border payments. The wallet is funded, the capability list looks plausible, and the agent card JSON is well-formed. You have one chance to interact with it before committing a thousand USDC. What do you actually know about the machine on the other end of that URL? Almost nothing — until you ask EVIDIQ to verify AI agent endpoint reachability.

Teams use this preflight to verify AI agent endpoint reachability before the first paid call, to compare the declared surface with the live response, and to verify AI agent endpoint reachability again when the decision is time-sensitive. It gives operators a repeatable way to verify AI agent endpoint reachability without treating a single 200 response as approval.

We built EVIDIQ's probe to answer one narrow question: right now, is this declared endpoint actually alive, on TLS, and speaking a protocol a downstream agent can use? It's not a vibe check on the agent's overall trustworthiness. It's a single, bounded HTTP probe that returns hard facts, and those facts flow straight into the deterministic trust score you eventually receive. Everything below is what we actually do inside that probe — and, equally important, what we deliberately don't.

Six Seconds to Learn Something Real

Verifying AI agent endpoint reachability is the live HTTP probe EVIDIQ runs against an agent's declared URL. It performs one bounded GET request — TLS handshake, status check, and a body-content scan for a skill, agent-card, or MCP fingerprint — inside a strict ~6-second budget. The result feeds directly into EVIDIQ's deterministic trust score.

Six seconds is not an apology. It's a constraint we chose on purpose.

When an agent hands over an endpoint URL, the caller usually has no patience for a 30-second health check and no interest in being a free load test target. So we cap the probe at roughly six seconds from connect to last byte. If the server can't produce a meaningful response inside that budget, that itself is a signal — the endpoint is too slow to be relied on for a real-time decision anyway. A fast timeout tells us more about the agent's operational maturity than a slow one. And critically, a single bounded probe also keeps us from accidentally hammering a target. We're guests, not auditors.

The 6-second budget has a second, more practical job: it forces the probe to be cheap. Every EVIDIQ verify_agent call is paid per call over x402 in USDT0 on X Layer, and we don't want the cost of one probe to be larger than the cost of the decision the score is supporting. That's the design pressure that keeps the probe small, focused, and reproducible.

The Three Things One GET Request Reveals

Inside the six seconds, exactly three things get checked. Not four. Not "everything we can think of." Three.

1. TLS presence. We confirm the endpoint actually speaks HTTPS — and not in name only. A valid certificate chain, a non-expired leaf cert, and a hostname that matches the SAN are the floor. No TLS, or a self-signed cert presented as production, fails this check immediately. Plain http:// endpoints are treated as a hard failure on capability scoring regardless of what the body says.

2. HTTP status. Anything in the 2xx range passes; 3xx is followed once within the budget; 4xx and 5xx are treated as the endpoint being unreachable for the purposes of this probe. We're not picky about 200 vs 204 vs 206 — what we care about is "did the server answer our GET with something that isn't an error."

3. Body-content scan. This is the part most people don't expect. The GET request isn't generic — it's targeted at well-known machine-readable surfaces: an Agent Skill file at skill.md, an agent-card.json, an MCP manifest, or a similar discovery document. If the body contains recognizable fingerprints of any of these, the probe tags the endpoint as serving a real, parsable protocol surface. If the body is a generic marketing page, a Cloudflare challenge, or a 200 OK with no meaningful payload, that also gets recorded — as a fail.

What a pass looks like in the score: the capability component jumps toward 60–80 of 100, the risk component drops, and the recommendation frequently shifts from caution toward proceed or proceed_with_escrow. What a fail looks like: the endpoint is still recorded, but the capability component stays low and the recommendation stays at caution. We never silently downgrade a pass — and we never silently upgrade a fail.

A Capability Claim Nobody Checked Is Just a Sentence

Here's the thing: an agent declaring "I can do X" tells you nothing. A capability claim is a sentence. The probe is what turns it into evidence.

EVIDIQ's capability score rewards two things, in this order:

• A declared capability (the agent's own JSON or skill file says it can do X), and
• A live endpoint that backs it up (the probe just confirmed a reachable, TLS-served, machine-readable surface that actually exposes how to call X).

One without the other is roughly half a score. A beautifully declared capability that points to a dead 503 endpoint is, in practice, the same as a marketing site claiming the same thing — there's no path from intent to action. And conversely, a perfectly live endpoint that serves only a "Hello world" page tells you nothing about what its owner is willing or able to do for you.

We weight these together with identity and reputation inside the EVIDIQ scoring formula:

identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2

Same inputs, same score, every time. Deterministic and auditable — which is the whole point of doing the probe in the first place instead of trusting vibes. If you want to see the math broken out field by field, the EVIDIQ docs cover it end to end.

There's also a quieter signal buried in this. An agent that runs a paid x402 service on its endpoint is, in our experience, a more reliable counterparty than one that runs a free demo on a subdomain. Economic skin in the game shows up in the reputation component and gets noticed by the probe — even if it never reaches the user as a line item. Worth noting: we don't treat paid x402 as proof of goodness, only as a signal that someone put money on the line for this endpoint to stay alive.

What This Probe Deliberately Does Not Do

A probe is not a promise. We say this out loud because the failure mode we're most worried about is someone reading "live probe passed" and treating it as "this agent is safe to transact with forever."

Here is what the probe explicitly does not check:

• It is not a penetration test. We send one GET. We don't fuzz, we don't probe adjacent ports, we don't look for SSRF, we don't try to break in. If you want a security audit, run a security audit.
• It is not a functional test. A live MCP manifest means the server advertises the right shape. It does not mean the model on the other side actually answers your prompt correctly, hallucinates less, or returns well-typed JSON every time.
• It is not an uptime guarantee. The endpoint was alive the one moment we hit it. Tomorrow, next week, or at 3am during your trade — we have no idea. We snapshot a point in time and move on.
• It is not a content review. We don't read the agent's skill text for safety, bias, or jailbreak risk. That's a separate, slower process — and frankly, no short probe could do it honestly.

We'd rather you under-trust the probe result than over-trust it. A pass says "this endpoint is alive and speaking the right dialect right now." Anything stronger than that, you have to earn with more calls, more history, or — when it's worth it — escrow and dispute rights you negotiate yourself. EVIDIQ never holds funds and never grants authority; we produce evidence and a recommendation, and you choose your protection.

If you want the long-term picture, that's exactly what the EVIDIQ Notary docs covers: hashing the canonical report, anchoring it on 0G Storage, optionally running risk analysis on 0G Compute, and signing the verdict so anyone can re-fetch and verify. The probe is the input. Notary is the receipt.