🧭 Type of Feature

Please select the most appropriate category:

• Enhancement to existing functionality
• New feature or capability
• New MCP-compliant server
• New component or integration
• Developer tooling or test improvement
• Packaging, automation and deployment (ex: pypi, docker, quay.io, kubernetes, terraform)
• Other (please describe below)

📓 Additional Context

The client is building a multi-agent architecture using Google ADK agents registered in ContextForge as A2A agents. While the registration and admin UI are functional, there is a critical architectural limitation: ContextForge lacks a native, transparent A2A JSON-RPC proxy.

Current State & Limitations

Currently, agents can only be invoked via a REST endpoint (POST /a2a/{agent_name}/invoke) or an MCP tool bridge (POST /mcp/). The client reports that both methods are insufficient for standard A2A clients (such as Google ADK's RemoteA2aAgent). Specifically, the translation to the MCP protocol causes a significant loss of A2A protocol semantics:

• Task Lifecycle: Complex operations (tasks/send, tasks/get, tasks/cancel) are reduced to stateless tools/call executions.
• Streaming: There is no support for SSE/WebSocket for long-running responses.
• Artifacts: File attachments within A2A tasks have no equivalent in the MCP response format.
• Asynchronous Communication: Push notifications are impossible via synchronous MCP calls.

Technical Requirement

The requirement is the implementation of a transparent proxy endpoint (e.g., POST /a2a/{agent_name}/) that:

1. Accepts standard A2A JSON-RPC requests.
2. Applies ContextForge governance (Auth, RBAC, Rate-limiting) at the proxy layer.
3. Forwards the payload to the downstream agent without protocol translation.
4. Returns the native response directly to the caller.