Your agent is about to call another agent. It has an address, a manifest, a list of "capabilities" the other side swears it has. Now what? You could send the request blind and hope for the best, or you could spend six seconds learning something real first.
To verify AI agent endpoint reachability consistently, follow a small preflight:
- Submit the declared HTTPS endpoint and capabilities to the verification call.
- Review TLS, status, and machine-readable-surface evidence before treating the peer as reachable.
- Verify AI agent endpoint reachability again before a material or state-changing payment.
That's literally the budget EVIDIQ gives to a live probe — six seconds, bounded, deterministic — and it produces more useful signal than most "trust" systems in this space. Here's what we built it to do, and just as importantly, what it deliberately doesn't promise.
Six Seconds to Learn Something Real
An endpoint reachability probe is a bounded ~6-second HTTPS GET that checks three things: TLS validity, HTTP status, and whether the response body contains a machine-readable fingerprint like an Agent Skill file, agent card, or MCP manifest. It feeds into the capability and risk dimensions of the EVIDIQ trust score and runs every time verify_agent is called.
The 6-second timeout is a deliberate engineering constraint, not an apology. It's long enough to ride out a slow TLS handshake or a transient cold start on a serverless function. It's short enough that you can run it on every meaningful transaction without burning the budget of the calling agent, and without a slow peer agent becoming your problem.
Why six seconds? Honest answer: we tried longer and the tail latency killed the developer experience. Ten seconds felt polite. Eight felt fine. Six felt honest — the line where "slow" becomes "probably down" stops mattering. Below six, you're just timing out things that are working. Why a GET? Because GETs don't mutate state, don't need auth headers in most cases, and let us observe the same surface a peer agent would observe. A POST would be cleaner for some checks, but it would also mean the probe itself can change the world, and that's a non-starter.
The probe runs as part of EVIDIQ's verify_agent tool, which is the paid per-call endpoint exposed via the EVIDIQ MCP server. The full report weighs identity, capability, reputation, and risk together into a single 0–100 trust score with an explicit recommendation: proceed, proceed_with_escrow, caution, or do_not_proceed. But the probe is the only piece of that report that's live — everything else is either a static claim, an on-chain anchor, or a derived signal. The probe is the part that proves the lights are actually on at the URL the agent gave us.
The Three Things One GET Request Reveals
We get one shot, one request, one body. Here's what we read out of it.
1. TLS presence and validity. A pass looks like a valid certificate chain, a hostname that matches, and a handshake that completes inside our timeout. A fail is anything else: cert expired, hostname mismatch, handshake hangs, or a connection that never upgrades to TLS at all. In 2026, TLS is the floor — if you can't serve HTTPS, you don't get to talk to other agents without raising a flag. We treat any TLS failure as an automatic hit on the risk dimension, and a complete absence of TLS as grounds for a do_not_proceed recommendation on its own.
2. HTTP status. A pass is a 2xx response. A 3xx is interesting but not necessarily fatal — we follow one redirect hop if the Location header points at a sane target with a matching hostname. 4xx and 5xx are both fails, but we record them differently in the risk dimension. A 401 is "you're allowed to ask but need credentials," which is fine for a paid service that's been configured to require x402 payment. A 503 is "this thing is down right now," which is a different conversation — recoverable, but it pulls the score down until the next probe.
3. Body-content fingerprint scan. This is the one most people don't expect. We look at the response body and search for fingerprints of machine-readable surfaces. A pass looks like at least one of these landing:
- A markdown heading plus a recognizable
name:/description:block matching the Agent Skill convention used atevidiq.dev/skill.md - A JSON agent card with a
skillsorcapabilitiesarray - A
/.well-known/agent.jsonor MCP manifest at a known path - A pointer header like
X-Agent-Cardreferencing one of the above
A fail is a stock 404 page, a marketing splash, a Cloudflare challenge page, or — most interesting — a body that looks like an agent card but lists capabilities the agent never declared to us. Mismatches between declared and served capabilities are the single most common "soft fail" we see, and they hit the trust score harder than a 503 does, because a 503 is honest about being broken, while a mismatch is dishonest about what it is.
Worth noting: the fingerprint scan is heuristic. We don't parse the body with a full grammar; we look for structural markers. That's a trade-off — it costs us some precision in exchange for staying under the timeout. The full EVIDIQ docs cover the matcher rules in detail.
A Capability Claim Nobody Checked Is Just a Sentence
Here's the part we think about a lot. When an agent says "I can translate English to Japanese," that sentence is free. It costs the agent nothing to put it in a manifest. It costs you, the caller, real money to find out it's a lie — and worse, it can poison a workflow if the bad response is fed downstream before anyone notices.
EVIDIQ's capability score is the dimension that suffers most from unchecked claims, and the probe is what flips it from "trust the sentence" to "trust the endpoint." A claimed capability that the probe cannot corroborate in any way — no matching skill file, no agent card, no MCP surface — drops the capability score materially. A claimed capability backed by a live endpoint that serves a coherent skill file with consistent metadata moves the capability score up. A claimed capability that the endpoint contradicts (declares something different than the manifest) drops the score further than silence would.
The math is simple. Two agents, same identity, same reputation, same risk — but one has a probe result and one doesn't. The one with a passing probe is the one you'd hand a transaction to. The capability dimension is weighted at 0.3 in the final score, and a passing probe can move it by 15–20 points. That's the difference between a "caution" recommendation and a "proceed" recommendation in real cases we've run on the EVIDIQ playground, all from a single 6-second pass to verify AI agent endpoint reachability.
We're not running the translation. We're not even calling the translation endpoint. We're confirming that the agent is a real, reachable, machine-readable thing that has bothered to publish what it does. That's a weaker claim than "we tested your translation" — but it's a stronger claim than "we read your business card." And in 2026, when most agents are still publishing nothing, even the weaker claim is enough to break ties in the calling agent's decision.
What This Probe Deliberately Does Not Do
Boundaries matter, so let me be specific. The probe is a useful primitive, but it's not a security audit and it's not a quality certification. Here's the line we draw on purpose.
- It is not a penetration test. We are not fuzzing inputs, not probing for SQLi, not checking for SSRF, not looking for path traversal. That's not what this is for.
- It is not a functional test of the declared capability. We do not call your translation endpoint with "hello" and check whether the response is "こんにちは." We confirm the surface exists; we don't exercise it.
- It is not a guarantee of uptime tomorrow. The probe result is a snapshot. The endpoint could pass at 14:00:03 and be down at 14:00:07. We don't simulate a future, and we don't model the operator.
- It is not a benchmark. We don't measure throughput, latency under load, or cost-per-call. The 6-second timeout is a ceiling on our patience, not a measurement of their speed.
- It is not a reputation signal on its own. The probe contributes to the capability and risk dimensions. Reputation today is anchored in identity and economic-skin-in-the-game signals (e.g. does the endpoint operate as a paid x402 service), not in probe history. We're not pretending a single good probe is a long-term record.
The honest version: the probe raises the floor of what you can know about an agent before transacting with it. It does not raise the ceiling. If you need a deeper signal — actual functional testing, dispute resolution, regulatory review — that's a different system, and in 2026 most of it doesn't exist in a packaged form yet. The EVIDIQ Notary docs cover how the probe result combines with on-chain evidence anchoring to produce a tamper-evident report — and even that report is a recommendation, not a contract.
We'd rather under-promise here than have someone skip a step they should have taken. A do_not_proceed from EVIDIQ is a reason to dig in, not a reason to walk away forever. A proceed is a reason to proceed, not a reason to skip your own diligence. The probe earns you information; it doesn't replace judgment.