How We Verify AI Agent Endpoint Reachability at EVIDIQ

Picture this: your agent is about to pay 50 USDT to another agent for a translation job. The counterparty's endpoint was declared — maybe an HTTPS URL pasted into a registration form — and now you're three seconds from a signed authorization. How do you know the URL is actually live? That it speaks a protocol your agent can parse? That whoever declared the capability can serve it?

You don't, unless something probes it first.

That's the work EVIDIQ does in roughly six seconds. We built a trust layer for the autonomous AI-agent economy, and one of the most concrete things our service does is verify AI agent endpoint reachability before anyone pays anything. Not a marketing promise — a deterministic, evidence-producing step inside the verify_agent MCP tool. The probe is small, bounded, and loud about what it proves and what it doesn't. This post is the honest walkthrough.

Six Seconds to Learn Something Real

A trust layer is mostly a question of what you can prove in a tight time budget. When we designed the live probe that runs inside EVIDIQ's verify_agent call, we gave it a hard ceiling: the GET request to the agent's declared endpoint must complete in roughly six seconds, or it counts as failed. That's not an apology for a limitation — it's a deliberate constraint. An unbounded probe is a denial-of-service waiting room. Six seconds is enough to learn something real about whether the endpoint is alive, whether it serves over TLS, and whether it speaks a recognizable agent protocol. It's not enough to do anything adversarial, and that's the point.

EVIDIQ's endpoint reachability probe is a bounded, ~6-second GET request to an agent's declared URL that checks three things: TLS presence, HTTP status code, and a body-content scan for a machine-readable skill, agent-card, or MCP surface. It runs inside the verify_agent MCP tool and feeds directly into the deterministic trust score.

The probe is one of the signals that feed the capability axis of the score. If you'd rather see the formula before the wire-level details, the EVIDIQ docs lay it out: identity contributes 30%, capability 30%, reputation 20%, and risk is inverted at 20%. Capability score is the only axis where the probe is allowed to raise a score from a tie. Everything else flows from identity anchors and live signals.

The Three Things One GET Request Reveals

One GET. Three checks. Each is logged in the evidence bundle, and each can independently fail.

1. TLS presence. First check: does the endpoint actually speak HTTPS? A plain http:// URL is a hard fail on the capability axis — no negotiation, no fall-back. This isn't a deep certificate inspection; it's a reachable-TLS-handshake check. If your declared endpoint is http://agents.example.com/translate, you get zero on the live capability signal. The fail mode in practice is mostly misconfigured dev servers or someone copy-pasting a non-prod URL into a registration form.

2. HTTP status. The probe then reads the response code. A 2xx is alive. A 3xx is followed one hop only — we don't run a full redirect chain. A 4xx or 5xx is a failure with the status preserved in the report. The status code matters because the next check — the body scan — needs a 200, but the score also weighs the header response itself. A 200 under any load is materially different evidence from a 503.

3. Body-content scan for a skill/agent-card/MCP fingerprint. The most interesting check. Once the probe has a 200 body, it looks for a machine-readable surface — an agent card, an MCP manifest, an EVIDIQ-formatted skill file, or any "I am an agent and here is what I do" marker. A pass raises the capability score. A 200 with a generic marketing page is a weaker pass. A 200 with no agent surface at all is a check-level fail, even though the endpoint is reachable.

An endpoint can pass TLS, return a 200, and still fail the live probe because the body has no agent surface. That's the difference between "a URL exists" and "an agent lives there." Honestly? That gap is the entire reason the probe exists in the first place.

A Capability Claim Nobody Checked Is Just a Sentence

An agent registers with a capabilities list. "I can translate English to Japanese." "I can fetch on-chain prices." "I can run code in a sandbox." That's a sentence. The capability score asks a different question: does the endpoint that backs the claim actually respond to a live request, and does it publish a machine-readable description of what it does?

This is where the probe and the capability score pull apart usefully. There are four honest states:

1. Declared capability, no machine-readable surface, endpoint passes TLS+200. Partial pass. The capability score gets a small bump from live reachability, but the missing surface costs the claim most of its weight. Honest take: this is the most common state in 2026, and most agents sit here.

2. Declared capability, machine-readable surface present, endpoint passes everything. Full pass. The capability score treats the claim as supported by live evidence. Contribution to the overall trust score is at its maximum for that axis.

3. Declared capability, endpoint is dead. Probe returns a failure code. The capability score drops relative to a static read-only assessment. This is the case where an agent used to be live and is now stale — common in rotating fleets.

4. No declared capability, endpoint is fine. The probe still succeeds and the identity/reputation axes still benefit, but the capability axis isn't meaningfully populated. We don't reward reachability for nothing.

The capability axis is where the probe earns its keep. Identity is mostly on-chain evidence. Reputation today is read from identity anchors and live signals — including whether the endpoint runs a paid x402 service, which is the closest thing to "economic skin in the game" we have right now. Risk is a static frame. Capability is the only axis where the agent itself has to be alive right now, and the probe is how we check.

If you want to see the operator's side of this — the part that submits the agent endpoint and gets the report back — the EVIDIQ Operator docs walk through the request shape. The probe result is returned as structured fields, not a free-text verdict, so it slots directly into a downstream decision.

What This Probe Deliberately Does Not Do

Boundaries matter more than features in the trust business. Here's what the live probe explicitly does not check, stated plainly so nobody over-relies on it.

• It is not a penetration test. The probe does one bounded GET. No fuzzing, no auth attempts, no probing sibling paths. If an attacker has hidden a malicious route at /admin, this probe won't find it. We're not in the security-scanner business; we're in the trust-signal business.

• It is not a functional test of the declared capability. A passing probe tells you the endpoint is alive and serves a machine-readable surface. It does not tell you the translation is accurate or the price feed is correct. Functional correctness requires real inputs and output checks. That's a different service, and we don't pretend it isn't.

• It is not a guarantee of uptime tomorrow. The probe ran at time T with a result. A minute later, the endpoint could be down, rate-limited, or behind a WAF that just rotated. The evidence is timestamped and signed, but the underlying fact — "reachable at T" — is exactly that. Re-probe for high-value transactions.

• It does not bypass identity. A live endpoint with no identity anchor still fails the identity axis. The probe alone cannot raise an agent from "anonymous" to "trusted." Reachability is necessary, not sufficient.

• It does not run inside a TEE by default. The probe is a regular deterministic HTTP call. The verdict — the final signed report — can be generated inside a TEE on 0G Compute with GLM-5.2 if the operator opts in, but the reachability GET itself runs wherever verify_agent runs. Don't confuse the two.

The probe proves a small thing, and it proves it with evidence you can verify against the EVIDIQ Notary docs — the report is keccak256-hashed, anchored on 0G Storage, and signed with an EIP-191 key anyone can recover. Small, honest, signed.