Connect your AI agent to Textdrip

1. What is this?

Textdrip MCP is a hosted Model Context Protocol server that exposes the Textdrip SMS API as a set of tools your AI agent can call in natural language. Instead of writing code against the REST API, the agent just says “send Jane a follow-up” and the tool call happens.

https://mcp.textdrip.ai/mcp

2. Before you start

1. A Textdrip account with API access enabled. If you can log in at app.textdrip.com and see an API token under your profile, you’re good.
2. An MCP-capable AI client. Supported ones are listed below.
3. A web browser. You’ll sign in to Textdrip once through its normal login page.

3. How authentication works

You’ll see this flow the first time you use the connector. After that, your AI client holds a token and reconnects silently.

4. Claude Desktop

Claude Desktop doesn’t speak the MCP HTTP transport natively yet, so we use a tiny bridge called mcp-remote that ships with npx.

Step 1. Open the config file

Step 2. Add the Textdrip entry

{
  "mcpServers": {
    "textdrip": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.textdrip.ai/mcp"
      ]
    }
  }
}

Step 3. Restart Claude Desktop

Fully quit (⌘Q on macOS) and reopen. The first time you call a Textdrip tool, a browser window pops up for the Textdrip sign-in. Click Allow access and you’re connected.

Try it

In a new chat, say:

Send an SMS to +15555551234 saying "Thanks for reaching out, we'll follow up by Friday."

5. Claude Code (CLI)

Claude Code has first-class MCP support. Add the server with one command:

claude mcp add --transport http textdrip https://mcp.textdrip.ai/mcp

Then run claude in any project. The first tool call triggers the OAuth popup; after that, the session is remembered.

Inside Claude Code:

> find the contact with email jane@example.com and add her to the welcome campaign

6. ChatGPT (custom connector)

ChatGPT Enterprise / Team / Edu / Pro accounts can add custom MCP connectors. Personal Plus accounts don’t have this toggle yet.

Enable the connector in any chat and try:

Who are my most recent 10 conversations, and which ones haven't replied yet?

7. OpenAI Agents SDK / Responses API

If you’re building with the OpenAI API directly, the Responses API supports MCP servers as a first-class tool type. The model uses our tools alongside your own.

Python

from openai import OpenAI
client = OpenAI()

response = client.responses.create(
    model="gpt-4.1",
    tools=[{
        "type": "mcp",
        "server_label": "textdrip",
        "server_url": "https://mcp.textdrip.ai/mcp",
        "require_approval": "never",   # or "always" for human-in-the-loop
    }],
    input="Send a text to +15555551234 saying the demo is confirmed for 2pm.",
)
print(response.output_text)

Node

import OpenAI from "openai";
const client = new OpenAI();

const response = await client.responses.create({
  model: "gpt-4.1",
  tools: [{
    type: "mcp",
    server_label: "textdrip",
    server_url: "https://mcp.textdrip.ai/mcp",
    require_approval: "never",
  }],
  input: "List my phone numbers and pick the cleanest one for outbound.",
});
console.log(response.output_text);

8. Any other OAuth-capable MCP client

Textdrip MCP implements the full OAuth 2.1 spec used by the MCP ecosystem, so any compliant client can connect by pointing at https://mcp.textdrip.ai/mcp. The client discovers everything else automatically:

• Resource metadata: https://mcp.textdrip.ai/.well-known/oauth-protected-resource
• AS metadata: https://mcp.textdrip.ai/.well-known/oauth-authorization-server
• Dynamic client registration: POST /oauth/register
• Auth flow: authorization code + PKCE S256
• Refresh rotation: 90-day refresh tokens, 1-hour access tokens

The registration contract

POST /oauth/register is open and is the intended path for a self-built client. You do not need to be allowlisted, and the ChatGPT and Claude options above are just pre-filled versions of this same flow. Four things about the response surprise people, so they are spelled out here:

• No client_secret is issued. Every client is public: token_endpoint_auth_method is always "none" and PKCE does the work instead. code_challenge_method=S256 is required and plain is rejected.
• The server sets some fields regardless of what you send. grant_types always comes back as ["authorization_code", "refresh_token"], and any other metadata you submit beyond redirect_uris and client_name is not stored and not echoed. A response that does not mirror your request is expected, not an error.
• There is no registration read-back. We do not implement RFC 7592: there is no registration_access_token, no registration_client_uri, and no GET on /oauth/register. The 201 body is the only copy of your registration, so save it. If you lose it, register again: a replacement costs nothing and an unauthorized client record carries no permissions.
• redirect_uris must be HTTPS, or HTTP on loopback (127.0.0.1, localhost, [::1]). At /oauth/authorize the redirect_uri has to match a registered one exactly. A trailing slash or a different port counts as a different URI and returns “Invalid redirect_uri”.

The exact registration response

A successful POST /oauth/register returns 201 with exactly these six fields, and no others:

{
  "client_id":                   "32 bytes, base64url",
  "client_name":                 "what you sent, or "Unnamed MCP client"",
  "redirect_uris":               ["what you sent, verbatim"],
  "grant_types":                 ["authorization_code", "refresh_token"],
  "token_endpoint_auth_method":  "none",
  "client_id_issued_at":         unix seconds
}

Note what is not there. scope and response_types are not returned, because they are not stored: the client record has six columns and neither of those is one of them. If your client validates the response by comparing it field by field against what you submitted, it will report a mismatch every time, on three counts. scope is absent, response_types is absent, and grant_types comes back as a superset of whatever you asked for. That is this server's behaviour for every registration, not a problem with yours, and the registration is still usable. Only redirect_uris and client_name are carried through from your request.

Treat the registration as good if /oauth/authorize accepts your client_id and redirect_uri. That is the only check that reflects server state.

Scope, and what a grant actually permits

There is one scope, mcp, and it is the only value in scopes_supported. /oauth/authorize defaults to it when scope is omitted.

There is no narrower grant. We do not currently offer a read-only or catalog-only scope, a per-tool permission model, or a restricted test tenant, and the scope string on a token is not enforced against individual tools. An authorized session can reach all 17 tools, including send_message, schedule_message, delete_contact and set_contact_pipeline, against the Textdrip account that signed in. If you need a restricted grant, the only reliable boundary today is a separate Textdrip account holding only the data you want exposed. Do not rely on a restriction that lives in your own client: it limits your client, not the token.

Sessions and per-tool call history are visible to Textdrip support, and a session can be revoked on request.

Protocol versions and response format

• Transport is Streamable HTTP, at https://mcp.textdrip.ai/mcp. The deprecated SSE transport and stdio are not offered.
• Protocol versions accepted: 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05 and 2024-10-07. A client that sends no version negotiates 2025-03-26.
• Responses are server-sent events, with content type text/event-stream, not plain JSON. Your Accept header must include both application/json and text/event-stream or the transport will reject the request before it reaches a handler.
• mcp-session-id comes back on the initialize response and must be echoed on every later request. DELETE /mcp ends the transport session. This is separate from the OAuth session, which outlives it.

Metadata-only discovery still requires authorization. initialize and tools/list sit behind the same bearer check as everything else, so there is no way to read the tool catalog without a token, and a token requires a Textdrip sign-in. What you can rely on is that neither call touches your account: both are served from a static definition, make no call to the Textdrip API, and are not written to the tool-call audit log. Signing in and listing tools reads no customer data and sends no messages. If you only want to see the catalog, section 9 of this page lists all 17 tools and needs no account at all.

The two .well-known documents are authoritative for endpoints and supported parameters. If they disagree with this page, believe them.

MCP Inspector is a great way to test the connection before wiring it into an agent:

npx @modelcontextprotocol/inspector
# then paste https://mcp.textdrip.ai/mcp into "Server URL"
# and click Connect, and the OAuth popup will appear

9. What the AI can do

The agent gets 17 tools organized in three categories:

10. Troubleshooting

The popup never appears

Your MCP client might have cached a bad state. For Claude Desktop / Claude Code, delete the mcp-remote cache and retry:

rm -rf ~/.mcp-auth
# then restart the client

“Missing Textdrip credentials” after sign-in

Your Textdrip account doesn’t have an API token provisioned. Log in to app.textdrip.com, check your profile / API settings, or contact Textdrip support to enable API access.

Tools work for a while, then start returning 401

Access tokens are valid for 1 hour. Well-behaved clients refresh silently using the refresh token (90-day lifetime, rotates on every use). If you manually revoked access from Textdrip, re-run the connector to re-auth.

My client reports a registration metadata mismatch

Expected, and your registration is probably fine. The 201 body omits scope and response_types entirely and widens grant_types, so a strict field-by-field validator fails on three counts for every client we issue. See the exact registration response for the full list of fields you get back.

I registered a client and cannot verify the settings

There is no endpoint that reads a registration back, and support cannot confirm a client configuration from an email address, because a client_id is not tied to an identity until someone signs in to Textdrip with it. Verify it yourself by running the flow against MCP Inspector: if /oauth/authorize accepts your client_id and redirect_uri, the registration is good. If it still fails, send support the HTTP status, the error code and the UTC timestamp, never an API token.

Rate limited

The /mcp endpoint is capped at 60 requests per minute per session. Normal conversational use never hits this; bulk operations should pace themselves.

Something else

Contact Textdrip support with the client you’re using, what you tried, the HTTP status and error code you got back, and the UTC timestamp. Please do not send API tokens or secrets: we never need one to help.