Telerivet provides a Model Context Protocol (MCP) server that allows AI agents and LLM-based tools such as Claude and ChatGPT to interact with the Telerivet REST API using the standard MCP interface.
Telerivet's MCP server enables AI agents to perform a wide range of actions within Telerivet, including sending and scheduling messages, retrieving data and usage statistics, importing contacts, and configuring projects, routes, and automated services.
The MCP endpoint is available at:
https://api.telerivet.com/mcp
MCP clients connect via Streamable HTTP transport using JSON-RPC 2.0 messages over HTTP POST requests.
The MCP endpoint requires authentication via OAuth 2.0.
MCP clients that support OAuth Client ID Metadata Documents (CIMD) can connect without any manual configuration: Telerivet registers it automatically the first time a user authorizes it. Telerivet does not support Dynamic Client Registration.
Setup instructions are available for the following MCP clients:
For MCP clients that do not support Client ID Metadata Documents, an OAuth Client must be configured manually. To allow using another MCP client that does not support CIMD, you can add a new OAuth Client in your Telerivet organization and configure the OAuth callback URLs required by the MCP client. (The service providing the MCP client may specify their OAuth callback URLs in their documentation.) When an OAuth Client is manually configured in this way, it will only be accessible by users within your own Telerivet organization.
Organization administrators can control what each approved MCP client is allowed to do within their organization on the Connected Applications page (also linked from your organization's Developer API page). Click an application to view or change its settings. These settings apply to every user's access to that application within the organization, regardless of the permissions users granted when connecting it.
Required permission – which users in the organization can authorize the application (all users, organization administrators only, or organization and project administrators only).
Allowed actions – for each category of action, whether the application may perform it on its own, whether a user must approve each action, or whether it is not allowed at all:
| Action | Description | Options | Default |
|---|---|---|---|
| Reading data | Looking up contacts, messages, statistics, and other project data. | Allowed, Not allowed | Allowed |
| Creating and updating data | Creating and editing contacts, groups, services, draft campaigns, routes, and other project data. | Allowed, Require approval, Not allowed | Allowed |
| Sending messages and triggering services | Sending or scheduling messages and calls to contacts, triggering automated services, and running scripts. | Allowed, Require approval, Not allowed | Require approval |
| Deleting data | Deleting contacts, messages, services, and other project data. | Allowed, Require approval, Not allowed | Require approval |
| Making external web requests | Making requests to external websites and third-party APIs from scripts this application runs. | Allowed, Not allowed | Allowed |
When a category is Not allowed, the corresponding MCP tool (such as send_api or delete_api) is hidden from the MCP client, and any API request in that category is refused.
The run_script tool follows the strictest setting among sending, creating/updating, and deleting data.
Some applications specify their own defaults – for example, an autonomous agent that needs to send messages without a user present. When an application's default differs from the standard default, the Connected Applications page notes the application's default next to the setting. Your organization's setting always takes precedence.
Allowed permissions – the types of data and actions the application can access in this organization. Unchecking a permission blocks the corresponding API actions for all users of the application in the organization, even if a user granted that permission when connecting it.
Revoke access – removes the application from your organization's approved applications and revokes all existing access tokens for it in your organization.
Applications owned by your own organization (added via Add OAuth Client) don't need approval, and their allowed actions are configured on the application's own settings page instead.
When a category of action is set to Require approval on the Connected Applications page, the MCP client can't perform those actions until a user explicitly approves each one. By default, this applies to sending messages and triggering services, and to deleting data.
Actions in the sending category include sending or scheduling messages and calls, resending messages, triggering automated services, creating batch tasks, simulating incoming messages,
editing scheduled messages or campaigns, activating an automated service or changing an active service's configuration, creating webhooks or changing webhook URLs,
changing a route's phone number or provider settings, changing the project's default route, and running scripts with the run_script tool.
The deleting category includes all delete methods, as well as reducing a project's message retention.
Depending on the MCP client, you can approve an action in one of the following ways:
If the MCP client supports MCP elicitation (using MCP protocol version 2026-07-28 or later), the MCP client prompts you to approve the action directly, with a plain-language description of what the action will do and which project it affects. If you approve, the action is performed immediately. If you decline, the action is not performed and the AI model is told not to retry it.
If the MCP client supports the MCP Apps extension, the AI model can use the draft_message tool
to show you an editable draft of a text message, including the recipients.
Clicking Send approves sending that exact message to those recipients.
If the MCP client doesn't support either of the above, or the action can't be approved that way, the AI model receives a link to an Approve Action page in the Telerivet web app, and should ask you to open it. This page shows the application, project, a description of the action, and the full request details. After clicking Approve, return to the MCP client and ask it to try again.
To approve an action, you must have the permission that the action itself requires (for example, permission to send messages in the project). Approving an action doesn't grant the application any additional permissions.
run_script don't require separate approval.confirmation_required, and the error message includes an approval link.
Applications that need to perform these actions without a user present (such as server-side integrations or autonomous agents) require an organization administrator to set the category to Allowed.Message Review. Independently of the above, if a project has Message Review enabled in its Messaging Settings, messages sent via the API (including via MCP) that exceed the configured limits are held as pending messages until a reviewer approves them, the same as messages sent from the web app.
The MCP server currently exposes the following tools:
The tools and API methods exposed by the MCP server may change over time.
The links below show the JSON returned by the MCP server, which may help to get an understanding of the available tools and API methods:
The scopes granted to your OAuth token, along with your organization's controls for the application, determine which tools and API methods are available. Methods requiring a scope that your token does not have, or that your organization does not allow for the application, will be excluded from the list.