Supported protocols and application fields

Agent Proxy generates workload events for the following protocols and technologies:

• HTTP
• Snowflake
• MCP
• PostgreSQL
• Amazon Redshift
• MySQL and MariaDB
• Oracle Database
• Redis
• TCP Passthrough

This page lists the application fields Agent Proxy records for each protocol, split by request and response event. For the common fields that every event shares, see the Workload Event reference. For a conceptual overview, see Workload Events.

The Presence column indicates whether Agent Proxy always includes the field (Always) or includes it only under certain conditions (Optional).

HTTP and Snowflake

HTTP fields appear under application.http. Snowflake events are HTTP-based queries to Snowflake endpoints and use the same fields, under application.snowflake.

Request fields:

Field	Presence	Description
httpMethod	Always	HTTP method, such as GET or POST.
httpVersion	Always	HTTP version, such as HTTP/1.1.
uri	Always	Requested URI, with the query string removed to avoid recording sensitive values.
headers	Always	A list of single-key objects, each a header name and value, with sensitive headers redacted.

Response fields:

Field	Presence	Description
httpVersion	Always	HTTP version, such as HTTP/1.1.
headers	Always	A list of single-key objects, each a header name and value, with sensitive headers redacted.
httpResponseCode	Always	HTTP response status code, such as 200 or 404.

Example application.http block

"application": {
  "http": {
    "httpMethod": "GET",
    "httpVersion": "HTTP/1.1",
    "uri": "/v2/accounts",
    "headers": [
      {"content-type": "application/json"},
      {"host": "api.example.com"}
    ],
    "httpResponseCode": 200
  }
}

MCP

MCP events use the HTTP-based fields under application.mcp, plus MCP-specific fields.

Request fields:

Field	Presence	Description
httpMethod	Always	HTTP method, such as POST.
httpVersion	Always	HTTP version, such as HTTP/1.1.
uri	Always	Requested URI, with the query string removed to avoid recording sensitive values.
headers	Always	A list of single-key objects, each a header name and value, with sensitive headers redacted.
mcpMethod	Always	The MCP method for the request, such as tools/list or tools/call.
mcpSessionId	Always	The MCP session ID, shared across requests and responses in the same session.
mcpProtocolVersion	Optional	The negotiated MCP protocol version, when available.
mcpServerName	Optional	The name of the target MCP server, when available.
mcpToolName	Optional	The tool invoked, on tools/call requests.
mcpRequestId	Optional	The MCP request identifier, used to correlate a response with its request.
userId	Optional	The user identity for MCP flows that involve a human identity, matching the User (MCP App Protocol only) filter.

Response fields:

Field	Presence	Description
httpVersion	Always	HTTP version, such as HTTP/1.1.
headers	Always	A list of single-key objects, each a header name and value, with sensitive headers redacted.
httpResponseCode	Always	HTTP response status code, such as 200 or 404.
mcpMethod	Always	The MCP method the response corresponds to, such as tools/list or tools/call.
mcpSessionId	Always	The MCP session ID, shared across requests and responses in the same session.
mcpProtocolVersion	Optional	The negotiated MCP protocol version, when available.
mcpServerName	Optional	The name of the target MCP server, when available.
mcpRequestId	Optional	The MCP request identifier, used to correlate the response with its request.

Example application.mcp block

"application": {
  "mcp": {
    "httpMethod": "POST",
    "httpVersion": "HTTP/1.1",
    "uri": "/mcp/v1/tools/call",
    "headers": [
      {"content-type": "application/json"},
      {"host": "mcp.example.com"}
    ],
    "mcpMethod": "tools/call",
    "mcpSessionId": "3d9c1e77-5b42-4c8a-9f16-2a7e8b0d4c31",
    "mcpProtocolVersion": "2025-06-18",
    "mcpServerName": "example-mcp-server",
    "mcpToolName": "search_records",
    "mcpRequestId": "42",
    "userId": "alice@example.com"
  }
}

PostgreSQL and Amazon Redshift

PostgreSQL fields appear under application.postgres. Amazon Redshift uses the same fields, under application.redshift. Request and response events carry the same fields; the value of message.type differs by direction.

Request fields:

Field	Presence	Description
protocolVersion	Optional	The PostgreSQL wire protocol version.
user	Optional	The database user.
database	Optional	The target database name.
message.type	Always	The protocol message type, such as Query.
tls.version	Optional	The negotiated TLS version, such as TLSv1.2.

Response fields:

Field	Presence	Description
protocolVersion	Optional	The PostgreSQL wire protocol version.
user	Optional	The database user.
database	Optional	The target database name.
message.type	Always	The protocol message type.
tls.version	Optional	The negotiated TLS version, such as TLSv1.2.

Example application.postgres block

"application": {
  "postgres": {
    "protocolVersion": "3.0",
    "user": "analytics",
    "database": "warehouse",
    "message": {
      "type": "Query"
    },
    "tls": {
      "version": "TLSv1.2"
    }
  }
}

MySQL and MariaDB

MySQL fields appear under application.mysql. MariaDB shares the MySQL protocol handler and uses the same event types and fields. Request and response events carry the same fields; the value of message.type differs by direction.

Note

MySQL field names use snake_case, unlike the camelCase of the other protocols.

Request fields:

Field	Presence	Description
protocol_version	Always	The MySQL wire protocol version.
server_version	Always	The MySQL server version string, such as 8.4.7.
server_thread_id	Always	The server-assigned connection thread ID.
user	Always	The database user.
message.type	Always	The protocol message type, such as ComQuery.
connection_attributes	Optional	Client-supplied connection metadata, such as client name and version, operating system, and program name.

Response fields:

Field	Presence	Description
protocol_version	Always	The MySQL wire protocol version.
server_version	Always	The MySQL server version string, such as 8.4.7.
server_thread_id	Always	The server-assigned connection thread ID.
user	Always	The database user.
message.type	Always	The protocol message type.
connection_attributes	Optional	Client-supplied connection metadata, such as client name and version, operating system, and program name.

Example application.mysql block

"application": {
  "mysql": {
    "protocol_version": "10",
    "server_version": "8.4.7",
    "server_thread_id": 4182,
    "connection_attributes": {
      "_client_name": "libmysql",
      "_client_version": "8.4.7",
      "_os": "Linux",
      "program_name": "mysql"
    },
    "user": "reporting",
    "message": {
      "type": "ComQuery"
    }
  }
}

Oracle Database and Redis

Oracle Database fields appear under application.oracleDatabase, and Redis fields under application.redis. Both carry a single field, whose value differs between request and response events.

Request fields:

Field	Presence	Description
message.type	Always	The protocol message type. For Redis, the command name, such as AUTH. For Oracle Database, the packet type, such as Connect (NSPTCN).

Response fields:

Field	Presence	Description
message.type	Always	The protocol message type. For Redis, the status, such as OK or ERR. For Oracle Database, the packet type, such as Accept (NSPTAC).

Example application.oracleDatabase and application.redis blocks

"application": {
  "oracleDatabase": {
    "message": {
      "type": "Connect (NSPTCN)"
    }
  }
}

"application": {
  "redis": {
    "message": {
      "type": "AUTH"
    }
  }
}

TCP Passthrough

TCP Passthrough captures traffic that doesn’t match a supported application-protocol handler. Instead of request and response events, Agent Proxy generates the connection-level event types tcp.open and tcp.close, which don’t include an application block. When Agent Proxy can identify the underlying protocol, it records it in meta.identifiedProtocol.