What It Takes to Verify AI Agent Endpoint Reachability (And What It Doesn't)

You ship an agent. It advertises an endpoint. Someone — a paying customer, a marketplace, an orchestrator — has to decide whether to send it work. The deciding question sounds simple: "Can I reach it?" The honest answer is harder than a curl.

Here's the thing: a 200 OK and a working agent are not the same thing. A reachable domain name is not the same thing as an agent that can do the job. We built EVIDIQ's live endpoint reachability probe to narrow that gap, and we want to be exact about what it does and what it deliberately leaves to other tools. If you're evaluating an agent before handing it a task — or building tooling that does — this is the walkthrough.

Six Seconds to Learn Something Real

EVIDIQ's endpoint reachability probe is a bounded ~6-second GET request that tells a caller whether an agent's advertised endpoint actually exists, serves valid HTTPS, and exposes a recognizable skill, agent-card, or MCP surface. It is a deliberate, narrow check — not a penetration test — designed to back capability claims with at least one piece of live evidence.

Why six seconds? Because a probe is a tax on the agent you're verifying, and we run probes inside flows that call them constantly. Tighten the budget and you start dropping real agents behind slow CDNs and cold-start runtimes. Loosen it and you've turned a verification step into a denial-of-service vector against the very marketplace you're trying to make trustworthy. Six seconds is the compromise we found between "got an answer" and "didn't punish the agent for being slow to wake up."

Worth noting: the timeout isn't a limit on what we want to know. It's a constraint that forces the probe to stay honest. The moment you conflate endpoint reachability with functional correctness, the verdict stops being useful.

The Three Things One GET Request Reveals

[IMAGE_PROMPT: modern flat illustration showing a stylized magnifying glass hovering over a developer notebook screen, with three labeled beams emerging toward the glass — a green padlock (TLS), a 200 OK badge (HTTP), and a small JSON agent-card snippet — abstract blockchain-trust motifs in soft blue and teal, minimal background, no real brand logos, no in-image text]

A single bounded GET sounds undersized, but a lot of signal fits inside one request. The probe returns evidence for three distinct facts, and we report each one separately. Pass all three and the endpoint counts as "live"; partial passes are reported as partial passes.

1. TLS presence and certificate validity. We connect, complete the handshake, and confirm the certificate chain resolves to a trusted root. A self-signed cert on a private IP fails this check. A valid certificate proves the endpoint's operator controls the domain — it does not prove who that operator is, which is what the identity sub-score is for.

2. HTTP status within the timeout window. A 2xx is what we hope for; a 3xx redirect is followed up to a small hop count. A 401 or 403 is interesting — the endpoint exists, TLS works, but access is gated — that becomes a partial pass, not a hard fail. A 5xx or TCP-level timeout is the only thing that drops the endpoint into the unreachability bucket.

3. A body-content fingerprint scan. This is the part most people miss when they say "just curl it." Once we get a 2xx, we look at the response body for skill-shaped surfaces:

   • A machine-readable agent-card JSON object.
   • A skill manifest following MCP conventions.
   • An OpenAPI-style description served at a well-known path.
   • A clear textual pointer like "skill": "..." in raw HTML.

The fingerprint has to look deliberately served, not a homepage that happens to mention "agent." A parsed, structured manifest counts far above a stray keyword.

What does a pass look like? TLS green, a 200, a parsed JSON object claiming at least one capability that matches what the agent advertised. What does a fail look like? TLS green, a 200, and a generic marketing page saying "AI for business." That endpoint is reachable. It is also useless for our purposes, and the report says so in plain English alongside the score.

For the full data model behind each probe response, see the EVIDIQ Sentinel docs — the live probe is one of Sentinel's primary signals and the docs go deeper into the response schema.

A Capability Claim Nobody Checked Is Just a Sentence

An agent says it can translate English to Mandarin. The capability is declared in its manifest. What does the probe make of that?

If the endpoint is reachable and its served skill manifest names translation as a capability, the capability sub-score climbs. If the endpoint is reachable but the manifest names something different — code generation, with no translation anywhere — we treat the declared translation as unsubstantiated. The endpoint works; the claim doesn't match. That mismatch is the worst kind of partial truth in agent marketplaces, and the capability sub-score, which sits at 0-100 and contributes 30% of the overall trust score, reflects it accordingly.

The math is simple: an unbacked capability claim moves the number, but not by enough to make the agent trustworthy on its own. We weight identity (a verifiable EVM address, an ERC-8004 identity id, an ENS name, or a TLS-served domain) and reputation (live economic skin-in-the-game signals from a paid x402 surface) into the same formula, so no single sub-score carries the verdict. For the exact weighting — identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2 — see the EVIDIQ docs.

Honestly? Most agents that fail this step aren't malicious. They made a copy-paste mistake on their agent card and never noticed. We prefer to surface that as a low capability score than to fail the entire trust check, because the rest of the signal (identity, reputation, risk) is usually still meaningful and deserves to count for something.

What This Probe Deliberately Does Not Do

[IMAGE_PROMPT: clean diagram-style illustration of a magnifying glass examining a server endpoint, with four soft red 'X' marks drawn over labeled zones reading 'penetration test', 'functional test', 'uptime guarantee', 'reputation ledger', modern flat design in muted coral and slate gray palette, generous whitespace, developer-aesthetic, no real brand logos, no in-image text]

Boundaries matter more than features for a tool you might rely on to vet an agent. Here is what the live endpoint reachability probe explicitly does not do:

• It is not a penetration test. No payload fuzzing, no SQL injection probes, no privilege escalation attempts. If you need security auditing, run a real audit.
• It is not a functional test of the declared capability. A translation agent returning a 200 and an MCP manifest is not proven to translate correctly. We measure reachability and surface consistency — not output quality. That belongs to evaluation harnesses and downstream test suites.
• It is not a guarantee of uptime tomorrow. Reachability is a point-in-time observation. The endpoint could be down an hour later, or wrapped in a flaky load balancer. Pair EVIDIQ's verdict with your own liveness checks before letting a high-value transaction rely on it.
• It is not a full reputation ledger. The reputation sub-score today is built from identity anchors and live economic signals (does the endpoint run a paid x402 service?). A complete on-chain reputation registry with automated dispute resolution is on our roadmap, but it is not shipped — don't confuse a live economic-skin signal with a years-long track record we haven't aggregated yet.

We surface these limits inside the report itself, in the same JSON object that carries the score, so they don't get lost between the verdict and the call you're about to make. If you want a deeper dive into how the trust report is notarized (keccak256 hash, 0G Storage anchor, EIP-191 signature) so you can verify any verdict yourself, the EVIDIQ Notary docs cover the full pipeline. If you want to operate EVIDIQ — running your own probes, configuring policies, integrating with x402 — the EVIDIQ Operator docs are the starting point.