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

Yes. When using the A2A protocol to send tasks with multiple Part elements in a message (e.g., a TextPart for a query and a FilePart for an image), there is currently no standardized way to name or label these parts. This leads to ambiguity and requires agents to rely on the order of parts or use informal conventions via metadata to interpret inputs correctly.

This becomes especially problematic when:

• Multiple parts of the same type are sent (e.g., several TextParts),
• Agents are built to work with named parameters and some may have the same type (e.g., query: str, channel: str),
• Parts are dynamically generated or added in variable order,
• Developers want to build stricter contracts or validation logic for agent inputs.

While it is possible to include a name or similar identifier in the metadata field of each part, this approach lacks consistency and discoverability. Having a dedicated name field would make input handling clearer, easier to validate.

Without a naming mechanism, the protocol lacks a robust way to map inputs to their intended semantic meaning.

Describe the solution you'd like

I'd like to propose extending the Part model (e.g., TextPart, FilePart, etc.) to optionally include a name: str field.

This would allow each part to be explicitly labeled (e.g., name="query", name="invoice") and give agents a consistent and reliable way to reference expected inputs.

Example:

parts: [

   {
     "type": "text",
     "text": "What's the total from this invoice?",
     "name": "query"
   },
   {
     "type": "file",
     "file": {
          "mimeType": "application/pdf",
          "bytes": "<base64-encoded-content>",
     },
     "name": "invoice"
   }
]

This change would improve readability and debuggability, reduce reliance on ordering, enable stronger validation and agent design and be backward-compatible if name is made optional.

Describe alternatives you've considered

As mentioned above, part names can be added to metadata field, but this is inconsistent and not standardized. A dedicated name field would make input handling clearer and validation more straightforward.

Additional context

No response

Code of Conduct

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