Skip to main content
Glama
Sign In

PixelFlow

by so.pixelflow
OverviewDiscussionsAdmin

List supported values

list_supported_values
Read-onlyIdempotent

List the names PixelFlow supports and other tools accept: the platforms a site can run on, the ad platforms events can be sent to, the integrations that report conversions, the supported events, and the traffic sources events are attributed to. Use it when the user asks whether PixelFlow supports a platform, ad platform, integration, event, or traffic source, or before passing one of these names to another tool.

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_supported_values"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
eventsYesSupported events, such as Purchase or Lead. Trigger tools take these in `event`, blocking rules in `target`, and report filters in `events`.
sourcesYesTraffic source buckets PixelFlow assigns to events, such as facebook, google, organic, or direct. list_events and get_journeys take these in `sources`; get_attribution returns them as row keys and takes one in `source`.
platformsYesPlatforms a site can run on, such as webflow or wordpress. create_site and update_site take these in `platform`. other means custom code or a platform not in the list.
ad_platformsYesAd platforms PixelFlow sends events to, such as facebook or tiktok. get_connect_link takes these in `ad_platform`.
integrationsYesIntegrations that report conversions to PixelFlow, such as stripe or calendly. get_connect_link takes these in `integration`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: the returned names are the canonical identifiers other tools accept, which is behavioral guidance annotations cannot express. It does not describe response shape, but an output schema exists to cover that.

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?

Two sentences, front-loaded with the action and value categories, then the usage condition. The five-item enumeration is somewhat long but each item maps to a distinct value domain, so it earns its space.

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?

A zero-parameter, read-only lookup with an output schema and full annotation coverage. The description supplies the value domains and the usage rationale, which is everything an agent needs to select and call it correctly.

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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description's categorization of returned values is the only semantic payload needed here.

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 ('List') and names the exact resource set: platforms, ad platforms, integrations, events, and traffic sources. These enumerated vocabularies let an agent distinguish it cleanly from siblings like list_events or list_sites, which list instances rather than the supported name set.

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 two explicit triggers: when the user asks whether a platform/ad platform/integration/event/traffic source is supported, and as a prerequisite lookup before passing such a name to another tool. The second clause effectively routes the agent away from guessing enum values in sibling calls.

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

All PixelFlow toolsInspect
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.

Resources