Spec Proposal: Dependencies manifest

[marianogonzalez]

NOTE:

This issue was originally posted on the ards-project repo, issue #42. Moving here for visibility. Please refer to the original issue for already existing community feedback and comments.

The original issue has also been referenced in other proposals:

ards-project/ard-spec#53
ards-project/ard-spec#55
ards-project/ard-spec#57

The Problem:

Agents often depend on other assets like agents, MCP servers, etc.

Sometimes agents act on their own behalf, using their own identity. But sometimes they do it on behalf of the client, propagating
user credentials along the stack (e.g: the auth-required flow in A2A).

Example implementation of different identity strategies for agents

If the purpose is enabling agents to discover and use assets at runtime, then agents need to determine upfront which additional credentials
will be required downstream, so that the agent (or the client) can validate if that asset is really an option regardless of the
offered capabilities.

Proposal:

Enrich the entry with optional information about downstream dependencies so that the agent planner can identify additional system for which access are required. In this way, the agent can avoid failures due to lack of access.

Example:

{
  "identifier": "urn:ai:acme.com:sales:crm-assistant",
  "capabilities": ["lead_search", "opportunity_update", "forecast_generation"],
  "dependencies": {
    "required": [
      {
        "type": "application/mcp-server+json",
        "identifier": "urn:ai:salesforce.com:mcp:sales-cloud",
        "minVersion": "3.0.0",
        "identityType": "OBO",
        "purpose": "Access Salesforce data"
      }
    ],
    "optional": [
      {
        "type": "application/a2a-agent-card+json",
        "identifier": "urn:ai:acme.com:email:sender",
        "identityType": "agent",
        "purpose": "Send email notifications"
      }
    ]
  }
}

Discovery Value:

• Pre-flight checks: "Can I use this agent?" (Do I have required credentials?)
• Security planning: Understand data access scope before deployment
• Compliance: Know audit trail model (user-attributed vs agent-attributed)
• Filter discovery: Hide agents requiring credentials I don't have
• "bundle" discovery: agent + all required components
• Filter unapproved vendors: e.g: don't book flights through Expedia because there's an active lawsuit
• Impact analysis: "what agents break if I decommission MCP server X?"

While this could be treated as vendor specific additional metadata, lack of standardization on this concept would make cross-platform, cross-vendor governance more difficult than it should be