Agent Capabilities Discovery Proposal
Summary
Problem Statement
AG-UI integrations (Mastra, LangGraph, CrewAI, etc.) each support different features — tools, streaming, structured output, reasoning, multi-agent coordination, and more. Currently there is no way for a client to discover what an agent supports at runtime. Clients must guess, hardcode assumptions, or consult external documentation.Motivation
Add a standardized capability discovery mechanism to AG-UI so that clients can query any agent for a typed, categorized snapshot of its current capabilities. This enables adaptive UIs, smart feature gating, and better developer experience when working across different agent integrations.Status
- Status: Draft
- Author(s): AG-UI Team
Overview
This proposal introduces:- An optional
getCapabilities()method onAbstractAgent - A typed
AgentCapabilitiesinterface with standardized categories - A convention for
HttpAgentto discover remote agent capabilities - An extensibility mechanism via
customfor integration-specific features
Design Principles
- Discovery only — the agent declares what it can do, no negotiation
- Dynamic — returns a live snapshot (add tools, next call reflects them)
- Optional — agents that don’t implement it return
undefined - Absent = unknown — only declare what you support, omitted fields mean not declared
- Typed categories + escape hatch — standardized categories with full
TypeScript types, plus
customfor anything else
Research
Capability patterns were analyzed across 8 frameworks and 2 protocols:| Framework/Protocol | Capability Pattern | Discovery |
|---|---|---|
| OpenAI Responses API | Per-request parameters | None |
| Anthropic Messages API | Per-request params + beta headers | Opt-in via headers |
| LangGraph | Graph definition + configurable fields | None |
| Mastra | Constructor params + dynamic arguments | None |
| CrewAI | Static constructor params | None |
| AutoGen | Constructor + capability registration | Runtime registration |
| Vercel AI SDK | Constructor + per-call overrides | None |
| Google ADK | Constructor + agent hierarchy | None |
| A2A Protocol | AgentCard at /.well-known/agent.json | Static JSON discovery |
| MCP | Bidirectional init handshake | Full negotiation |
- MCP is the only protocol with true bidirectional capability negotiation
- A2A has the best self-description model (discoverable AgentCard)
- Most frameworks use static declaration at construction time
- 50+ unique capabilities were identified across 13 categories
- Capabilities cluster into binary flags (streaming: yes/no) and rich declarations (tool schemas, sub-agent lists)
Detailed Specification
AbstractAgent Change
AgentCapabilities Root Interface
Category Interfaces
IdentityCapabilities
TransportCapabilities
ToolsCapabilities
Tool type is reused from @ag-ui/core, providing full JSON schema
definitions for each tool’s parameters.
OutputCapabilities
StateCapabilities
MultiAgentCapabilities
ReasoningCapabilities
MultimodalCapabilities
ExecutionCapabilities
HumanInTheLoopCapabilities
HttpAgent Convention
ForHttpAgent, which communicates with remote agents, capabilities are
discovered via a conventional endpoint:
GET /capabilities endpoint that returns the
AgentCapabilities JSON object.
Implementation Examples
Integration Implementation
Each integration implementsgetCapabilities() returning only what it supports:
Client Consumption
Dynamic Capabilities
Custom Capabilities
Integrations can declare custom capabilities beyond the standard categories:Use Cases
Adaptive UI
Clients render UI components based on what the agent actually supports — show a reasoning panel only ifreasoning.supported is true, display a tool picker
only if tools.items has entries.
Integration Selection
When multiple agents are available, clients can compare capabilities to select the best agent for a task — e.g., pick one that supports structured output and multi-agent delegation.Feature Gating
Disable UI features that the connected agent doesn’t support, providing clear feedback instead of runtime errors.Agent Marketplaces
Discovery platforms can index agent capabilities to help users find agents that match their needs.Debugging and Observability
Developers can inspect what an agent reports as its capabilities to diagnose integration issues.Implementation Considerations
Client SDK Changes
TypeScript SDK (@ag-ui/core and @ag-ui/client):
- New capability type definitions in
@ag-ui/core - Optional
getCapabilities?()method onAbstractAgent HttpAgentimplementation with conventional endpoint- New
capabilitiesUrlfield onHttpAgentConfig
- Pydantic models for capability types
- Optional
get_capabilities()method on agent base class - HTTP agent implementation for remote discovery
Framework Integration
Each integration implementsgetCapabilities() by mapping its internal
configuration to the standardized categories. Only supported features are
declared — absent fields mean the capability is not declared.
Versioning
New capability categories can be added toAgentCapabilities as optional fields
without breaking existing implementations. This is a non-breaking additive
change.
What Changes
| Component | Change |
|---|---|
@ag-ui/core | New capability type definitions |
@ag-ui/client AbstractAgent | Optional getCapabilities?() method |
@ag-ui/client HttpAgent | Implementation hitting {url}/capabilities |
@ag-ui/client HttpAgentConfig | New optional capabilitiesUrl field |
| Integrations | Each implements getCapabilities() for their features |
What Doesn’t Change
run()method andRunAgentInput- Event types and event processing pipeline
- Middleware and subscriber systems
- Existing
AgentConfig(exceptHttpAgentConfiggains one optional field)
Testing Strategy
- Unit tests for capability type construction and serialization
- Integration tests verifying each integration returns accurate capabilities
- Dynamic capability tests (add/remove tools, verify snapshot updates)
HttpAgenttests with mocked/capabilitiesendpoint- Type compatibility tests ensuring new types don’t break existing consumers