PixelFlow

Get event details

get_event_payloads

Read-onlyIdempotent

Get the payload (request body) PixelFlow sent to each ad platform for up to 25 events by id. Each event lists every pixel it was sent to, with that payload and any error. IP addresses in the payload are partly hidden. Pass include_ip true to see them in full. Name, email and phone are hashed, as the ad platforms receive them. Use it to see exactly what was sent for an event from list_events, or why an ad platform rejected it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site_id": "<site_id>",
      "ids": "<ids>"
    },
    "name": "get_event_payloads"
  }
}

Input Schema

Name	Required	Description
`ids`	Yes	Row `id` values from list_events.
`site_id`	Yes	Site to act on, as returned by list_sites.
`timezone`	No	IANA time zone such as Europe/Berlin. Default UTC. Returned times and day buckets use it.
`include_ip`	No	Whether to return the full IP address inside the payload. Default false, which keeps only the first three IPv4 octets or the IPv6 /48 and replaces the rest with x. Use only when the user asks for the full address.

Output Schema

Name	Required	Description	Default
`events`	Yes	One per id found, in the order of `ids`.
`timezone`	Yes	IANA time zone used for times.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 2, 2026
- addedOutput schema / properties / events / items / properties / pixels / items / properties / ad_platform / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / events / items / properties / pixels / items / properties / ad_platform / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- addedOutput schema / properties / events / items / properties / pixels / items / properties / error / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / events / items / properties / pixels / items / properties / error / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- removedOutput schema / properties / events / items / properties / pixels / items / properties / payload / additionalProperties
```
Removed value: -true
```
- addedOutput schema / properties / events / items / properties / pixels / items / properties / payload / anyOf
```
Added value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / events / items / properties / pixels / items / properties / payload / type
```
Removed value: -[
-  "object",
-  "null"
-]
```

Changed10 schema fields changedNov 2, 2026

changedInput schema / properties / ids / description

Previous value: -"Event ids from list_events. At most 25"New value: +"Row `id` values from list_events."

changedInput schema / properties / ids / items / type
```
Previous value: -"number"New value: +"integer"
```
addedInput schema / properties / ids / minItems
```
Added value: +1
```

changedInput schema / properties / include_ip / description

Previous value: -"True returns the IP whole. Omitted keeps the first three IPv4 octets, or the IPv6 /48"New value: +"Whether to return the full IP address inside the payload. Default false, which keeps only the first three IPv4 octets or the IPv6 /48 and replaces the rest with x. Use only when the user asks for the full address."

removedInput schema / properties / include_sent

Removed value: -{
-  "description": "True adds the body sent to each Pixel and that Pixel response",
-  "type": "boolean"
-}

removedInput schema / properties / site

Removed value: -{
-  "description": "Domain, id, or external id from list_sites",
-  "type": "string"
-}

addedInput schema / properties / site_id

Added value: +{
+  "description": "Site to act on, as returned by list_sites.",
+  "type": "integer"
+}

changedInput schema / properties / timezone / description

Previous value: -"IANA timezone. Omitted means UTC, and the response says UTC"New value: +"IANA time zone such as Europe/Berlin. Default UTC. Returned times and day buckets use it."

changedInput schema / required

Previous value: -[
-  "site",
-  "ids"
-]New value: +[
+  "site_id",
+  "ids"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "events": {
+      "description": "One per id found, in the order of `ids`.",
+      "items": {
+        "additionalProperties": false,
+        "description": "One event.",
+        "properties": {
+          "event": {
+            "description": "The event recorded, such as Purchase.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Row id from list_events.",
+            "type": "integer"
+          },
+          "pixels": {
+            "description": "One per pixel the event was sent to, including pixels deleted since. Empty when the event was not sent to any pixel.",
+            "items": {
+              "additionalProperties": false,
+              "description": "One send.",
+              "properties": {
+                "ad_platform": {
+                  "description": "The pixel, as in list_events.",
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                },
+                "error": {
+                  "description": "Error stored for this send. Set only on a real failure.",
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                },
+                "name": {
+                  "description": "The pixel, as in list_events.",
+                  "type": "string"
+                },
+                "payload": {
+                  "additionalProperties": true,
+                  "description": "Payload (request body) sent to the ad platform, as stored. IP masked unless include_ip. null when no payload is stored, such as a send that failed before dispatch or an event older than payload retention.",
+                  "type": [
+                    "object",
+                    "null"
+                  ]
+                },
+                "pixel_id": {
+                  "description": "The pixel, as in list_events.",
+                  "type": "integer"
+                },
+                "state": {
+                  "description": "Send status, as in list_events.",
+                  "enum": [
+                    "sent",
+                    "failed",
+                    "pending"
+                  ],
+                  "type": "string"
+                }
+              },
+              "required": [
+                "pixel_id",
+                "name",
+                "ad_platform",
+                "state",
+                "error",
+                "payload"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "time": {
+            "description": "Arrival time.",
+            "format": "date-time",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "time",
+          "event",
+          "pixels"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "timezone": {
+      "description": "IANA time zone used for times.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "timezone",
+    "events"
+  ],
+  "type": "object"
+}

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety and idempotency, but the description adds substantial behavioral context: each event lists every pixel with its payload and any error, IPs are partially hidden unless include_ip is true, and name/email/phone are hashed as the ad platforms receive them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then adds only relevant details about return structure, IP masking, hashing, and usage. Every sentence contributes useful context without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering safety, an output schema present, and full schema description coverage, the description supplies the remaining context an agent needs: what the payload contains, how pixels and errors are represented, and how sensitive fields are masked.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters in detail. The description reinforces the 25-event limit and IP masking behavior, but does not add parameter syntax or meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get the payload (request body) PixelFlow sent to each ad platform for up to 25 events by id.' It clearly distinguishes the tool from list_events by explaining that it retrieves payload details rather than listing events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use it to see exactly what was sent for an event from list_events, or why an ad platform rejected it. The connection to list_events gives clear context, though it does not explicitly exclude other sibling tools such as get_attribution.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All PixelFlow tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.