A2A · INTERACTIVE DISCOVERY

Agent Card discovery: access and validation

Follow the request, inspect the card, and see exactly why discovery succeeds or stops.

Discovery desk · five attempts, one clientCLIENT
ClientFind an agentHTTP cachemax-age + ETagAgent Card endpointGET agent-card.jsonValidateJSON + HTTPSMatch capabilityStreaming required?DecisionReady / rejected No cached card
HTTP requests0
Fresh cache hits0
Ready0
Rejected0

Try this experiment

Protect the card endpoint, add credentials, then make the advertised interface insecure. Explain why authentication and card validation are separate checks.

  1. Play the healthy sequence. Follow the blue request marker.
  2. Change one input; the preview and sequence recalculate immediately.
  3. Use Next event or scrub the timeline to inspect the branch.
  4. Capture a baseline and record what changed.

Discovery trace

    Offline teaching model, not a live benchmark or complete A2A implementation. Five sequential attempts; fixed round-trip time; a modeled 1,200-byte card; no retries or task execution. Validation represents JSON parsing, a client HTTPS policy and one capability check—not full schema or signature verification. Credentials are simulated booleans; never enter real secrets. Discovery of a card does not authenticate subsequent task calls. Official discovery and caching reference.

    Two independent rejection gates

    Choose the protected endpoint and leave discovery credentials off. All five attempts are rejected before a usable card is obtained. Enable credentials and inspect the ready decisions. Now choose Non-HTTPS advertised interface: having credentials does not rescue a card rejected by the separate client interface policy. Try Malformed JSON as a third boundary. Invalid cards are not cached, so a long max-age does not turn these failed responses into accepted discoveries.

    Choose the request and cache policy

    Discovery interval sets the intended spacing of five attempts. Requests are sequential, so an attempt waits if earlier work is still running. Network round trip adds fixed modeled delay only when the cache cannot supply a fresh card. Cache max-age controls how long a validated response remains fresh; zero forces revalidation, while a long lifetime can hide a newly published version. Endpoint / card condition chooses a missing or unavailable endpoint, required authentication, invalid JSON, an insecure advertised interface, or a healthy response. Supply discovery credentials affects only the protected endpoint and is disabled otherwise. It represents a boolean, not a secret input.

    Separate suitability from discovery

    Client requires streaming expresses a local requirement. Card advertises streaming is the agent fixture capability; a syntactically valid card can still fail the match. Publish card v2 at model time 12s changes the server version but does not invalidate a still-fresh client cache. Watch network requests, cache hits, conditional 304 responses, ready decisions and rejected attempts separately. A 304 response refreshes the cached version without another modeled card body; it still required a network request.

    Inspect rather than infer

    Restore defaults resets the policy controls. Restart rewinds the current experiment, Play and Pause control the moving request, Next event jumps to the next actual decision, Speed changes playback, and Inspect any moment seeks in model time. The preview summarizes the complete five-attempt plan; the live counters describe only the events reached so far. Neither is a measured production availability rate. The HTTPS check is a client teaching policy; this simulation does not verify certificates, signatures or a full Agent Card schema.

    Views are my own and do not represent any employer, past or present.