Is your feature request related to a problem? Please describe.

In real-world deployments of A2A (embedded client systems), it’s not enough for a client to simply discover an agent endpoint. Clients also need to know whether their current environment actually supports that agent before initiating calls.

For example, an agent might only function if:

• A minimum firmware/software version is installed on the client device
• Certain hardware features (GPS, microphone arrays, BLE chipsets) are present
• A companion app or service is installed and running
• The user has enabled certain settings
• The agent is available in a specific region

Currently, the A2A spec provides no standard way for agents to communicate such eligibility requirements to clients.

This leads to several problems:

• Clients may attempt to invoke agents they can’t actually use, resulting in failed requests or degraded UX.
• Clients must hardcode knowledge about agent prerequisites, reducing interoperability and increasing maintenance burden.

Describe the solution you'd like

The A2A message object and task object already provide a metadata field for extensibility. It would be consistent and powerful if the Agent Card also explicitly supported a metadata field, allowing agents to advertise additional information such as:

• Required firmware/software versions
• Required hardware specs
• Required app installations
• Settings enablement
• Region availability

Example:

"metadata": {
  "requirements": {
    "min_firmware_version": "2.3.0",
    "required_hardware_features": ["BLE", "MicrophoneArray"],
    "required_apps": ["com.example.controllerapp"]
  }
}

Dependencies and organizational information can be modelled the same way.

I am proposing to only specify the metadata field in the Agent Card (as opposed to specifying further fields within it) and leaving the exact downstream usage to the Agent owner.

Describe alternatives you've considered

Alternatively, the metadata (like environment requirements, dependencies, organizational information) can be modelled by an Agent Registry - moving the responsibility out of the A2A protocol. The disadvantage of that is that it would require the use of an Agent Registry in the first place, and currently Agent Registries are not standardized.

Additional context

I am curious to hear about other opinions and solutions :)

Code of Conduct

• I agree to follow this project's Code of Conduct