PixelFlow

Update Get Started checklist

close_get_started

Idempotent

Check the site's Get Started checklist and mark as done the items PixelFlow can confirm from its data. The setup item is marked done when any event was received. The old pixel item is marked done when the last page check found no native ad platform pixel. The UTM item is marked done when an event came from a paid source. The consent banner item is marked done when a banner was detected or consent blocked an event. Items are only marked done, never undone. Returns the items this call marked done and the items not done yet, each with the update_site field that marks it done once the user confirms. Use it at the end of setup.

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>"
    },
    "name": "close_get_started"
  }
}

Input Schema

Name	Required	Description	Default
`site_id`	Yes	Site to act on, as returned by list_sites.
`extra_events_declined`	No	Whether the user said they do not want to track more conversions. Saves that answer so get_site_status stops asking.

Output Schema

Name	Required	Description
`remaining`	Yes	Items not done yet that apply to this site.
`marked_done`	Yes	Items this call marked done, named by their flag: is_completed (setup finished), is_old_pixel_removed, is_utm_snippet_added, is_consent_banner_configured. Empty when no item was marked done.
`has_conversion_event`	Yes	Whether an event other than PageView arrived in the last events_window_days of get_site_status.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 2, 2026

changedInput schema / properties / extra_events_declined / description

Previous value: -"True when the customer does not want conversions beyond the ones the shop already tracks. False does not clear the flag"New value: +"Whether the user said they do not want to track more conversions. Saves that answer so get_site_status stops asking."

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 / required

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

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "has_conversion_event": {
+      "description": "Whether an event other than PageView arrived in the last events_window_days of get_site_status.",
+      "type": "boolean"
+    },
+    "marked_done": {
+      "description": "Items this call marked done, named by their flag: is_completed (setup finished), is_old_pixel_removed, is_utm_snippet_added, is_consent_banner_configured. Empty when no item was marked done.",
+      "items": {
+        "enum": [
+          "is_completed",
+          "is_old_pixel_removed",
+          "is_utm_snippet_added",
+          "is_consent_banner_configured"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "remaining": {
+      "description": "Items not done yet that apply to this site.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "docs": {
+            "description": "Help articles for this item: `title` (string) and `url` (string, uri).",
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "title": {
+                  "type": "string"
+                },
+                "url": {
+                  "format": "uri",
+                  "type": "string"
+                }
+              },
+              "required": [
+                "title",
+                "url"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "field": {
+            "description": "The update_site field that marks this item done.",
+            "enum": [
+              "is_old_pixel_removed",
+              "is_utm_snippet_added",
+              "is_meta_domain_approved",
+              "is_consent_banner_configured"
+            ],
+            "type": "string"
+          },
+          "title": {
+            "description": "Item title, such as \"Approve your domain in Meta\".",
+            "type": "string"
+          }
+        },
+        "required": [
+          "field",
+          "title",
+          "docs"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "has_conversion_event",
+    "marked_done",
+    "remaining"
+  ],
+  "type": "object"
+}

First observedOct 23, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare the write/idempotent/non-destructive profile, and the description adds real value beyond them: writes are one-way ('Items are only marked done, never undone') and the returned payload includes per-item update_site fields. This is meaningful mutation context; only pagination/refresh behavior is left unstated.

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

Conciseness4/5

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

The core action leads, followed by the per-item rules in parallel structure, then the return shape and a placement cue. Every sentence carries information, though the four near-identical 'The X item is marked done when…' sentences make it longer than strictly necessary.

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?

For a 2-parameter write tool with annotations and an output schema, this covers what is mutated, the exact trigger conditions per item, the one-way nature of the change, and a usage cue. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so site_id and extra_events_declined are already documented, and the description adds no syntax or semantics for either. It does imply the tool reads PixelFlow's own event data to decide completion, but that is not parameter-level guidance, so baseline 3 applies.

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?

States a specific verb pair (check / mark done) and a specific resource (the site's Get Started checklist), plus the criterion for which items get marked. An agent can distinguish this from read-only status tools like get_site_status because it explicitly says it writes completion state.

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?

Gives a clear situational cue ('Use it at the end of setup') and enumerates the exact conditions under which each checklist item is completed. It stops short of naming an alternative tool or stating when not to call it, so it falls just below the top band.

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.