Skip to main content
Glama
nexus-mcp-infra

agent-verification-api

Agent Verification API

Confirms that an AI agent/service is who it claims to be. NEXUS candidate #3 -- manual build, not FORGE-generated, extending the domain-verification engine already live in production on live-entity-verification (Railway, free -- see below) with two new agent-specific signals.

  • POST /verify-agent-identity {"domain": "...", "entity_name": "...", "agent_endpoint_url": "..." (optional)} -- charged $0.35 via x402 (Base Sepolia testnet).

  • MCP tool verify_agent_identity at /mcp -- currently free, see "Known limitations".

  • GET /health, GET /.well-known/agent-card.json, GET /openapi.json (has x-payment-info).

What it actually checks

Fuses two independent lenses into one verdict:

  1. Domain existence (the live-entity-verification engine, ported unchanged -- WHOIS + Certificate Transparency + Wayback Machine + DNS operational maturity, fused with the same calibrated Bayesian priors).

  2. Agent liveness (new, only runs if agent_endpoint_url is given): a real GET of {agent_endpoint_url}/.well-known/agent-card.json, and a real MCP initialize handshake at {agent_endpoint_url}/mcp -- not just an HTTP 200 check. Also verifies the agent-card's own declared url is bound to domain (catches an agent card hosted somewhere unrelated to the entity it claims to represent).

Verdicts, most-trusted first: VERIFIED_LIVE_AGENT, VERIFIED_LIVE_DOMAIN_ONLY (no agent_endpoint_url given), DOMAIN_VERIFIED_AGENT_UNREACHABLE, AGENT_DOMAIN_MISMATCH, LIKELY_HALLUCINATED_AGENT, UNVERIFIED_AGENT. Full semantics in the endpoint's own docstring / OpenAPI description.

Why $0.35 (vs $0.01 for the sibling url-metadata-api)

Real cost per call is meaningfully higher: paid WHOIS lookup (~$0.002/call via Whoxy) plus 5-6 real outbound checks (WHOIS, CT, Wayback, DNS, agent-card fetch, MCP handshake) instead of one fetch. $0.35 is the midpoint of the $0.30-0.50 range for identity-verification-class services in the x402 ecosystem.

Relationship to live-entity-verification

live-entity-verification (Railway, live-entity-verification-production.up.railway.app, free, no x402, asset_registry.status='active' since 2026-08-20) is a separate, still-live asset -- this candidate reuses its domain-verification code (ported into main.py here, not imported cross-service) but does not replace or modify it. Don't touch that Railway service as part of work on this one without checking both.

Deploy target: Cloud Run, not Railway

Same pipeline as candidate #4 (url-metadata-api) -- see skills/infra-deploy-ops.

# 1. First deploy -- PUBLIC_DOMAIN not known yet, every real request 421s until step 2.
./scripts/deploy_cloud_run.sh agent-verification-api manual_assets/agent-verification-api

# 2. Grab the printed *.run.app URL, then (only if it differs from env-vars.deploy.yaml's guess):
gcloud run services update agent-verification-api --region us-central1 --project nexus-505016 \
    --update-env-vars PUBLIC_DOMAIN=<the-real-domain>

No numpy/scipy dependency (removed after the first deploy attempt failed Cloud Buildpacks' Python-3.14 scipy source build, which needs a Fortran compiler not present in the build image -- _fuse_signals_naive_bayes/ _compute_evidence_quality use plain math.log/math.exp/a small _clip helper instead; the one expit import from the original engine was actually unused dead code, dropped).

Known limitations (left unfixed on purpose -- CLAUDE.md SS3, no gate without evidence it's needed)

  • MCP tool calls are not charged. Same in-process-call pattern (and same reason) as url-metadata-api: the MCP tool calls the shared verification function directly, not via HTTP re-entry into the ASGI app.

  • No per-caller rate limiting. Fine for a 7-day disposable measurement; add if it survives.

  • SSRF guard on agent_endpoint_url: IP-range based pre-connect check (rejects private/loopback/ link-local/reserved, including cloud metadata's 169.254.169.254). The agent-card fetch uses follow_redirects=False. The MCP handshake uses a custom httpx_client_factory that also disables redirects (the MCP client library's own default factory hardcodes follow_redirects=True with no opt-out via the public streamablehttp_client signature -- found in this candidate's pre-deploy security review: a malicious server could otherwise pass the pre-connect check, then 307-redirect the actual MCP request to an internal target). Neither guard defends against DNS rebinding between the check and the actual connect (accepted risk, same as candidate #4).

  • name_matches_card is informational only, not verdict-gating -- self-reported agent names vary in formatting often enough that a hard mismatch gate would produce false negatives on real agents.

Pre-deploy quality gate (2026-08-22, from design not retroactive)

4 parallel review lenses ran against main.py before the first deploy. Real findings, all fixed before shipping:

  • Security (critical): the MCP-handshake SSRF guard was bypassed by the mcp library's hardcoded follow_redirects=True default -- fixed via a custom httpx_client_factory.

  • Functional (critical): the ported DNS-maturity engine silently dropped 2 of 6 scoring components (DKIM, cross-resolver propagation consistency) despite the module docstring claiming an unchanged port -- restored, and parallelized (was sequential, up to ~48s worst-case per call).

  • Functional: _classify_agent_verdict's reachability check used OR between agent-card-present and MCP-handshake-reachable, letting a dead MCP server with a stale-but-present agent-card pass as VERIFIED_LIVE_AGENT -- the exact "vaporware" case this asset exists to catch. Fixed to require the handshake specifically for the top verdict.

  • Code quality: dead function, unused signal_mask threading, a dropped explanatory comment -- all cleaned up.

  • Buyer experience: the REST response was undocumented in OpenAPI (response_model added), the 6-value verdict enum had no semantic explanation anywhere reachable pre-payment (added to the endpoint docstring), and the fact that a 400/422 is still charged (ASGI middleware settles before FastAPI validation runs) was underdisclosed (added to agent-card.json's protocol_note and the endpoint docstring).

Measurement (candidate #3, 7-day window)

7-day window from first real deploy (2026-08-22 -> decision point 2026-08-29). Source of truth: traffic_events/revenue_events/mcp_call_events tables (asset_name = 'agent-verification-api'), not Cloud Run logs. First real call already confirmed same-session: real x402 payment settled on-chain, real revenue_events row (amount_eur=0.35, pricing_model=x402), verified against the live url-metadata-api Cloud Run service as the test agent (agent-card fetched, real MCP handshake succeeded, domain-binding confirmed). Day 7: if zero real traffic (filtering crawlers), pause/delete the Cloud Run service (gcloud run services delete agent-verification-api --region us-central1 --project nexus-505016).

-
license - not tested
Not graded
quality - not tested
B
maintenance

Maintenance

Maintainers
Response time
Release cycle
Releases (12mo)
Commit activity

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

  • Verify x402 payment endpoints before an AI agent pays: scam scan, on-chain checks, trust scores.

  • Reputation oracle for AI agents on Base: SAFE/CAUTION/BLOCK + 0-100 score before you pay. x402+MCP

  • Agent x402 Paywall MCP — Coinbase HTTP 402 protocol + on-chain settlement. Agents pay per-call

View all MCP Connectors

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nexus-mcp-infra/agent-verification-api'

If you have feedback or need assistance with the MCP directory API, please join our Discord server