Notifly

MANDATORY before create_campaign/replace_campaign: returns the resolved payload schema for the scenario, including a copy-and-fill full_example_payload, the channel-specific required message fields (derived from the live validator), and notes covering sub-branches not expressible in the schema (e.g. text-message sms/lms/mms, scheduled frequency). Pass the chosen channel, type, timing_type, and segment_mode to get the most concrete schema; omit any to receive all variants for that dimension. Many required rules live only in superRefine and are invisible in the create_campaign input schema, so always call this first.

describe_campaign_payload

Run a read-only shell-like query against the Notifly Docs virtual filesystem rooted at /. Use this when you need exact documentation content or a full page after search_notifly_docs. Supported commands include rg, grep, find, tree, ls, cat, head, tail, stat, wc, sort, uniq, cut, sed, awk, and jq. The filesystem is stateless and command output may be truncated by the upstream docs MCP server.

query_docs_filesystem_notifly_docs

Search Notifly Docs for product documentation, guides, API references, and code examples. Use this first when you need to find relevant Notifly documentation pages. If the user needs a full page or exact source text, use query_docs_filesystem_notifly_docs after search.

search_notifly_docs

Create a draft campaign in a Notifly project. ALWAYS call describe_campaign_payload first with the chosen channel/type/timing_type/segment_mode and build the payload from its full_example_payload; many required rules (especially per-channel message fields) live only in server-side validation and are not visible in this input schema. This only creates draft campaigns and uses the same web-console builder-compatible payload contract as POST /v1/projects/{projectId}/campaigns. timing is strict by timing.type and timing.details.frequency: scheduled frequency=once requires timing.details.on + timezone_options and must not include timing.details.period; scheduled frequency=everyday/weekly and event-based timing use timing.details.period with full date-time strings such as 2026-03-06T11:42:00. Time-only values such as 00:00 or 23:59 are rejected. event-based timing requires timing.details.period and trigger variants match the web-console flow: use_advanced_options=false requires event; use_advanced_options=true requires event_name conditions. segment.mode=condition uses web-console condition units such as unit=user/device/event/campaign_exposure/file_based/session; loose aliases like type=user_property or operator=days_before are rejected. message payloads are validated by channel: push/web-push require title and body, push importance is lowercase low/normal/high, and email requires subject/sender_email/sender_name/content. For SMS/LMS/MMS, use channel: "text-message"; do not use channel: "sms" or channel: "lms". Put the subtype in message.type (sms, lms, or mms), set message.platform: "notifly", and include message.body plus message.sender_phone_number. LMS/MMS require message.title; MMS requires 1 to 3 message.attachments. Public fields are snake_case and converted once into web-console view_state so the draft can be opened in the edit form.

Create a saved condition-based user segment in a Notifly project.

Create an inactive user journey draft in a Notifly project. This stores builder state and does not activate or schedule the journey. Use request-local refs and *_node_ref links; persisted node IDs are generated. Valid node.type values: message, delay, event_trigger, user_update, event_branching, segment_branching, variant_branching. For segment_branching, segments[].segment is the direct { groups, operator, additional_conditions?, condition_targeting_mode? } object, never { mode, details }. Entry timing/segment matrix: api→none, scheduled→condition|csv, event-based→condition. Message nodes must provide exactly one of message or localized_messages. localized_messages is accepted only for projects with localized message writes enabled; otherwise use message.

Delete a saved user segment by segment_id.

Read one campaign's CONFIGURATION by campaign_id (a 6-character ID, not a name). Returns settings only — it does NOT include statistics/performance numbers. For results/performance, call get_campaign_statistics separately. Use this directly when the campaign_id is known instead of calling list_campaigns first.

Read asynchronously pre-aggregated campaign statistics. Input boundaries are UTC and statistics use UTC hourly buckets: use YYYY-MM-DD with [start, end); equal bounds select no data. Returned stats daily date labels and lastCollectedAt, when present, are KST. If lastCollectedAt is omitted, no freshness value is available. No unavailable reason is returned, so zero or empty results cannot distinguish no activity from aggregation lag.

Check whether a specific user is/was eligible for a specific campaign, with privacy-preserving evidence of why they were or were not targeted. Use this FIRST for any single-user-single-campaign question like "why was this user (not) sent this campaign?" or "is this user in the target?".