--- title: "Courier MCP server" url: "https://martechdb.com/vendors/courier" markdown_url: "https://martechdb.com/vendors/courier.md" api_url: "https://martechdb.com/api/v1/vendors/courier.com" updated: "2026-10-27" --- # Courier MCP server Yes. Courier publishes an official MCP server at https://mcp.courier.com. It's hosted. It offers 173 tools. We last checked it on 1 Nov 2026. MartechDB lists only servers the vendor publishes itself, never community servers. **Key facts:** As of 1 Nov 2026, Courier's official MCP server scores 65/100 (provisional) on MartechDB's Agent Readiness Index (v1.1). It lists 173 tools. - Website: [courier.com](https://courier.com) - Categories: [Marketing automation](https://martechdb.com/categories/marketing-automation.md) ## Review Courier's Courier MCP scores 65/100 on MartechDB's Agent Readiness Index: easy to connect an AI agent to, with a few gaps. The good: - Hosted by Courier: connect by URL, with nothing to install - Documented, with 173 tools known Not checked yet: how you sign in; what agent access costs. ## Agent Readiness Index: 65/100 (provisional) How friendly Courier is to AI agents, from its best official MCP server. Anything not yet researched scores nothing, so this score may rise once it is. Methodology v1.1: https://martechdb.com/methodology. - Official MCP server: 30/30 (Published by the vendor) - Hosted by the vendor: 25/25 (Connect by URL, nothing to install) - OAuth sign-in: pending (Sign-in: see vendor docs) - Documented tools: 10/10 (A docs page, and its tools are known) - Free to start, pay as you go: 0/15 (Not stated by the vendor) ## Courier MCP - Address: https://mcp.courier.com - Runs: Hosted - Sign-in: Sign-in: see vendor docs (`unknown`) - Official MCP Registry: not listed - Documentation: https://www.courier.com/docs/resources/mcp - How we know it's official: Documented on Courier's own site, at www.courier.com - First seen: 2026-10-27 - Last checked: 2026-11-01 - Recent checks: 5 of the last 5 reachable ### Tools (173) As the server lists them on 2026-11-01. Names and descriptions come from the vendor's server. - `list_messages` (read-only): List messages you've previously sent. Filter by status, recipient, notification, provider, tags, or tenant. - `get_message` (read-only): Get the full details and status of a single message by its ID. - `get_message_content` (read-only): Get the rendered content (HTML, text, subject) of a previously sent message. - `get_message_history` (read-only): Get the event history for a message, showing each step in the delivery pipeline (enqueued, sent, delivered, etc.). - `list_notifications` (read-only): List notification templates, newest first. Pass tags to return only templates carrying ALL of the given tags. Page through the rest with cursor. - `get_notification_content` (read-only): Get the published content blocks of a notification template. - `get_notification_draft_content` (read-only): Get the draft (unpublished) content blocks of a notification template. - `create_notification`: Create a V2 notification template. name is required. Content may be provided inline or set separately afterwards. A newly created template is a draft; making it live is a separate step this tool cannot perform. Link a routing strategy via notification.routing.strategy\_id to control which channels are used. Example: { notification: { name: 'welcome-email', tags: \[\], brand: null, subscription: null, routing: { strategy\_id: 'rs\_01abc' }, content: { version: '2022-01-01', elements: \[\] } } }. - `get_notification` (read-only): Retrieve a notification template by ID. Optionally request draft, published, or a version such as v001. - `replace_notification`: Replace a notification template entirely (full document PUT). The template stays a draft; making it live is a separate step this tool cannot perform. - `put_notification_content`: Replace the elemental content of a V2 notification template. Overwrites all elements. Use channel elements to target specific channels. Multi-channel example: elements: \[{ type: "channel", channel: "email", elements: \[{ type: "meta", title: "Hello" }, { type: "text", content: "Email body" }\] }, { type: "channel", channel: "push", elements: \[{ type: "meta", title: "Hello" }, { type: "text", content: "Push body" }\] }, { type: "channel", channel: "inbox", elements: \[{ type: "text", content: "Inbox plain text only" }\] }\]. The template stays a draft; making it live is a separate step this tool cannot perform. - `put_notification_element`: Update a single element within a V2 notification template. The template stays a draft; making it live is a separate step this tool cannot perform. - `put_notification_locale`: Set locale-specific content overrides for a V2 notification template. Each element override must reference an existing element by its id. Example for Spanish locale: { notification\_id: "nt\_01abc", locale\_id: "es", elements: \[{ id: "elem\_meta\_1", title: "Restablecer contraseña" }, { id: "elem\_text\_1", content: "Haga clic en el enlace para restablecer su contraseña." }\] }. The template stays a draft; making it live is a separate step this tool cannot perform. - `list_notification_versions` (read-only): List the version history of a notification template — each published version with when it was created. Use this to say what changed and when, or to find the version string get\_notification accepts. - `list_notification_checks` (read-only): List the checks recorded against one notification submission. Checks are the gates a submission has to clear before it goes out, so a failing check here is the reason a template is stuck rather than live. - `list_providers` (read-only): List configured provider integrations for the workspace. - `get_provider` (read-only): Fetch a single provider configuration by ID. - `list_provider_catalog` (read-only): List the provider integrations Courier supports and the configuration each one expects. This is the catalog of what COULD be connected, not what this workspace has configured — use list\_providers for that. Answers "what can I connect Courier to" and "what do I need in order to set up this provider". - `get_routing_strategy` (read-only): Retrieve a routing strategy by ID. Returns the full entity including routing, channels, and providers. - `list_routing_strategies` (read-only): List the workspace's routing strategies, returning metadata only. A routing strategy decides which channel a notification takes and in what order. Use this to find the rs\_-prefixed strategy ID that get\_routing\_strategy needs for the full definition. - `list_preference_sections` (read-only): List the workspace's preference sections, each with the topics inside it. One call returns the whole opt-in surface: everything a user could subscribe to or opt out of. This is what the workspace DEFINES — use get\_user\_preferences for what a particular person actually chose. - `get_preference_section` (read-only): Get one preference section by ID, including its topics. Use this when you already know which section you need; list\_preference\_sections returns every section with its topics in one call. - `list_preference_topics` (read-only): List the subscription topics inside one preference section. A topic is the individual thing a user opts in or out of, and its ID is what get\_user\_preference\_topic takes. - `get_preference_topic` (read-only): Get one subscription topic within a section, including its default opt-in state. Returns 404 if the section or topic does not exist, or if the topic belongs to a different section — so a 404 here can mean the pairing is wrong rather than the topic missing. - `create_journey`: Create a new journey. Always created as a draft; making it live is a separate step this tool cannot perform. Send two nodes: the trigger, and an exit node last. Both are required — a create with no exit node is rejected, and the API reports that as "exit node must be the last node in the journey" even when no exit was sent at all. Send and delay nodes are added afterwards by replace\_journey, once journey-scoped templates exist. Node ids are server-generated; do NOT include an id field. Example: { name: "Welcome Journey", nodes: \[{ type: "trigger", trigger\_type: "api-invoke" }, { type: "exit" }\], enabled: true }. The result carries a "verification" object read back from the server after the write — check it every time. verified:true means what you asked for is what saved. verified:false names what did not: "fieldMismatches" for node fields that failed to land, "nodeCountMismatch" for a node dropped or added, and "unknownTemplateReferences" for a send node pointing at a template id this… - `get_journey` (read-only): Get a journey by ID. Pass version=draft to retrieve the working draft, or version=vN for a historical version. Defaults to published. - `replace_journey` (can delete or overwrite): Replace (update) a journey draft. Full document replacement — include all nodes and properties in the body, the trigger included; anything omitted is deleted. The journey stays a draft; making the change live is a separate step this tool cannot perform. This is where send, delay, branch and exit nodes are added, and send node template IDs must already be scoped to this journey. The result carries a "verification" object read back from the server after the write — check it every time. verified:true means what you asked for is what saved. verified:false names what did not: "fieldMismatches" for node fields that failed to land, "nodeCountMismatch" for a node dropped or added, and "unknownTemplateReferences" for a send node pointing at a template id this journey does not have — almost always a mistyped id, so re-copy it from the create\_journey\_template or get\_journey response it came from. Fix the specific thing named and send the corrected document. Re-sending an identical call changes n… - `create_journey_template`: Create a notification template scoped to a journey. Always created as a draft; making it live is a separate step this tool cannot perform. The template can then be referenced in journey send nodes. content.elements must be wrapped in a channel block — the API rejects bare elements. Example: { journey\_id: "j-abc", channel: "email", notification: { name: "Welcome Email", tags: \[\], brand: null, subscription: null, content: { version: "2022-01-01", elements: \[{ type: "channel", channel: "email", elements: \[{ type: "text", content: "Hello!" }\] }\] } } }. The result carries a "verification" object confirming the new id is really present on the journey. verified:true means the id in this response is safe to reference from a send node. verified:false means it is not visible yet — re-read the journey before referencing it, and do not create a second template to work around it. An "errorKind" of "unauthorized" means the template was created and only the check was refused. - `put_journey_template_content` (can delete or overwrite): Replace the elemental content of a journey-scoped notification template. Overwrites all elements. The template stays a draft; making it live is a separate step this tool cannot perform. - `put_journey_template_locale`: Set locale-specific content overrides for a journey-scoped notification template. Each element override must reference an existing element by its id. The template stays a draft; making it live is a separate step this tool cannot perform. - `list_journeys` (read-only): List journey templates in the workspace, returning the journey IDs and version state of each. Optionally filter by version (published or draft). - `list_journey_templates` (read-only): List notification templates scoped to a journey. Journey-scoped templates can only be used by send nodes within the same journey. Call this to discover template IDs before wiring send nodes in replace\_journey. - `get_journey_template` (read-only): Get a journey-scoped notification template by notification ID. Pass version=draft to retrieve the working draft (required before the template has been published). Defaults to published. - `get_journey_template_content` (read-only): Fetch the elemental content of a journey-scoped notification template. Pass version=draft for the working draft, or vN for a historical version. Defaults to published. - `get_notification_metrics` (read-only): Delivery funnel for ONE notification template over time: sent, delivered, opened, clicked, errors and undeliverable, per provider and channel, in time buckets. Choosing the window — supply EITHER \`lookback\` OR \`start\` and \`end\` together, NEVER both. Supplying both is rejected. For a relative window like 'the last week', \`lookback\` alone is the whole answer: do not also pin \`start\` and \`end\`. Default is the last 30 days by day. Fine granularities cover shorter windows: HOUR spans at most 7 days and DAY at most 90. How far back a workspace may look also depends on its plan; a request reaching further back is refused with a payment error, which means the plan does not cover that window, NOT that there is no data. A coarser granularity can reach further back than a fine one. Reading the numbers correctly: - The first four counters are NESTED, not separate groups. Every delivered message is also counted in sent, every opened one in delivered, every clicked one in opened. So sent \>= deliver… - `get_tenant` (read-only): Get a tenant by its ID. - `list_tenants` (read-only): List the workspace's tenants. A tenant is a customer or organisation whose users, branding and preferences are scoped separately; this answers "what tenants do I have" and gives you the tenant IDs get\_tenant needs. - `list_tenant_users` (read-only): List the users associated with one tenant. Use this to confirm whether someone actually belongs to the tenant whose branding or preferences you are reasoning about. - `get_user_profile_by_id` (read-only): Get a user profile by their ID. Returns profile data including email, phone, and custom properties. - `get_user_list_subscriptions` (read-only): List the lists one user is subscribed to. Use this when explaining why a user received something — a subscription here is the reason a list-addressed send reached them, and its absence rules that path out. - `get_user_preferences` (read-only): Get a user's notification preferences (subscriptions, opt-outs, channel preferences). - `get_user_preference_topic` (read-only): Get one user's choice for a single subscription topic — whether they opted in or out, and per channel. Use this when you already know which topic is in question; get\_user\_preferences returns all of them at once. - `list_user_tenants` (read-only): List the tenants a user belongs to. Preferences and branding can be scoped per tenant, so this tells you which tenant-scoped settings could apply to this user at all before you go looking for them. - `list_brands` (read-only): List the workspace's brands. A brand is the reusable logo, colors and email styling a notification template renders with; this gives you the brand IDs a template's brand reference points at. - `get_brand` (read-only): Get one brand by ID, including its colors, logo and styling settings. Read this to describe what a template referencing this brand will actually look like. - `courier_installation_guide` (read-only): Get the Courier SDK installation guide for one platform: the install command, a quick-start code sample and the relevant doc links. This is the answer to "how do I integrate Courier" or "how do I get started". Client-side platforms need a JWT to authenticate; each guide says so and names the tool that issues one. - `list_automations` (read-only): List the workspace's automation templates, each with its template ID and whether it has a published or draft version. Answers "what automations already exist here" — this only reads the catalog, it never runs one. - `list_audiences` (read-only): List the workspace's audiences. An audience is a saved filter over user profiles — a dynamic segment — so this answers "who can I target" and gives you the audience IDs that journey audience triggers and send requests refer to. - `get_audience` (read-only): Get one audience by ID, including the filter that defines its membership. Read this to explain why someone is or is not in an audience — the filter is the rule, not a stored member list. Use list\_audience\_members for who currently matches. - `list_audience_members` (read-only): List the users who currently match an audience's filter. Membership is computed, so this reflects profiles as they are right now — a profile change can move someone in or out without the audience itself being edited. - `list_lists` (read-only): List the workspace's lists. A list is an explicit, subscription-based group of users — someone is on it because they were subscribed, not because they match a rule. Optionally filter by an id pattern such as "example.list.\*". - `get_list` (read-only): Get one list by its ID, including its name and current state. - `get_list_subscribers` (read-only): List the users subscribed to a list. Use this to confirm whether someone was actually on a list at all — a subscription here is the reason a list-addressed send reached them. - `list_digest_instances` (read-only): List the digest instances for a digest schedule. Each instance is the events accumulated so far for one user against that schedule, so this shows what is waiting to go out and answers why a digest has not arrived yet — it is still accumulating, or it has nothing in it. - `update_audience`: Create or update an audience with a filter definition. - `delete_audience` (can delete or overwrite): Delete an audience by its ID. - `get_audit_event` (read-only): Get a specific audit event by its ID. - `list_audit_events` (read-only): List audit events in the workspace. Useful for tracking API usage and changes. - `generate_jwt_for_user`: Generate a JWT authentication token for a user. Used for client-side SDK auth (Inbox, Preferences, etc.). - `invoke_automation_template`: Invoke an automation run from an existing automation template. template\_id refers to an existing automation template in the workspace. Example: { template\_id: "auto-onboarding", recipient: "user-123", data: { plan: "pro" } }. - `invoke_ad_hoc_automation`: Invoke an ad-hoc automation with inline steps. Valid step actions: send, send-list, delay, cancel, update-profile, invoke, fetch-data. To cancel a previously started automation, use the cancel\_automation tool instead. - `cancel_automation`: Cancel a running automation by its cancelation\_token. This invokes a second ad-hoc automation with a single cancel step. The token must match the cancelation\_token set when the original automation was started. Note: spelling is "cancelation\_token" (single "l"). - `list_automation_runs` (read-only): List automation runs, newest first. Filter by automation template, status, or a created\_at window to find a run that stalled or errored, then read its steps with list\_automation\_run\_steps. Journey runs are listed by list\_journey\_runs instead. - `list_automation_run_steps` (read-only): List the steps of an automation run in order, with what happened at each. Send steps carry a message\_id to follow with get\_message. - `create_brand`: Create a new brand. The API requires settings — omitting it returns a 400. If you do not have specific brand colors, omit settings and a safe default will be used automatically (black primary, white secondary). Example: { name: "Acme", settings: { colors: { primary: "\#1a73e8", secondary: "\#ffffff" } } }. - `update_brand`: Replace an existing brand with new values. - `delete_brand` (can delete or overwrite): Delete a brand by its ID. - `create_bulk_job`: Create a new bulk job for sending messages to multiple recipients. Workflow: create\_bulk\_job → add\_bulk\_users → run\_bulk\_job. - `add_bulk_users`: Add users to an existing bulk job. - `run_bulk_job`: Run a bulk job, triggering delivery to all added users. - `get_bulk_job` (read-only): Get the status of a bulk job. - `list_bulk_users` (read-only): List the users in a bulk job. - `track_inbound_event`: Track an inbound event that can trigger automations. Requires event name, messageId (for deduplication), and properties. - `create_list`: Create or update a list by list ID. - `subscribe_user_to_list`: Subscribe a user to a list. Creates the list if it doesn't exist. - `unsubscribe_user_from_list` (can delete or overwrite): Unsubscribe a user from a list. - `delete_list` (can delete or overwrite): Delete a list by its ID. - `restore_list`: Restore a previously deleted list. - `bulk_subscribe_to_list` (can delete or overwrite): Replace all subscribers on a list with the given recipients. - `add_subscribers_to_list`: Append subscribers to a list without removing existing subscribers. - `cancel_message` (can delete or overwrite): Cancel a message that is currently being delivered. Returns the message details with updated status. - `resend_message`: Resend a previously sent message. Loads the original send request and enqueues a brand-new send to the same recipient with the same content, producing a new messageId; the original message is unchanged. Rate limited per message (429 on rapid repeats). - `trace_message` (read-only): Trace delivery in one call. Give EXACTLY ONE of message\_id (a single message) or trace\_id (the metadata.trace\_id set on a send, which can span several messages). Returns each matching message with its event history, which carries the status reason when a message is undeliverable. Set include\_output to also return the rendered content each provider received. - `archive_notification` (can delete or overwrite): Archive a notification template by ID. - `publish_notification`: Publish a notification template, making it available for sending. Must be called before send\_message\_template unless the template was created with state: 'PUBLISHED'. Publishes the current draft by default; pass version (e.g. 'v001') to publish a specific historical version. Returns 204 on success. - `update_notification_checks`: Update check statuses for a notification submission. - `cancel_notification_submission` (can delete or overwrite): Cancel a notification template submission. - `create_or_merge_user`: Create a new user profile or merge supplied values into an existing profile (POST). Existing fields not included are preserved. - `replace_profile` (can delete or overwrite): Fully replace a user profile (PUT). All existing data is overwritten; include every field you want to keep. - `patch_profile`: Partially update a user profile via JSON Patch (RFC 6902). Use add/replace/remove operations on specific profile paths. - `delete_profile` (can delete or overwrite): Delete a user profile permanently. - `subscribe_user_to_lists`: Subscribe a user to one or more lists. Creates lists that do not exist. - `delete_user_list_subscriptions` (can delete or overwrite): Delete all list subscriptions for a user. - `send_message`: Send a message to a user using inline title and body content (no template). Optionally specify routing channels. API reference: https://www.courier.com/docs/api-reference/send/send-a-message. - `send_message_template`: Send a message to a user using a published notification template. Only published templates can be sent; publishing a draft is a separate operation. Example: { user\_id: "user-123", template: "nt\_01abc123", data: { name: "Alex", resetUrl: "https://app.example.com/reset" } }. - `send_message_to_list`: Send a message to all subscribers of a list using inline title and body content. API reference: https://www.courier.com/docs/api-reference/send/send-a-message. - `send_message_to_list_template`: Send a message to all subscribers of a list using a notification template. - `create_or_update_tenant`: Create or replace a tenant. Tenants represent organizations or groups that users belong to. - `delete_tenant` (can delete or overwrite): Delete a tenant by its ID. - `update_tenant_preference`: Set the default notification preference for a subscription topic on a tenant. This controls tenant-level defaults — it does NOT set per-user preferences (use the user preferences API for that). The topic\_id must already exist as a subscription topic in the workspace; a 404 means the topic has not been created yet. Example: { tenant\_id: "acme", topic\_id: "marketing-updates", status: "OPTED\_IN", has\_custom\_routing: true, custom\_routing: \["email", "push"\] }. - `delete_tenant_preference` (can delete or overwrite): Remove default notification preference for a topic from a tenant. - `list_tenant_templates` (read-only): List notification templates configured for a tenant. - `get_tenant_template` (read-only): Get a tenant notification template association by template ID. - `replace_tenant_template`: Create or replace a tenant notification template (draft unless published is true). - `publish_tenant_template`: Publish a version of a tenant notification template. - `get_tenant_template_version` (read-only): Get a specific version of a tenant notification template (e.g. latest, published, or v1). - `delete_tenant_template` (can delete or overwrite): Delete a tenant notification template. Returns 204 on success, 404 if the template does not exist for this tenant. - `get_translation` (read-only): Get a translation for a specific locale (e.g. "en\_US", "fr\_FR"). - `update_translation`: Create or update a translation for a specific locale. API reference: https://www.courier.com/docs/api-reference/translations/update-translations-by-locale. - `list_user_push_tokens` (read-only): List all push/device tokens for a user. - `get_user_push_token` (read-only): Get a specific push/device token for a user. - `create_or_replace_user_push_token`: Create or replace a push/device token for a user. - `bulk_add_user_tokens`: Add multiple push/device tokens for a user in one request. Overwrites matching existing tokens. - `patch_user_token`: Apply a JSON Patch (RFC 6902) to a specific push token. - `delete_user_token` (can delete or overwrite): Delete a specific push token for a user. - `update_user_preference_topic`: Update a user's preference for a specific subscription topic (opt in, opt out, or set channel preferences). - `delete_user_preference_topic` (can delete or overwrite): Delete a user's preference for a specific subscription topic, reverting it to the topic's default status. - `add_user_to_tenant`: Add a user to a tenant. - `remove_user_from_tenant` (can delete or overwrite): Remove a user from a tenant. - `bulk_add_user_tenants`: Add a user to multiple tenants at once. A custom profile can be supplied per tenant. - `remove_all_user_tenants` (can delete or overwrite): Remove a user from all tenants. - `bulk_update_user_preferences`: Additively create or update a user's preferences for one or more topics in a single request. Only the topics in the body are touched; existing overrides for other topics are left untouched. Partial-success: valid topics are written and returned in \`items\`, unapplicable ones collected in \`errors\`. - `bulk_replace_user_preferences` (can delete or overwrite): Replace a user's complete set of preference overrides in one request. The topics in the body become the recipient's entire override set: listed topics are created or updated, and every existing override not included is reset to its topic default. An empty \`topics\` array clears all overrides. Validation-atomic (all-or-nothing). - `archive_request` (can delete or overwrite): Archive a send request and all its associated messages by request ID. - `create_routing_strategy`: Create a routing strategy defining how notifications are delivered across channels and providers. - `replace_routing_strategy`: Replace a routing strategy. Full document replacement; missing optional fields are cleared. - `archive_routing_strategy` (can delete or overwrite): Archive a routing strategy. The strategy must not have associated notification templates; unlink all templates before archiving. - `list_routing_strategy_notifications` (read-only): List notification templates associated with a routing strategy. Useful for checking linked templates before archiving. - `invoke_journey`: Invoke a journey run from a journey template. template\_id refers to an existing journey template in the workspace. Example: { template\_id: "j-onboarding", user\_id: "user-123", data: { plan: "pro" } }. - `publish_journey`: Publish the current draft of a journey, making it live and invokable. Pass version to roll back to a prior published version instead of publishing the draft. Returns 404 if there is no draft to publish. - `archive_journey` (can delete or overwrite): Archive a journey. Archived journeys cannot be invoked but existing runs continue to completion. - `list_journey_versions` (read-only): List published versions of a journey, ordered most recent first. - `replace_journey_template`: Replace the draft of a journey-scoped notification template. Full document replacement. Call publish\_journey\_template afterwards to make it live. - `archive_journey_template` (can delete or overwrite): Archive a journey-scoped notification template. Archived templates cannot be sent. - `publish_journey_template`: Publish the current draft of a journey-scoped notification template. Optionally pass version to roll back to a prior version. - `list_journey_template_versions` (read-only): List published versions of a journey-scoped notification template, ordered most recent first. - `cancel_journey` (can delete or overwrite): Cancel journey runs. Supply EXACTLY ONE of cancelation\_token (cancels every run associated with the token) or run\_id (cancels a single run). Cancelation is idempotent: a run that already finished or was already canceled is left unchanged. - `list_journey_runs` (read-only): List journey runs, newest first. Filter by journey, status, or a created\_at window to find a run that stalled or errored, then read its steps with list\_journey\_run\_steps. - `get_journey_run` (read-only): Get one journey run by id: its journey, status, and timestamps. - `list_journey_run_steps` (read-only): List the steps of a journey run in order, with each node and what happened at it. This is how to see where a run stopped and why. - `create_provider`: Create a new provider (integration) configuration. Once routing strategies or notification templates reference this config, credential or settings mistakes can affect live sends—confirm provider key and settings against list\_provider\_catalog before saving. The provider field must be a known Courier provider key. - `update_provider` (can delete or overwrite): Replace an existing provider configuration. Full replacement — retrieve current config with get\_provider first; omitted optional fields are cleared. Changing API keys or settings affects live delivery if this integration is in use. - `delete_provider` (can delete or overwrite): Delete a provider configuration. Returns 409 if the provider is still referenced by routing or notifications. - `create_preference_section`: Create a preference section in your workspace. The section id is generated and returned. Add topics afterwards with create\_preference\_topic. - `replace_preference_section`: Replace a preference section. Full document replacement; missing optional fields are cleared. Topics attached to the section are unaffected. - `archive_preference_section` (can delete or overwrite): Archive a preference section. The section must be empty: delete its topics first, otherwise the request fails with 409. - `publish_preferences`: Publish the workspace's preferences page. Takes a snapshot of every section with its topics under a new published version, making the current state visible on the hosted preferences page. - `create_preference_topic`: Create a subscription preference topic inside a section. The topic id is generated and returned. Fails with 404 if the section does not exist. - `replace_preference_topic`: Replace a topic within a section. Full document replacement: omitted optional fields are cleared, except \`digest\`, which is left untouched when omitted. Pass \`digest: null\` to turn a digest off. - `archive_preference_topic` (can delete or overwrite): Archive a topic within a section. - `list_preference_logs` (read-only): List preference changes, newest first. Each entry is one change a user made to one subscription topic, with the value before it where there was one. Pass user\_id to answer "when did this user opt out, and of what?"; omit it to read the whole environment. Page with paging.cursor while paging.more is true. - `release_digest`: Release a digest schedule early — send what users have collected so far now instead of waiting for the scheduled time. A 204 is also returned when the schedule has no in-progress instances to release. - `release_user_digest`: Release one recipient's held digest for a topic now, instead of waiting for its schedule. Use it to preview a digest, or to let a user flush their own, without releasing everyone else on the schedule. There is no release-everyone form of this call; use release\_digest with a schedule id for that. - `list_broadcasts` (read-only): List broadcasts in the workspace. - `create_broadcast`: Create a broadcast: a one-off message to a list or audience on a single channel. It starts as a draft with no content; add content with put\_broadcast\_content, then send\_broadcast or schedule\_broadcast. - `get_broadcast` (read-only): Get a broadcast by id, including its channel and send or schedule state. - `rename_broadcast`: Rename a broadcast. Content and channel are unchanged. - `delete_broadcast` (can delete or overwrite): Delete a broadcast. - `get_broadcast_content` (read-only): Get a broadcast's Elemental content. - `put_broadcast_content`: Replace a broadcast's content with an Elemental document. Saved as a draft unless state is PUBLISHED. - `send_broadcast`: Send a broadcast now to every member of a list or audience. This delivers real messages. - `schedule_broadcast`: Schedule a broadcast to send later to a list or audience. Cancel with cancel\_broadcast\_schedule. - `cancel_broadcast_schedule` (can delete or overwrite): Cancel a broadcast's scheduled send. The broadcast itself is kept. - `duplicate_broadcast`: Copy a broadcast into a new draft. The original is left unchanged. - `list_preview_devices` (read-only): List the email clients a preview can render on. Each device has a pvd\_ id, a display name, and fields to filter by: category, app, platform, os, os\_version and theme. Use these ids in a device set or in create\_preview\_run. - `list_preview_device_sets` (read-only): List saved preview device sets. Every workspace has a read-only Courier Recommended set that runs can use without creating a set first. - `create_preview_device_set`: Create a named, reusable set of preview devices. - `get_preview_device_set` (read-only): Get a preview device set by id. - `replace_preview_device_set`: Replace a preview device set's name and devices. This is a full replace, so send every device the set should keep. The Courier Recommended set cannot be changed. - `archive_preview_device_set` (can delete or overwrite): Archive a preview device set. Runs that used it keep their own copy of its devices. The Courier Recommended set cannot be archived. - `create_preview_run`: Render a template's email on real email clients and capture screenshots. Pass exactly one of device\_set\_id or device\_ids. Each run is billed to the workspace's previews add-on. The run starts PENDING, so poll get\_preview\_run for the results. - `list_preview_runs` (read-only): List a template's preview runs, newest first. - `get_preview_run` (read-only): Get a preview run with its per-device results and screenshot URLs. Poll until status is COMPLETED or FAILED. The URLs are short-lived and re-signed on every read, so fetch them rather than storing them. ### Connect it Claude Code: ```sh claude mcp add --transport http courier https://mcp.courier.com ``` - Add to Cursor: - Add to VS Code: - Claude.ai and Claude Desktop: Customize, Connectors, "+", Add custom connector, then paste https://mcp.courier.com - ChatGPT: Settings, Apps, Advanced settings, turn on Developer mode, Create, then paste https://mcp.courier.com (this usually works only with servers that use self-serve sign-in or none) JSON for Cursor, Windsurf and other clients that connect to hosted servers: ```json { "mcpServers": { "courier": { "type": "http", "url": "https://mcp.courier.com" } } } ``` ## Questions ### Does Courier have an official MCP server? Yes. Courier publishes its MCP server itself. Courier's own documentation describes it. MartechDB only lists servers a vendor publishes, never community copies. ### What is the Courier MCP server URL? The address is https://mcp.courier.com. ### How do I connect Courier MCP to Claude, ChatGPT or Cursor? In Claude, add https://mcp.courier.com as a custom connector (Customize, Connectors, Add custom connector). In Cursor, use the Add to Cursor link on MartechDB's page, or paste the JSON settings into your mcp.json. In Claude Code, run: claude mcp add --transport http courier https://mcp.courier.com ### What can the Courier MCP server do? It offers 173 tools, including list\_messages, get\_message, get\_message\_content, get\_message\_history and list\_notifications (as listed on 1 Nov 2026). 72 are marked read-only and 33 can delete or overwrite data. ### Is the Courier MCP server in the official MCP Registry? No. Courier hasn't published it to the official MCP Registry. ### Is the Courier MCP server working? Yes. It answered our most recent check. We last checked it on 1 Nov 2026. ### What are the alternatives to Courier's MCP server? In Marketing automation, the most agent-friendly alternatives with an official MCP server are Kit (94/100), GetResponse (94/100), Quentn (91/100), Brevo (89/100) and vbout (89/100). Courier scores 65/100 on the same index. ## Change history - 2026-10-27: Added to MartechDB with Courier MCP ## Alternatives to Courier's MCP server In Marketing automation, the most agent-friendly first: - [Kit](https://martechdb.com/vendors/kit.md) (kit.com), Agent Readiness Index 94/100 - [GetResponse](https://martechdb.com/vendors/getresponse.md) (getresponse.com), Agent Readiness Index 94/100 - [Quentn](https://martechdb.com/vendors/quentn.md) (quentn.com), Agent Readiness Index 91/100 - [Brevo](https://martechdb.com/vendors/brevo.md) (brevo.com), Agent Readiness Index 89/100 - [vbout](https://martechdb.com/vendors/vbout.md) (vbout.com), Agent Readiness Index 89/100 ## Get this data - API: `curl https://martechdb.com/api/v1/vendors/courier.com` - MCP: `claude mcp add --transport http martechdb https://martechdb.com/mcp`, then ask about Courier. - Web page: https://martechdb.com/vendors/courier