> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getinteract.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP servers

> Connect a platform's MCP server so agents can read live data and propose changes for approval.

## What an MCP connector adds

An MCP connector points Interact at a remote [Model Context Protocol](https://modelcontextprotocol.io) server — the way platforms like Notion and Meta expose their own tools to AI agents. Attaching one to an agent gives it two things:

* **Read tools** it can call directly, to pull live data during a conversation or scheduled job.
* **Write tools** it can never call directly. Those only reach the platform through a proposal you approve in the Decisioning inbox.

Every tool discovered on a server starts **disabled**. A new connector grants an agent nothing until you enable specific tools on it.

## Adding one

<Steps>
  <Step title="Go to Settings → Connectors → New connector">
    The connector type picker shows curated platforms (each badged with the MCP mark) alongside **Custom MCP server** for any other endpoint.
  </Step>

  <Step title="Pick a platform, or Custom">
    A curated platform fills in its server URL, authentication method and setup checklist, so you only supply credentials. Custom asks for the endpoint yourself — it must be a Streamable HTTP MCP endpoint over HTTPS.
  </Step>

  <Step title="Authenticate">
    Either paste an access token, or authorize with OAuth — see below. Token connectors must pass **Test connection** before they can be saved.
  </Step>

  <Step title="Enable the tools agents may use">
    On the connector's **Tools** tab, switch on the tools you want and check the read/write classification of each. Anything the server does not explicitly mark read-only is treated as a write, so it stays behind human approval.
  </Step>

  <Step title="Attach it to an agent">
    Under the agent's **Data access** tab, switch on the connector. You can also add a connector straight from there.
  </Step>
</Steps>

## Authentication

### OAuth

For servers that support it, OAuth is the better option: nothing is copied by hand, and access tokens are refreshed automatically in the background.

Because authorizing has to store credentials against a connector, the order is **save first, then Connect**:

<Steps>
  <Step title="Save the connector">
    An OAuth connector can be saved before it works — it just has no credentials yet.
  </Step>

  <Step title="Register the redirect URI (only if the platform requires an app)">
    The connector page shows the exact redirect URI to register with the platform. It must match character for character. Servers that support dynamic client registration — Notion, for example — need no app and no client ID at all.
  </Step>

  <Step title="Click Connect">
    You're sent to the platform to sign in and choose what to share, then returned to the connector. Its tools are discovered automatically, all disabled.
  </Step>
</Steps>

The connector page shows whether it is connected, when it was authorized, and any authorization error. **Reconnect** re-runs the flow; **Disconnect** drops the stored credentials, which immediately stops agents from calling that server.

<Note>
  An OAuth connection belongs to the organisation, not to the person who authorized it. That is what lets scheduled agent jobs keep running when nobody is logged in — and it means the connection carries whatever access that person granted, so authorize with an account whose permissions match what agents should be able to see and change.
</Note>

If a connection lapses, agents don't fail silently: the tool tells the agent an administrator has to reconnect the connector, and a proposal that cannot execute records the same reason in the Decisioning inbox. Reconnect it, then approve the proposal again.

### Access token

For servers without usable OAuth, paste a token instead. It is stored encrypted and only decrypted at the moment a tool is called. You choose the header it is sent in (default `Authorization`), and the value is sent verbatim — so include the `Bearer ` prefix if the platform expects one.

## Curated platforms

Picking a platform fills in its endpoint, authentication method and scopes, so you only supply credentials. "Setup needed" is what you have to do before connecting.

| Platform        | Authentication            | Setup needed                                                                                                                                                                  |
| --------------- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Notion**      | OAuth                     | None — Notion registers Interact automatically. Choose which pages to share when you connect.                                                                                 |
| **Klaviyo**     | OAuth                     | None — registers automatically.                                                                                                                                               |
| **Customer.io** | OAuth                     | None — registers automatically. Requests read scopes; add `write` under the prefilled settings to let agents propose changes.                                                 |
| **Amplitude**   | OAuth                     | None — registers automatically.                                                                                                                                               |
| **HubSpot**     | OAuth                     | Create a HubSpot public app; supply its client ID **and** secret (HubSpot requires a confidential client).                                                                    |
| **Slack**       | OAuth                     | Create a Slack app; supply its client ID and secret.                                                                                                                          |
| **Asana**       | OAuth                     | Create an Asana app; supply its client ID.                                                                                                                                    |
| **Shopify**     | OAuth                     | Create a Shopify app; supply its client ID and secret. Store management — products, discounts, inventory, orders, customers, analytics. The store is chosen when you sign in. |
| **Amazon Ads**  | OAuth (Login with Amazon) | Create an Amazon Ads API application with a Login with Amazon security profile; supply its LWA client ID.                                                                     |
| **Meta**        | Access token              | Create a Meta app with the ads MCP use case; paste a user access token as `Bearer <token>`.                                                                                   |
| **Ahrefs**      | API key                   | Generate a key under Account settings → API keys; paste as `Bearer <token>`.                                                                                                  |
| **Semrush**     | API key                   | Copy your key from Subscription info → API units; paste as `Apikey <your key>` — note the scheme is `Apikey`, not `Bearer`.                                                   |

Every one of these also works as a **Custom MCP server** if you would rather enter the endpoint yourself, and any other remote MCP server can be connected the same way.

<Note>
  Four of these platforms document OAuth that we cannot use, so they are set up with an API key or token instead. Meta reports an authorization-server issuer that does not match the server named in its own discovery document; Ahrefs reports its issuer with a trailing slash where the standard expects none; Semrush rejects standard client registration and expects the token in the request body rather than a header. In each case the platform's documented token method is used, and the connector page explains why on screen. These are upstream issues — the OAuth option will be enabled here if they are corrected.
</Note>

## Third-party servers and responsibility

MCP servers are operated by third parties. Connecting one is a decision your organisation makes about its own data, so the first time you connect a given server an administrator has to accept a notice covering four points. We record who accepted it and when.

<Warning>
  **Operated by someone else.** Interact does not own, operate, control or vet MCP servers. Offering a platform as a prefilled option is convenience, not an endorsement or a security review of it. **Their availability, security and data handling are outside our control.**

  **Data leaves Interact.** Whatever your agents send to a server — including data drawn from your other connectors — is processed by that provider under its own terms and privacy policy, not Interact's.

  **The server defines its own tools, and can change them.** A compromised or hostile server can describe its tools in ways designed to make an agent take actions you did not intend, or send data where you did not intend.

  **Your organisation decides, and carries the risk.** Which servers you connect, which credentials and scopes you grant, and what agents do through them are your organisation's decisions, and the consequences rest with your organisation.
</Warning>

Practical consequences worth planning for:

* Connect servers run by organisations you already have a relationship with, and read the provider's terms before authorizing.
* Grant the narrowest scopes the work needs. An OAuth connection carries whatever access the authorizing account had.
* Keep tools off unless an agent needs them, and leave anything that changes state on **Needs approval** so a human sees it first.
* Review the tool list after a server updates — tool descriptions are the server's to change at any time.

Your agreement with Interact governs liability for connected third-party services; this page describes how the product behaves, not the contract.

## Security

* Server URLs must be HTTPS and cannot point at private or internal hosts.
* Tokens and OAuth credentials are encrypted per organisation and only decrypted for the duration of a call.
* An OAuth flow only accepts an authorization server on the MCP server's own origin, so a server cannot redirect you to sign in somewhere unrelated.
* Write tools always require human approval. There is no setting that lets an agent write to a platform unattended.

[Deep dive: how connectors work →](/concepts/connectors)