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 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 | | --- | --- | | **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 | | **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 | | **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 overwrite what your git repo owns.** If your Lists, topics, or attributes are defined in a connected repository, the repo wins and the agent is told so. For templates, an edit becomes a **pull request** for your team to review, not a silent change. - **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. **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. ## Which organization it connects to The connection is to **one organization** — the one you approved it for. If you belong to several, connect the agent once per org; each gets its own approval and can be revoked separately. ## 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, across every organization. Disconnect takes 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).