Skip to main content
An application reaches an agent once the agent is in the registry and the application lists it: Applications → the application → General → Agents → Add agent. An application with no agents has no agent plane.

The Connect tab

Connect → Agents lists each agent the application calls, with its A2A version and a button that copies its card URL. Agent in the examples picks the agent the cURL and Python snippets call. Any A2A client works: point it at the agent’s card on the gateway and send the application’s key, from the Auth tab, in X-AG-API-Key.
On a 0.3 agent the method is message/send and the message is written the 0.3 way ("role": "user", "kind": "text" parts). Requests must be Content-Type: application/json and carry one JSON-RPC 2.0 request with an id. Your own code can find the addresses from the key instead: GET /whoami on the MCP host lists each of the key’s agent applications with its agents, their card URLs and versions, and the TrustGate SDK hands them to an A2A client.

Who a call runs as

The plane authenticates callers as the MCP plane does:
  • the application’s key in X-AG-API-Key, or Authorization: Bearer ag_…;
  • a client certificate;
  • a token from an identity provider the gateway trusts.
A bearer token without the ag_ prefix is validated as a token, even when an X-AG-API-Key is also sent. MCP session tokens are not accepted. Who the call runs as decides who owns its tasks and what the agent receives when it signs in as the user (see sign-in).

Errors

These three come back as HTTP statuses, before the body is read and before any call to the agent: 413 answers a body over 8 MiB, and 402 (-32092, plan_unavailable) a gateway whose usage plan is exhausted. Everything else is a JSON-RPC error over HTTP 200: -32092 reasons: An error the agent itself answers is relayed as it came.