Skip to main content
Glama
awesomemotive

pushengage-mcp

Create an audience group

pushengage_create_audience_group

Create an audience group by defining a subscriber-filter expression to match users based on device, engagement, or custom attributes.

Instructions

Creates a new audience group on the current site. Required: name and filter. The filter is a subscriber-filter expression — { op: "or" | "and" (default "or"), value: 2-D array of rule groups }. Each rule is { field, op, value?, key? }. Rules WITHIN a group are AND-ed; groups in value are combined with the top-level op. See the inputSchema field descriptions for the supported field and op enums. Common patterns: "Mobile subscribers" → filter={ op: "or", value: [[{ field: "device", op: "in", value: ["mobile"] }]] }. "Subscribed in the last 7 days" → filter={ op: "or", value: [[{ field: "ts_created", op: "ts_elapsed_lt", value: 604800 }]] }. "Highly engaged" (≥20 sent AND ≥2 clicks) → filter={ op: "or", value: [[{ field: "sent_count", op: "gt", value: 20 }, { field: "click_count", op: "gt", value: 2 }]] }. Only set description and complex filters when the user explicitly describes them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesAudience-group display name. 1–150 chars.
filterYesRequired. The subscriber-filter expression that decides which subscribers belong to this group. Use SubscriberFilterSchema: an outer op ("or"/"and") + a 2-D `value` array (groups of AND-ed rules). Each rule is { field, op, value?, key? }. Example — "all mobile subscribers": { op: "or", value: [[{ field: "device", op: "in", value: ["mobile"] }]] }. Example — "subscribed in the last 7 days": { op: "or", value: [[{ field: "ts_created", op: "ts_elapsed_lt", value: 604800 }]] }. (604800 = 7 × 24 × 3600 seconds.)
site_idNoOverride the currently selected site.
descriptionNoOptional human-readable description, up to 256 chars.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
nameNo
filterNo
view_urlNo
descriptionNo
use_with_send_notificationNo
Behavior4/5

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

Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior. The description adds valuable context on the filter expression semantics, such as how rules within and across groups combine, and includes examples. It does not reveal side effects like duplicate handling, but annotations cover the safety profile.

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 well-structured and front-loaded with purpose. It uses compact notation for the filter schema, provides efficient examples, and every sentence adds value. The usage caution at the end is a worthwhile addition without bloat.

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

Completeness4/5

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

For a tool with a complex nested filter parameter, the description is highly complete: it explains the creation context, required parameters, filter semantics, and common patterns. An output schema exists, so return values are covered elsewhere. It does not discuss alternatives, but that gap is minor given the overall guidance.

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

Parameters5/5

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

With 100% schema coverage, the baseline is 3, but the description goes far beyond by explaining the nested filter structure in plain language, providing three complete examples, and advising when to set description and complex filters. This makes the parameters much easier to use correctly.

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 clearly states 'Creates a new audience group on the current site' with a specific verb and resource, and distinguishes from sibling tools like list_audience_groups. It also names the required parameters, making the tool's purpose unambiguous.

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?

Provides clear context for when to use (creating an audience group) and offers concrete filter patterns for common use cases. It does not explicitly mention alternatives or when-not-to-use, but the purpose is distinct among siblings and the guidance is sufficient for most scenarios.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/awesomemotive/pushengage-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server