AdCP 3.1.13 · Protocol

get_adcp_capabilities

get_adcp_capabilities request fields

The required column reflects the top-level required array only. The request schema declares no required array, so none of the 5 request fields carries a top-level required flag. A top-level if, anyOf, oneOf or dependencies block can make an unmarked field mandatory in the mode being called, and a flat table cannot render a rule that fires in one mode only. Those branches are visible in the request schema itself.

get_adcp_capabilities reads. 30 of the 64 registered operations are flagged x-mutates-state and its request schema is not one of them, so repeating the call is side-effect free. AdCP's release notes describe x-mutates-state as a non-normative tooling hint that agents do not validate, so it is the registry's classification of the operation rather than a contract, and it is the only machine-readable answer in the registry to whether an operation is safe to retry.

get_adcp_capabilities response fields

The first 13 rows are the shared protocol envelope from core/version-envelope.json and core/protocol-envelope.json. Only 22 of the 35 rows below belong to get_adcp_capabilities itself, beginning with adcp, supported_protocols and account. 3 fields in the whole response are marked required: status, adcp, supported_protocols.

The shared protocol envelope

62 of AdCP's 64 registered operations carry every one of the 13 envelope fields. report_plan_outcome and check_governance compose core/version-envelope.json only, so they carry the version pair and none of the task fields.

status resolves to enums/task-status.json, which admits nine values: submitted, working, input-required, completed, canceled, failed, rejected, auth-required, unknown. The envelope marks it required on every response, and a synchronous call emits completed rather than omitting it. When it returns submitted or working instead, task_id is the polling handle and push_notification_config is the webhook the agent echoes back to confirm the callback. Webhooks are A2A and REST only: MCP sends progress notifications and defines no webhook.

payload appears in the response field table typed object. core/protocol-envelope.json describes it as a documentary construct and states that it is not a required wire field. Body fields are siblings of the envelope fields: on MCP at the root of the tool response, on A2A in task.artifacts[0].parts[].DataPart, on REST at the root of the JSON body. An accessor that reads response.payload finds nothing there.

Field lists are not published over the wire

AdCP's integration guide, docs/protocol/calling-an-agent.mdx, states that its MCP servers no longer publish per-tool parameter schemas: a tools/list call returns an empty properties object for every tool, and the guide directs clients not to infer shape from it. A client author reads the schema registry instead of the tool list.

Example get_adcp_capabilities calls

The field tables above come from the 3.1.13 schema release and these blocks come from the documentation tree, which is versioned separately, so the two can disagree.

{
  "adcp": {
    "major_versions": [3],
    "idempotency": { "supported": true, "replay_ttl_seconds": 86400 }
  }
}

{
  "adcp": {
    "major_versions": [3],
    "idempotency": { "supported": false }
  }
}

{
  "adcp": {
    "major_versions": [3],
    "idempotency": { "supported": true, "replay_ttl_seconds": 86400 },
    "capability_changes": {
      "capabilities_version": "rev_20260702_091455",
      "last_modified": "2026-07-02T09:14:55Z",
      "cache_ttl_seconds": 3600,
      "notifications": {
        "supported": true,
        "registration_task": "sync_agent_notification_configs",
        "event_types": ["capabilities.changed"],
        "coalescence_window_seconds": 300
      }
    }
  }
}

Other operations in Protocol

• get_task_status
• list_tasks

Related

• The full Protocol reference
• All 64 entries in the AdCP 3.1.13 registry
• Does AAMP have an equivalent operation?