The [SendOps agent skill](/agent-skill) makes an agent *knowledgeable* about SendOps. An **MCP connection** goes further: it lets the agent actually look at your account and act on it. *"Why did yesterday's campaign bounce so hard?"* — with the skill, your agent explains how to find out. With an MCP connection, it looks, and tells you. An agent connected over MCP can read your contacts and reports, and — depending on what you approve — write contacts, author templates and workflows, and send broadcasts to your audience. Connect agents you trust, and approve only the permissions you need. You can review and disconnect anything you have connected at any time from [Connected Apps](/api-integrations/connected-apps). ## What MCP is MCP — the Model Context Protocol — is an open standard for connecting AI assistants to outside systems. If your agent supports it, SendOps appears as a set of **tools** the agent can use: look up a contact, size a segment, check whether you can send, draft a broadcast. You do not need to install anything on the SendOps side. There is one address: ``` https://mcp.sendops.dev/mcp ``` ## What an agent can do Thirty-nine tools, grouped by what they act on. Your agent sees **only the ones your approved permissions allow** — approve reads alone and the write tools are not merely refused, they never appear. | Area | What the agent can do | | --- | --- | | **Organizations** | List the organizations the connection covers and what it may do in each, and hand you the link to add or remove one | | **Sending readiness** | Check whether your account can send at all, and what's blocking it — AWS connection, domain verification, the SES sandbox, tracking setup | | **Deliverability** | Read your sending health, look through the suppression and undeliverable lists, search sent messages and diagnose why a particular one failed | | **Audience** | Look up contacts, list your Lists and Segments, size a segment predicate *before* you save it, read your attribute and topic registry | | **Audience writes** | Create and update contacts, archive them, change List membership, record activity, issue a contact's [website visitor id](/website/overview) for your server to set as a cookie | | **Audience authoring** | Write [Segments](/audience/segments), [Lists](/audience/lists), [topics](/audience/topics), [attributes](/audience/attributes) and activity properties | | **Templates** | List templates, render one with test data, author or edit template content, send a test | | **Drip Workflows** | Read workflow performance, dry-run a contact through one, author a workflow, estimate who it would enrol, activate it — [live or in shadow](/workflows/shadow-mode) | | **Version history** | Read any definition's [edit history](/templates/version-history-and-restore), see what one edit changed, and restore an earlier version | | **Broadcasts** | Read broadcast status, compose a draft, preview it, send a test, and send it for real | One of the most useful things an agent can do is compile and count a segment predicate without creating anything. Ask for "everyone who opened in the last 30 days but hasn't clicked", and it can tell you how many people that is before you commit to a Segment. ## What it cannot do - **It cannot bypass your permissions.** The agent acts *as you*. If your role can't send broadcasts, neither can an agent connected under your account — even if you approved that permission when you connected it. If your role is reduced later, the agent's access shrinks with it, within a few minutes. - **It cannot tell you an email is ready before it is.** A template save is a save — it takes effect the moment the agent makes it, with no queue and no review step. But *saved* and *sendable* are different states: every save reports a **deploy state**, and a well-behaved agent reads that back before telling you your wording can go out. See [Template Management](/templates/template-management#deployment-to-ses). - **It cannot quietly lose what was there before.** Every definition an agent edits is versioned with the agent named as the author, so you can see exactly what it changed and put the previous version back. See [Version history & restore](/templates/version-history-and-restore). - **It cannot send anything twice by accident.** Retries are recognised and answered with the original result rather than repeated. - **It cannot turn off your own safety checks.** There is no tool that disables a workflow's send approval. An agent can ask to do something consequential; it cannot remove the check on it. ## Sending and activating always ask first Two actions can't be taken back: **sending a broadcast** and **activating a workflow**. Both are deliberately made to take two steps. The agent's first attempt doesn't send anything — it comes back with exactly what is about to happen, and waits for an explicit confirmation before proceeding. This is enforced by SendOps, not by your agent's own good manners. An agent that ignored every warning still cannot send on the first call. Everything reversible — updating a contact, saving a draft — happens in one step on purpose. A confirmation prompt on every single action trains people to click through them, which is exactly what would make the two that matter stop working. ## Connecting your agent 1. **Add the SendOps MCP server in your agent.** In Claude Desktop, Cursor, or any MCP-capable client, add a connector and give it the URL `https://mcp.sendops.dev/mcp`. The exact menu differs by app — look for "Connectors", "MCP servers", or "Integrations". 2. **Sign in to SendOps.** Your agent opens a SendOps page in your browser. If you're already signed in to the dashboard, you go straight to the next step. 3. **Review the consent screen.** It names the agent asking, lists every permission it wants, and says which SendOps surface the access is for. Read the list — this is the moment to decline anything that looks broader than what you want the agent doing. 4. **Tick the organizations the agent may act in.** Nothing is ticked for you. If you belong to one organization, tick it; if you belong to several, tick as many as you want the agent to reach — one connection covers all of them. An organization whose administrator has blocked this agent is shown but cannot be ticked. **Approve** stays disabled until at least one is ticked. 5. **Approve.** Your agent is connected. Ask it something — *"can my account send email right now?"* is a good first test, since it needs only read access. It won't work. The MCP server does not accept API keys — only the sign-in flow above. API keys carry no user, no consent, and nothing to revoke per-agent, which is not a credential that belongs on an agent connection. If your agent only supports API keys, it can use the [Public API](https://developers.sendops.dev/api-reference/) instead. ## Working across several organizations One connection can act in **every organization you ticked** at consent. The agent never guesses which one you mean: every tool call names an organization, and the first thing a well-behaved agent does is ask SendOps which organizations the connection covers and then ask *you* which to use. *"Which organizations can you see?"* is a good check — the agent should name exactly the ones you ticked, along with what it is allowed to do in each. Your role can differ per organization (Admin in one, Viewer in another), and the agent's access differs with it: a tool it can use in one organization may be refused in the next, with the refusal saying so. If you ask for something without naming an organization and you have more than one, the agent should ask rather than pick. If it does pick, the request is refused by SendOps with the list of organizations it could have named — so a wrong guess costs a round trip, not an action in the wrong place. ### Adding an organization later You do not need to reconnect the agent to give it another organization. Ask it to add one — it hands you a link to [Connected Apps](/api-integrations/connected-apps) — or go there yourself, find the agent's card and choose **Add organization**. The new organization is available to the agent on its very next request, with the same permissions you originally approved, capped by your role there. ### Removing an organization From the same page, **Disconnect** the organization's row. The agent loses that organization immediately and keeps the others. Disconnecting the last row disconnects the agent entirely. ## Keeping an eye on it Everything an agent does through MCP is attributed in your [audit log](/team/audit-log), the same as any other change — you can see what was done, and that it came through the connected app rather than from a person in the dashboard. Reads aren't recorded there; the audit log tracks changes, not lookups. A connected agent is an authorized app like any other, so it appears in the same two places and is revoked the same way: - **[Connected Apps](/api-integrations/connected-apps)** (Profile → Connected Apps) — the agents *you* connected, one card per agent with a row for each organization it may act in. Disconnect an organization, or add one, from there; both take effect immediately. - **[OAuth Clients](/api-integrations/oauth-clients)** (Workspace → OAuth Clients) — an Owner or Org Admin can review and revoke every grant across the organization, which is the surface for off-boarding or an audit. Whatever you approved, the connection is still capped by what *you* are allowed to do. Reduce someone's role and their connected agents lose that access automatically, within a few minutes — you don't have to revisit each one. ## For developers Building a product that connects to SendOps on your customers' behalf? The technical guide — the OAuth flow, client registration without an admin in the loop, the tool schemas, guardrails, and rate limits — is at [developers.sendops.dev/api-reference/mcp](https://developers.sendops.dev/api-reference/mcp).