MCP server

SendLit exposes the same team-scoped email capabilities through a Model Context Protocol (MCP) server over stateless Streamable HTTP at:

https://api.sendlit.app/mcp

For a local installation, replace the origin with the API origin configured in your environment, for example http://localhost:5000/mcp.

Connect and authenticate

SendLit supports both the current 2026-07-28 protocol and the existing 2025-11-25 Streamable HTTP initialize handshake. Modern clients may call server/discover, then tools/list and tools/call; existing clients begin with initialize. Every request is self-contained: there is no MCP session ID or retained server-side transport state.

The retired SSE transport is not supported. In particular, GET /mcp is not an MCP endpoint; clients must use HTTP POST to /mcp.

Current clients construct the protocol envelope and the MCP-Protocol-Version, Mcp-Method, and Mcp-Name headers. Do not set those headers manually unless you are implementing an MCP client.

Authenticate with one of these headers:

Authorization: Bearer <oauth-access-token>

or:

x-sendlit-apikey: sl_live_...

OAuth-capable clients should discover the protected-resource metadata before starting authorization:

GET /.well-known/oauth-protected-resource
GET /.well-known/oauth-protected-resource/mcp
GET /.well-known/oauth-authorization-server
GET /.well-known/openid-configuration

OAuth authorization, consent, token, introspection, revocation, and userinfo endpoints are provided under /api/auth/oauth2/*. SendLit supports pre-registered clients, Client ID Metadata Documents (CIMD), and Dynamic Client Registration (DCR). For CIMD, the OAuth client_id is the HTTPS URL of the client's metadata document. Modern clients should prefer CIMD; DCR remains available for existing clients such as MCP Inspector.

Use Authorization Code with S256 PKCE, request only the scopes your client needs, and keep any refresh token in the client's secure credential store. The authorization request must include an explicit, non-empty scope; SendLit does not turn a missing value into a full-access grant. Every authorization requires a SendLit user to sign in, select a team when necessary, and approve consent.

API keys always select one fixed team and currently grant the complete MCP tool set for that team. Dashboard session cookies and X-Sendlit-Team-Id are not accepted as MCP authentication.

OAuth clients (including MCP clients like Claude) have no way to send a custom header during authorization, so a multi-team account instead picks a team as part of the OAuth flow itself: after login, and before the consent screen, the account is shown a "select a team" step (mirroring how apps like Notion resolve their own multi-workspace ambiguity). The chosen team is baked into the issued access token and used for every subsequent request — no header needed. Accounts with exactly one team skip this step entirely.

OAuth scopes

OAuth access is default-deny per tool. Read and write permissions are separate:

contacts:read, contacts:write
templates:read, templates:write
media:read, media:write
sequences:read, sequences:write
emails:read, emails:send
settings:read, settings:write
esp:read, esp:write
teams:read, teams:write
api_keys:read, api_keys:write
feedback:read, feedback:write
delivery_events:read
suppressions:read, suppressions:write

Available tools

Contacts and segments

list_contacts, get_contact, create_contact, update_contact, delete_contact
add_contact_tag, remove_contact_tag, get_contact_deliveries
list_segments, get_segment, create_segment, update_segment, delete_segment

Segments save reusable filters over contact fields, tags, subscription state, signup date, and custom fields.

Templates and media

list_system_templates, list_templates, get_template, create_template, update_template, duplicate_template, delete_template
list_media, get_media, update_media, delete_media, list_media_references

Templates and media are scoped to the selected team. Template list tools accept an optional purpose filter; create_template requires a purpose and returns the computed requiredVariables. System templates expose transactional variable descriptions and examples, but are starters rather than team-owned sendable templates. Use duplicate_template to copy or safely convert one.

Template and sequence-email content is validated as a complete SendLit email document on every write. The style must include colors, typography.header, typography.text, typography.link, interactives, and structure; blocks must be one of text, link, image, separator, or footer. Metadata supports only optional previewText and an optional utm object with source, medium, and campaign strings. For AI-created content, start with list_system_templates and duplicate_template rather than constructing a document shape from scratch.

Broadcasts and sequences

Broadcasts use the sequence resource with one email and an audience filter. Sequence tools include:

list_sequences, get_sequence, create_sequence, update_sequence
add_sequence_email, update_sequence_email, delete_sequence_email
start_sequence, pause_sequence, get_sequence_stats, get_sequence_subscribers

Use start_sequence only after the audience, trigger, email content, delays, and optional tag actions are correct. Use pause_sequence to stop future sequence processing.

Transactional email

send_email sends one API-triggered email.
get_email retrieves one delivery record.
list_emails lists transactional delivery records.

Transactional sends are separate from broadcasts and sequences; they do not enroll a contact or use a campaign audience. send_email accepts only team-owned transactional templates and reports template_not_transactional or the missing variable paths without creating a send. Broadcast and sequence tools accept only marketing templates and report template_not_marketing.

Sending configuration

get_general_settings, update_general_settings
get_esp_config, update_esp_config, delete_esp_config, send_test_email
list_esps, create_esp, get_esp, update_esp, delete_esp, test_esp

The ESP tools manage the team’s sending providers and default provider. Secrets are accepted for writes but are not returned in read responses.

Teams and API keys

list_teams, create_team, rename_team, delete_team
list_api_keys, create_api_key, delete_api_key

The full API key secret is returned only by create_api_key. Store it immediately; it cannot be recovered from a later listing.

Delivery feedback and suppressions

get_esp_feedback_connection, upsert_esp_feedback_connection, test_esp_feedback_connection, delete_esp_feedback_connection
list_delivery_events, get_delivery_event
list_suppressions, get_suppression, release_suppression

Delivery-feedback connections are supported only for providers with a reviewed asynchronous feedback adapter. Releasing a SendLit suppression does not remove a provider-native suppression, and complaint suppressions are not releasable through the owner API.

Example client configuration

The exact configuration shape depends on the MCP client. For clients that support a URL-based MCP server entry, use:

{
    "mcpServers": {
        "sendlit": {
            "url": "https://api.sendlit.app/mcp",
            "headers": {
                "x-sendlit-apikey": "${SENDLIT_API_KEY}"
            }
        }
    }
}

Prefer the client’s secure secret-store or environment-variable mechanism. Do not paste a live API key into a checked-in configuration file.

Operational limits

The MCP endpoint is rate limited to 60 requests per minute. High-impact tools such as sending email, activating sequences, testing ESPs, managing API keys, deleting teams, and releasing suppressions are limited to 20 requests per minute. A missing or invalid credential returns HTTP 401, a missing OAuth scope returns an insufficient_scope tool error, an unsupported protocol revision is rejected, and a non-JSON request returns HTTP 415. Because requests are stateless, retry only operations that are safe to repeat.

On this page