---
name: treater-connect
description: Connect an AI agent to a user's Treater account through the remote MCP server, using native OAuth integration or a terminal client. Use for connection setup and troubleshooting; load Treater's server-provided skills for business workflows after connecting.
---

# Connect to Treater

This is a setup guide for AI agents, served as plain text. It is not a login page or an OAuth endpoint. Every command below is meant to be run exactly as printed.

Connect this agent to the user's Treater account and verify that tools are available. MCP access is granted in **Treater Air** (`https://air.trytreater.com`), not the main Treater app (`app.trytreater.com`), which has no MCP or API settings. The user signs in to Treater Air and chooses their brand or organization on its consent screen. Reading this document does not itself create a connection or grant permissions to the host platform.

## Fast path for the terminal path

These steps come from one onboarding: Meta Muse on the terminal path, October 2026. They have not been tested on other platforms.

1. Write the client configuration (below) before starting authorization.
2. Have the user sign in to `https://air.trytreater.com` in the browser the agent will use.
3. Agree with the user, before consent, which brand or organization to connect and whether the agent will place calls or edit campaigns (that needs **Read and make changes**).
4. Start authorization, have the user consent in one pass, and get the callback back to the listener (relay it from the shell if the browser cannot reach it).
5. Confirm the client stored tokens, then run the checks in "Verify and start work".

## Connection details

| Setting               | Value                                                                                          |
| --------------------- | ---------------------------------------------------------------------------------------------- |
| Server name           | Treater                                                                                        |
| Server URL            | `https://mcp.trytreater.com/mcp`                                                               |
| Transport             | Streamable HTTP                                                                                |
| Authentication        | OAuth with PKCE; discover endpoints and register the client through the MCP authorization flow |
| Read access           | `mcp:read offline_access`                                                                      |
| Read and write access | `mcp:read mcp:write offline_access`                                                            |
| Resource metadata     | `https://mcp.trytreater.com/.well-known/oauth-protected-resource/mcp`                          |

Read access lets the agent inspect campaigns, calls, contacts and results. Placing calls, creating or editing campaigns, and adding contacts or targets need write access: request `mcp:write` and have the user keep **Read and make changes** on the consent screen, which is the default when write access is requested. A connection approved as read only will connect and list tools, then refuse every change.

The brand or organization the user picks decides whose data the agent sees and changes. A user can belong to several, and a connection to the wrong one looks exactly like a connection to the right one, so confirm the target with the user before consent and report it after.

Identity/email scopes alone do not grant MCP access. Do not substitute a shared API key, an administrator account, or another user's token.

## Choose the supported path

Reuse an existing working Treater connection. Otherwise prefer the host's native custom MCP or plugin integration. An agent with terminal access can use the terminal path below if the host permits package installation and outbound HTTPS. A skill cannot add those capabilities to a platform that lacks them.

Always have the user approve access on Treater's own consent page. Do not route them through a host platform's paid upgrade to connect, and do not ask them to paste passwords, codes or bearer tokens into chat.

### Native MCP or plugin integration

Add the server URL above with OAuth authentication. Let the client handle discovery, PKCE, token storage and refresh. The user completes sign-in, email verification if requested, and tenant/permission selection in the browser.

If the agent can add an MCP server to its own configuration, do it and hand the user only the sign-in. If it cannot, tell the user the exact steps for their client, with the server URL, and wait for them to finish before continuing.

### Platform notes

Each note says where it comes from. "Tested" means a real connection to Treater worked. "From the provider's docs" means it has not been tried with Treater yet. For a platform not listed, check which capabilities that environment actually exposes, try its native MCP integration first, and use the terminal path only if it has a shell, package installation and outbound HTTPS.

- **Meta Muse (tested, October 2026, terminal path):** the browser and the shell run in separate environments, so the browser could not reach the loopback callback. Relaying the callback URL from the shell worked (see below). The platform's own connector page showed a paid-plan upgrade, and the user chose Treater's consent page through the terminal path instead.
- **Claude Code (from [Anthropic's docs](https://code.claude.com/docs/en/mcp), not yet tested with Treater):** run `claude mcp add --transport http treater https://mcp.trytreater.com/mcp`, then `/mcp` in Claude Code, or `claude mcp login treater` from a shell, and sign in through the browser. If the redirect fails with a connection error, paste the full callback URL from the browser's address bar at Claude Code's prompt.
- **Claude apps: claude.ai, desktop and mobile (from [Anthropic's help center](https://support.claude.com/en/articles/11175166-getting-started-with-custom-connectors-using-remote-mcp), not yet tested with Treater):** Claude cannot add connectors itself, so give the user these steps. On Free, Pro and Max plans: Customize → Connectors → + Add → Add custom connector, then enter the name Treater and the server URL. On Team and Enterprise plans, an owner first adds it under Organization settings → Connectors → Add → Custom → Web. Each user then connects, approves in Treater, and enables Treater in the conversation.
- **ChatGPT (published Treater plugin):** ChatGPT cannot add plugins itself, so give the user these steps: open https://chatgpt.com/plugins/plugin_asdk_app_6adfacf523f48191bbcfdf9127d7ca51, add the Treater plugin, connect, approve in Treater, and turn Treater on from the tools menu in a chat. The plugin serves Growth (organization) workspaces only; for a brand workspace, add the server URL as a custom MCP server instead. On Business, Enterprise and Edu, a workspace admin may need to allow the plugin first.
- **Grok (from [xAI's docs](https://docs.x.ai/grok/connectors), not yet tested with Treater):** Grok cannot add connectors itself, so give the user these steps: open https://grok.com/connectors, click New Connector → Custom, enter the server URL, connect and approve in Treater. On Grok Business and Enterprise, a team admin first provisions the connector in the xAI console.
- **OpenAI Dot (no documentation or test):** OpenAI's docs don't mention Dot. Whether Dot can use a ChatGPT plugin is unconfirmed, so find out what that environment exposes before choosing a path.
- **Instinct (no documentation or test):** nothing is known yet about its MCP support. Find out what that environment exposes before choosing a path.

### Terminal path without native MCP settings

Use MCPorter, an MCP client that discovers tools and calls them from the shell. These commands use version 0.14.3 and require Node.js 24 or newer. Run them in the agent's persistent working directory so later sessions can reuse the same configuration and OAuth credential store.

```sh
npx --yes mcporter@0.14.3 --config ./treater-mcp.json config add treater https://mcp.trytreater.com/mcp --auth oauth --oauth-requested-scope 'mcp:read mcp:write offline_access'
npx --yes mcporter@0.14.3 --config ./treater-mcp.json --oauth-timeout 600000 auth treater --no-browser
```

For an inspect-only connection, use `'mcp:read offline_access'` instead. Do not replace a working connection just because this guide was loaded; changing the scopes of an existing connection requires new consent.

Keep the authorization command running; it waits up to 10 minutes. Open the authorization URL it prints in the agent's browser and let the user sign in and approve. Complete consent in one pass: reloading or re-opening the consent page regenerates it and resets the brand and access choices.

After approval, Treater redirects to the loopback callback the command printed (`http://127.0.0.1:<port>/callback?...`).

- **Browser and shell on the same machine:** the command receives the callback by itself.
- **Browser and shell in separate environments** (tested on Meta Muse; the browser shows a connection error on `127.0.0.1`): the failed page's address bar still holds the full callback URL. Read it from the address bar as text, never from a screenshot, and deliver it from the shell while the command is still waiting:

  ```sh
  curl -sS 'PASTE_THE_FULL_CALLBACK_URL_HERE'
  ```

  **Deliver the whole URL byte for byte, including the `iss` parameter.** Without `iss` the client rejects the code after showing "Authorization successful", and the code is spent.

The success page in the browser is not proof of a connection. Authorization worked only when the `auth` command exits reporting stored credentials and a tool call succeeds. Authorization codes are single-use and short-lived: if redemption fails, start a new `auth` run instead of resending the same URL.

MCPorter stores credentials separately from this configuration and refreshes them when needed. Its default vault is `~/.mcporter/credentials.json`, or `$XDG_DATA_HOME/mcporter/credentials.json` when configured. Preserve that private store in the same agent environment; do not copy its contents into messages, shared files or source control. Treat the authorization and callback URLs as temporary operational output rather than links to publish.

## Verify and start work

For a terminal connection:

```sh
npx --yes mcporter@0.14.3 --config ./treater-mcp.json list treater --schema
npx --yes mcporter@0.14.3 --config ./treater-mcp.json resource treater
```

1. **List tools with schemas.** Expect a non-empty list of Treater tools. A sign-in page or loading this guide does not verify anything.
2. **List resources.** Expect `skill://<name>/SKILL.md` entries: the server's workflow playbooks for this tenant. If the host shows tools but not resources, the load-skill tool returns the same text by name.
3. **Make one harmless real call,** such as listing the tenant's campaigns, with `npx --yes mcporter@0.14.3 --config ./treater-mcp.json call treater.<tool> ...`. Expect data from the brand or organization the user picked.

For a native connection, use the host's tool and resource discovery for the same three checks.

Report whether the connection works, whether it permits writes, and which tenant the user selected. Setup alone does not authorize business mutations. Continue with the user's requested work under their approved permissions.

## Calls and outreach campaigns: read the skills first

Before answering questions about how calls behave or doing any outreach work, list the server's skills and read the ones that match the task. They hold the current workflow, defaults and rules for this tenant, and they change with the product, so read them each session rather than relying on earlier knowledge. They cover, among others:

- outreach best practices: how calls and emails behave, and what to tell the user about call behavior;
- writing call prompts: read before writing or editing any call prompt and before placing a call;
- building and running a campaign end to end: goal, prompt, voice, targets, test calls, launch;
- finding and adding leads, and auditing how a running campaign is doing.

A typical flow for mass outreach is: read the skills; agree with the user on the goal, who to contact and what counts as success; build the campaign with its prompt; place a test call and review it with the user; then launch and monitor. Launching, adding targets and placing calls reach real people, so get the user's explicit go-ahead before each.

Some tools, such as placing a call with a custom prompt and saving a campaign prompt, take `skillTokens`: one token for each skill the tool needs. The token appears at the top of the matching skill when it is read. If a call arrives without the tokens it needs, the tool refuses and names the skills: load each one, follow it, and retry with all their tokens. Tokens are tied to this user and tenant and expire after a few hours, so read the skill again in each new session.

## Troubleshooting

- **Instant HTML 403 (AWS/ALB page) with no OAuth challenge:** the request was blocked at the network edge, not by sign-in. Stop retrying and debugging the client; ask the user to contact Treater with the time of the attempt and the agent's egress IP if known.
- **JSON 401 with an OAuth challenge:** follow the client's authentication/refresh flow. Reauthorize only if refresh is rejected or the grant has been revoked.
- **403 after sign-in:** inspect the response for missing scopes, unverified email or missing brand/organization membership. Have the user select an authorized tenant or approve the needed scopes.
- **Changes refused on a working connection:** the user approved Read only. Re-run authorization with `mcp:write` and have them choose Read and make changes.
- **"OAuth issuer validation failed":** the callback reached the client without `iss`. Start a new `auth` run and deliver the complete callback URL.
- **Callback timeout or `ERR_CONNECTION_REFUSED` on `127.0.0.1`:** relay the callback URL from the shell as described above, before the 10-minute wait ends.
- **429:** honor `Retry-After` and reduce concurrency. Shared provider egress IPs can share an edge limit.

The user can disconnect this client, including leftovers from failed attempts, in Treater Air's Account → Connected apps. For terminal-local cleanup, use MCPorter's configuration logout command; removing local credentials alone does not revoke server-side authorization.

## References

- [ChatGPT custom MCP servers](https://developers.openai.com/apps-sdk/deploy/connect-chatgpt)
- [Claude Code MCP setup](https://code.claude.com/docs/en/mcp)
- [Claude custom connectors](https://support.claude.com/en/articles/11175166-getting-started-with-custom-connectors-using-remote-mcp)
- [MCPorter configuration and scope selection](https://github.com/openclaw/mcporter/blob/main/docs/config.md)
- [MCPorter OAuth and remote browser callbacks](https://github.com/openclaw/mcporter/blob/main/docs/adhoc.md)