generated: '2026-09-03'
method: probed
source: https://api.leadping.ai/.well-known/agent-card.json
card:
  file: a2a/leadping-agent-card.json
discovery:
  path: /.well-known/agent-card.json
  canonical: true
  host: api.leadping.ai
  note: 'The card is served from the API host, not the apex. leadping.ai was probed on the same day and 404s both /.well-known/agent-card.json and /.well-known/agent.json ("Static asset not found."), and api.leadping.ai 404s the legacy /.well-known/agent.json — api.leadping.ai/.well-known/agent-card.json is the only agent card Leadping serves. Ownership is not in question: api.leadping.ai is the same host that serves Leadping''s OpenAPI (servers[] https://api.leadping.ai) and MCP endpoint, the card''s provider.organization is "Leadping" with provider.url https://leadping.ai, and Leadping''s own llms.txt names this exact URL as "A2A Agent Card".'
  previously: 'The 2026-08-18 enrichment round recorded NO agent card. At that time leadping.ai answered 200 with the SPA HTML shell for every /.well-known/* path (a false positive the round correctly rejected) and api.leadping.ai returned 404 for agent-card.json. Both facts changed: leadping.ai now returns a real 404, and api.leadping.ai now serves a real card. This is a new provider surface, not a correction of a missed probe.'
x-evidence:
  fetched: '2026-09-03'
  url: https://api.leadping.ai/.well-known/agent-card.json
  http_status: 200
  content_type: application/json; charset=utf-8
  body_bytes: 1505
  body_parses_as: JSON object with AgentCard shape
  corroborating_probes:
  - url: https://leadping.ai/.well-known/agent-card.json
    http_status: 404
  - url: https://leadping.ai/.well-known/agent.json
    http_status: 404
  - url: https://api.leadping.ai/.well-known/agent.json
    http_status: 404
  - url: https://api.leadping.ai/a2a
    http_status: 405
    note: GET on the declared A2A interface returns 405 Method Not Allowed with an empty body — the endpoint exists and expects the JSONRPC POST the card declares. It is a callable agent surface, not a documentation page.
  - url: https://leadping.ai/.well-known/ai-catalog.json
    http_status: 200
    note: Leadping's ARD/AI capability catalog independently lists the card as urn:air:leadping.ai:agent:lead-research with type application/a2a-agent-card+json.
agent_card:
  name: Leadping
  description: Researches and summarizes leads for an authenticated Leadping organization.
  version: 1.0.0
  documentation_url: https://leadping.ai/docs/api-reference
  provider:
    organization: Leadping
    url: https://leadping.ai
  supported_interfaces:
  - url: https://api.leadping.ai/a2a
    protocol_binding: JSONRPC
    protocol_version: '1.0'
  capabilities:
    streaming: true
    push_notifications: false
    extended_agent_card: false
    extensions: null
  default_input_modes:
  - text/plain
  - application/json
  default_output_modes:
  - text/plain
  - application/vnd.leadping.lead-research+json
  security_schemes:
    leadpingBearer:
      type: httpAuthSecurityScheme
      scheme: bearer
      bearer_format: JWT
      description: A Leadping access token with the leads:read permission.
  skill_count: 1
  skills:
  - id: lead-research
    name: Lead research
    description: Returns an organization-scoped lead snapshot with conversations and recent activity. This skill is read-only.
    tags:
    - lead
    - crm
    - research
    - read-only
    input_modes:
    - text/plain
    - application/json
    output_modes:
    - text/plain
    - application/vnd.leadping.lead-research+json
    security_requirements:
    - leadpingBearer
conformance:
  spec: A2A 1.0.0
  grade: conformant
  protocol_version: '1.0'
  preferred_transport: null
  transport: JSONRPC (via supportedInterfaces[0].protocolBinding)
  hard_checks:
    capabilities_is_object: true
    protocol_version_present: true
    skills_is_array: true
  optional_fields:
    default_input_modes: true
    default_output_modes: true
    preferred_transport: false
  grade_basis: 'Graded against the A2A 1.0.0 hard checks. capabilities is an OBJECT (pass) — streaming, pushNotifications, extensions and extendedAgentCard are declared as fields, not as a bare array or string. protocolVersion is present (pass), declared as "1.0" on supportedInterfaces[0], which is where A2A 1.0.0 carries it after supportedInterfaces[] replaced the 0.3-era top-level url/preferredTransport/protocolVersion triple. skills is an ARRAY (pass) with one fully-populated skill carrying id, name, description, tags, inputModes, outputModes and per-skill securityRequirements. Both optional discriminators that usually separate conformant from near-conformant are present: defaultInputModes and defaultOutputModes are each declared. preferredTransport is absent because A2A 1.0.0 superseded it with supportedInterfaces[].protocolBinding, which the card does declare (JSONRPC) — its absence is spec-current, not a gap.'
  deviations:
  - field: protocolVersion
    observed: carried on supportedInterfaces[0], not at the top level
    note: 'A reader written against A2A 0.3.0 — which required a top-level protocolVersion — will find none and may misread the card as version-less. This is recorded because the two card shapes coexist in the wild, not because Leadping is out of spec: the card is consistently 1.0-shaped throughout (supportedInterfaces, protocolBinding, the oneof-wrapped securitySchemes).'
  - field: securitySchemes.leadpingBearer
    observed: oneof-style wrapper object with apiKeySecurityScheme, httpAuthSecurityScheme, oauth2SecurityScheme, openIdConnectSecurityScheme and mtlsSecurityScheme keys, four of them null
    note: This is the A2A 1.0.0 protobuf-JSON oneof mapping rather than the flat OpenAPI-style securityScheme object. A naive reader looking for scheme/type at the top of the object finds nulls. Only httpAuthSecurityScheme is populated (bearer / JWT).
  - field: skills[].securityRequirements[].schemes.leadpingBearer.list
    observed: empty array
    note: The scheme is named but no scope list is attached, so the card itself does not state which permission the skill needs. The scheme's own description does — "A Leadping access token with the leads:read permission" — but that is prose inside a description, not a machine-readable scope, so an agent cannot programmatically determine the required grant.
  - field: iconUrl / extensions / signatures
    observed: explicit null
    note: Written as null rather than omitted. Harmless, but the card carries no JWS signature block, so its authenticity rests entirely on TLS to api.leadping.ai.
  - field: skills
    observed: one skill (lead-research), read-only
    note: Leadping's REST contract exposes 144 operations and its authenticated MCP server exposes organization tools, but the A2A surface is deliberately narrow and read-only. The agent card is not a projection of the whole API — an agent that reads only this card sees one research skill, not the messaging, calling, suppression or automation surface.
surface_relationship:
  note: 'Leadping now publishes three distinct agent surfaces that are NOT projections of one another, and the A2A card is the narrowest of the three. A2A: one read-only lead-research skill at https://api.leadping.ai/a2a. MCP: two remote servers — anonymous docs search at https://leadping.ai/docs/mcp and authenticated organization tools at https://api.leadping.ai/mcp (see mcp/leadping-mcp.yml). REST: 144 operations at https://api.leadping.ai. The REST contract also exposes the card itself as operations A2A_GetAgentCard and A2A_HandleRequest, so the A2A endpoint is a first-class part of the published OpenAPI rather than a side surface.'