PixelFlow

List sites

list_sites

Read-onlyIdempotent

List the websites the signed-in user can access in PixelFlow: each site's site_id, domain, platform, currency, whether the user can edit it, and the workspace it belongs to with the user's role there. Plan, limits, and usage are in get_site_status. Use it to find the site_id for a website the user names, or to ask which site they mean when there are several.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_sites"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`sites`	Yes	Every site the user can access, across all their workspaces.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 2, 2026
- addedOutput schema / properties / sites / items / properties / currency / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / sites / items / properties / currency / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- addedOutput schema / properties / sites / items / properties / domain / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / sites / items / properties / domain / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- addedOutput schema / properties / sites / items / properties / platform / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / sites / items / properties / platform / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

Changed1 schema field changedNov 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "sites": {
+      "description": "Every site the user can access, across all their workspaces.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "can_edit": {
+            "description": "Whether the user may run write tools on this site.",
+            "type": "boolean"
+          },
+          "currency": {
+            "description": "ISO 4217 currency for event values.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "domain": {
+            "description": "Website domain, such as example.com. null until saved (allowed on platforms with a PixelFlow plugin, such as WordPress).",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "external_id": {
+            "description": "Public id of this site. For sites created from the PixelFlow app inside Webflow or Framer, this is that builder's site id; otherwise PixelFlow generated it. The PixelFlow snippet uses it as its site id. Output only.",
+            "type": "string"
+          },
+          "platform": {
+            "description": "Platform the site runs on, such as webflow or wordpress. null until chosen.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "site_id": {
+            "description": "Site id. Every other tool takes it as site_id.",
+            "type": "integer"
+          },
+          "workspace_id": {
+            "description": "Workspace that owns the site. create_site takes it as workspace_id.",
+            "type": "integer"
+          },
+          "workspace_name": {
+            "description": "Workspace name.",
+            "type": "string"
+          },
+          "workspace_role": {
+            "description": "The user's role in that workspace. A viewer cannot run write tools.",
+            "enum": [
+              "owner",
+              "admin",
+              "viewer"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "site_id",
+          "external_id",
+          "domain",
+          "platform",
+          "currency",
+          "can_edit",
+          "workspace_id",
+          "workspace_name",
+          "workspace_role"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "sites"
+  ],
+  "type": "object"
+}

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description focuses on access scoping — results are limited to what the signed-in user can access, and edit permission is per-site. That access boundary is genuinely additive. It stops short of noting result size or what an empty list means for a user with no sites.

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?

Three front-loaded sentences with no filler: purpose and returned fields first, boundary against the sibling second, usage trigger third. The field enumeration slightly overlaps with the existing output schema, which is the only wasted motion.

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?

An output schema exists, so return values need no further explanation, and the description still covers scope, sibling boundary, and invocation intent. For a zero-parameter read tool this is complete — 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.

Parameters4/5

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no filtering arguments are needed since all accessible sites are returned.

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 and resource ('List the websites the signed-in user can access in PixelFlow') and enumerates the fields returned (site_id, domain, platform, currency, edit permission, workspace role), so the agent knows exactly what comes back. It explicitly separates itself from get_site_status, which handles plan/limits/usage.

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

Usage Guidelines5/5

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

Gives concrete triggers: use it to resolve a site_id for a website the user names, or to disambiguate when several sites match. It also names the alternative tool (get_site_status) and what that tool is for, so the routing decision is explicit in both directions.

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.