Gentic SMS Marketing — Documentation

1. Getting Started

Sign Up & Get Your API Key

Before you can use Gentic SMS Marketing, you need an API key to authenticate your requests.

1. Go to gentic.co/sms-marketing and create an account.
2. Create an organization from your dashboard. API keys and billing are scoped to the organization.
3. Generate an API key and use it as a Bearer token in your MCP client.

2. Connecting to the MCP Server

The server is available at https://mcp.gentic.co/sms-marketing. For Claude Code:

claude mcp add gentic-sms-marketing \
  --transport http \
  https://mcp.gentic.co/sms-marketing \
  --header "Authorization: Bearer YOUR_API_KEY"

For Claude Web and ChatGPT you can also connect via OAuth — no API key needed. See the connect section on the landing page for other MCP clients (n8n, OpenClaw).

3. Agent Skill

For the best results, pair the MCP server with the Gentic SMS Marketing agent skill. The MCP server gives your agent tool access; the skill teaches it the optimal workflow order. Both the raw SKILL.md and a ready-to-upload .skill bundle are generated on demand from the live manifest, so they always reflect the current tools and pricing.

Add the skill directly via URL:

https://gentic.co/sms-marketing/SKILL.md

Or upload a .skill bundle to Claude Managed Agents:

https://gentic.co/sms-marketing/gentic-sms-marketing.skill

Download this file and upload it wherever Claude Managed Agents asks for a .skill file. It's a zip bundle generated on demand from the latest SKILL.md.

4. When to Apply

• User wants to know what share of revenue or AOV comes from SMS subscribers.
• User wants list growth and opt-out rate over time.
• User wants to know whether SMS subscribers retain or resubscribe better than non-subscribers.
• User wants to know which keywords or sign-up sources are actually growing the list.
• User wants to sync their Postscript subscriber list into their Brain for analysis.
• User wants to join SMS opt-in status against orders, subscriptions, loyalty or survey data.

5. Workflow

1. 1. Connect Postscript once, then sync without credentials

   The SMS Marketing server sources the Postscript connection (the Private API key) from the org's connected integration (Gentic dashboard → Integrations → Postscript). You never pass credentials to the tools. Call `postscript_connection_status` first — it's free and returns `{ connected, shop_id, shop_name, checked_live }`. Pass `check_live` when you want it to actually probe Postscript rather than just report that a key is stored; that distinguishes a credentials problem from an empty result, which is the ambiguity worth resolving before you debug a sync.

2. 2. ⚠️ Know what this domain does NOT have, before you promise it

   Postscript's API exposes **no campaign, automation or message-performance data at all**. No tool here can tell you how a send performed — open rate, click rate, revenue per message, none of it exists to read. If the user asks about SMS campaign performance, say so plainly and point them at `klaviyo_report` on the `/email-marketing` domain. Answering with subscriber-list numbers dressed up as campaign results is worse than saying it isn't available.

3. 3. Sync the subscriber list with `postscript_sync`

   `postscript_sync` is **free** and READ-ONLY. It warehouses `postscript_subscribers` (id, ps_id, email, shopify_customer_id, per-channel opt-in status, tags, custom properties) and `postscript_keywords`, upserted on their id so a re-sync refreshes rows in place. Two retention details worth knowing before you interpret the tables: opted-out subscribers are **included**, so the table is the churn record as well as the active list; and keywords are never deleted from the table, so a keyword removed in Postscript stays as a historical row.

4. 4. Phone numbers and names are scrubbed before anything is written

   Numbers and customer names never reach the warehouse — they're removed on ingest, and the removed field names come back in `scrubbed_keys` and are recorded on each row. That's deliberate: the list is analysable without warehousing contact details. It also means this domain cannot be used to retrieve someone's phone number, and a request to do so should be declined rather than worked around.

5. 5. Walk the list with bounded, resumable pagination

   Each `postscript_sync` call is BOUNDED: it pages until `max_pages_per_run` pages OR `max_seconds_per_run` seconds, then returns `has_more` and a `next_cursor`. Call again passing that back as `cursor` until `has_more` is false; `total_pages` tells you how far the walk still has to go. The result also carries `rate_limited_retries` — how many times the run was rate-limited and retried. It's the field that tells a short run apart from a throttled one: Postscript's page size is fixed at 25 and cannot be raised, so when that count is high the answer is to keep calling, not to raise the bounds. Use `resources` to sync only the table you need, and `updated_since` for an incremental refresh rather than a full backfill.

6. 6. Count and aggregate with `query_data`

   The SMS tools warehouse data; they don't analyze it. For subscriber counts, list growth, opt-out rate, or SMS-subscriber revenue share, use `query_data` (Gentic Data MCP) over `postscript_subscribers` and `postscript_keywords` — standard SQL GROUP BY / COUNT / SUM. Sync first (or re-sync incrementally) so the numbers are current.

7. 7. Join against the rest of the business — this is the point

   A subscriber list on its own gives you growth and opt-out rate. Everything more interesting comes from the join, and `shopify_customer_id` is already on the row: against orders for SMS-subscriber revenue share and AOV versus non-subscribers, against subscription tables (`skio_*` / `loop_*`) for whether SMS opt-in tracks retention, against loyalty (`rivo_*`) for whether your SMS list and your VIPs are the same people. Compose it with `query_data`.

8. 8. Present results clearly

   Don't dump raw JSON. Summarize the numbers — subscriber counts, growth, opt-out rate, revenue share — and cite them. After a sync, say how many rows landed per table and **how far through the walk you are** — `has_more` together with `total_pages`, never `has_more` alone. The boolean reads the same at 1% and at 99%, so “there’s more to page through” sounds like nearly-done when it can mean thousands of pages remain; at a fixed 25 records per page that difference is the whole answer. Also mention `rate_limited_retries` when it's non-zero, because it explains a run that returned less than expected. If the question was about campaign performance, lead with the fact that this data doesn't exist here rather than burying it under numbers that don't answer it.

6. Tool Reference

2 tools, rendered live from the Gentic MCP manifest. Parameter tables come directly from each tool's JSON Schema.

7. Pricing

Pricing is pulled live from the Gentic MCP manifest. All prices are per call and deducted from your Gentic credits.

8. Notes

• Organization-scoped: the Postscript connection comes from the org's connected integration (dashboard → Integrations → Postscript). No credential is ever passed to the tools.
• Cost: both `postscript_connection_status` and `postscript_sync` are **free**. You pay only for analytics you run over the synced data (e.g. `query_data`). Pricing is pulled live from the Gentic MCP manifest.
• **No campaign or message-performance data exists in Postscript's API** — nothing here reports how a send performed. For SMS campaign stats use `klaviyo_report` on the `/email-marketing` domain.
• `postscript_sync` is READ-ONLY: it never sends a text, never edits a subscriber, and never writes back to Postscript.
• Phone numbers and customer names are removed before anything is written; the removed field names are returned in `scrubbed_keys` and recorded on each row.
• Opted-out subscribers are included in `postscript_subscribers`, so the table is the churn record as well as the active list.
• Keywords are never removed from `postscript_keywords`: a keyword deleted in Postscript remains as a historical row.
• Syncs are bounded and resumable: each call stops at `max_pages_per_run` / `max_seconds_per_run` and returns `has_more` + `next_cursor`; pass it back as `cursor` until `has_more` is false. `total_pages` shows the remaining distance, `rate_limited_retries` reports how often the run was rate-limited and retried, and `updated_since` gives an incremental refresh instead of a full backfill.
• The two tables — `postscript_subscribers` and `postscript_keywords` — are queried with `query_data` for all counts and aggregations.