Your agent needs to work with Outreach. It needs to find prospects, check which sequences a deal owner is running, pull the Kaia transcript from last week's call, and log what happened next. Outreach ships two paths: a hosted MCP server at api.outreach.io/mcp and a REST API that has been in production for years. They cover overlapping but genuinely different ground, they put you on different auth paths, and for one very common class of agent, the MCP path has a hard architectural stop. Here is how to pick.
Two different objects with two different design intents. One was built for a seller talking to an LLM. The other was built for systems integration. Reading them as interchangeable transports for the same capability set is the mistake that costs you a rewrite.
Outreach announced general availability of its MCP Server in February 2026. It is a hosted, Outreach-maintained endpoint at https://api.outreach.io/mcp, speaking Streamable HTTP and implementing the Model Context Protocol (MCP) 2025-03-26 revision and above, including tool annotations and self-describing schemas via tools/list.
Two gates sit in front of it. The organization must have the Amplify add-on enabled with active credits, and an admin must toggle MCP Server on under Administration, Organization, Org Info, Gen AI. Create actions are on by default at that toggle; delete actions are off by default.
Official docs: Outreach MCP Server developer portal and the MCP Server overview in Outreach support.
The REST API is a JSON:API-styled v2 surface at https://api.outreach.io/api/v2, covering prospects, accounts, opportunities, sequences, sequence states and steps, tasks, templates, snippets, mailings, mailboxes, calls, users, webhooks, batches, imports, and custom objects.
Authentication accepts an OAuth 2.0 bearer token obtained through the authorization code flow, with period-separated scopes such as prospects.read, accounts.write, and sequences.all. Scopes are not additive; prospects.write does not grant read. A separate S2S flow issues an application-scoped token for server contexts.
Official docs: Outreach REST API developer portal.
Four dimensions decide this: what the agent can do, what credential it holds, what you operate, and which one wins for your specific workload.
The MCP tool catalog breaks into 21 read and discovery tools, 8 write and mutation tools, and 3 schema and special tools. The read surface is strong. The write surface is deliberately small.
The single most consequential gap is that Outreach MCP has no update tools. Not for prospects, not for accounts, not for opportunities. The catalog contains prospect_create and prospect_delete but no prospect_update.
This is not an oversight or a roadmap gap that closes next quarter. Outreach states the reasoning directly: internal testing showed LLMs behaving unpredictably when updating existing records, so they shipped read, create, and delete only. If your agent's job is to keep opportunity fields current or correct prospect data after a call, the MCP server structurally cannot do it. That work goes over REST.
The gap runs the other way too, and comparison posts usually miss this. Three MCP tools have no REST equivalent: account_answer_question, opportunity_answer_question, and prepare_for_meeting. These are Amplify intelligence features surfaced as tools, not thin wrappers over v2 endpoints.
If your agent's value is "brief me on this account before the call," MCP gives you that in one call. Rebuilding it over REST means assembling accounts, opportunities, mailings, and Kaia records yourself and doing your own synthesis.
The MCP authentication model is OAuth 2.1 with PKCE, plus Dynamic Client Registration per RFC 7591. The client discovers .well-known/oauth-authorization-server, registers itself dynamically, and runs the user through an authorization code flow. Permissions inherit from the authenticated user's Outreach RBAC profile on every tool call.
That inheritance is architecturally correct. What the user cannot do, the agent cannot do. The constraint is what surrounds it.
Your MCP client itself must support OAuth 2.1 user authentication and Dynamic Client Registration. A bespoke agent runtime that speaks MCP but not DCR cannot connect. That is a client-side capability requirement, not a configuration flag.
Client credential authentication is explicitly not supported. Outreach enforces that an active user credential is presented, and if you use an agentic identity, that identity must be an active, licensed Outreach user consuming a seat.
Amplify gating means MCP availability is a commercial question before it is a technical one. If your B2B customers do not all carry Amplify, your MCP-based agent does not work for all of them.
Be precise here, because the common framing is wrong. Outreach does support non-user identities over MCP as long as a valid token is provided and that identity maps to a licensed user. So a scheduled agent can technically run on MCP.
The problem is credential issuance. There is no non-interactive way to mint that token. Bootstrapping requires a browser, and re-bootstrapping requires it again whenever the grant lapses. Combine that with a 14-day refresh token and a nightly job becomes a recurring human dependency.
The REST API's S2S access flow is the genuine non-interactive path. You register public keys, sign an RS256 app token with your private key and S2S_GUID, exchange it plus an installation ID for a one-hour access token, and call the API. There is no refresh; you request a new token.
State the tradeoff plainly, because Outreach does. The S2S token carries no user identity, only your application's, scoped to one org installation. The available scope list is a subset of OAuth scopes. Some write operations need extra data such as an authorizer user ID, and some will not work at all. S2S is a real headless path, not a full-fidelity one.
These numbers come from the Outreach API getting started guide and they shape your architecture more than the capability table does.
The 14-day figure is the one that surprises teams. A weekly pipeline hygiene agent is fine. A quarterly reporting agent is not; it will find a dead grant every single run.
Outreach rate limits the API on a per-user basis at 10,000 requests per hour. Kaia recordings and transcripts carry tighter org-level limits: 3 calls per second and 6,000 calls per day.
MCP tool calls count against the same throttle. Choosing MCP does not buy you a second budget. Worse, MCP call volume is non-deterministic; Outreach notes a single natural-language query may fan out into five or more tool calls depending on how the model reasons. A Kaia-heavy research agent can exhaust a shared org-level daily ceiling on behalf of a handful of users.
On the MCP path, Outreach owns hosting, tool schemas, and permission enforcement. You own per-user token storage, refresh, tenant isolation, and the Amplify entitlement check before you promise a customer the feature works.
On the REST path, you own all of that plus endpoint selection, JSON:API request construction, the newFilterSyntax filter semantics, pagination, retry logic, and adapter code per resource. More surface area, more control, and a versioned contract that does not shift when a vendor updates a tool schema.
MCP tool schemas change when Outreach updates the hosted server, and Outreach says outright that it is continuously adding tools and that you should refresh periodically. The catalog already moved from 27 documented tools in the support article to 32 in the developer portal.
For an interactive assistant, that is upside; new capability arrives without a redeploy. For a deterministic pipeline where an unplanned schema change is an incident, it is a dependency you did not choose.
Use Outreach MCP when:
Use the Outreach REST API when:
Both paths end at the same place: one Outreach credential per user, sitting somewhere in your infrastructure, silently aging.
A revenue agent serving 60 reps across 9 customer orgs is 60 OAuth grants. Each needs encryption at rest, per-tenant isolation, proactive refresh inside a 2-hour window, and rotation handling that stores the newest refresh token and drops the old one. Miss the 14-day window on any of them and that rep's agent goes dark.
Neither path gives you a vault, rotation logic, or a revocation flow. The token type differs. The infrastructure you must build does not. For a deeper look at secure token management for AI agents at scale, the patterns that apply here are the same ones production teams reach for regardless of which Outreach path they chose.
Ask the offboarding question. When a rep leaves, can you revoke their agent's Outreach access?
On the MCP path, Outreach's answer is that you cannot do it through Outreach if you use a third-party identity provider; an admin revokes at the IdP. That is defensible security design and a genuine operational gap. Your application has no way to enumerate which agent grants were live at the moment of departure, and no way to invalidate one without touching the IdP.
Scalekit's Outreach connector resolves the per-user credential server-side on every tool call, so actions attribute to the rep who authorized them rather than a shared service account. Credentials never touch the agent runtime or the LLM context. The connector page documents an AES-256 vault namespaced per tenant, automatic refresh, and a 90-day audit trail. The same layer works whether you chose MCP or REST.
Scalekit ships a single Outreach connector, connection name outreach, authenticating over OAuth 2.0 and wrapping the REST surface. At the time of writing it publishes 53 tools, including the update operations the official MCP server does not expose.
Create the connection in the dashboard under AgentKit > Connections. The connection_name string in your code must match the connection name configured there exactly; this is the single most common integration error.
The agent never sees an Outreach token. It references a connected account by your own user identifier, and Scalekit resolves the credential at call time.
Before the code, the distinction that matters. actions.langchain.get_tools does not load a connector catalog. It returns the tools this specific rep's connected account is authorized to call, in native LangChain StructuredTool form. Scope is a function of identity, not connector configuration.
For Node teams, listScopedTools accepts a toolNames filter, which is where surface reduction happens explicitly. Handing the model all 53 Outreach tools at roughly 200 tokens each burns over 10,000 tokens before the agent does any work, and measurably degrades selection accuracy. This is a core consideration covered in LangChain tool calling patterns as well.
outreach_tasks_complete only works for action_item and in_person tasks; call and email tasks cannot be completed this way. Use it rather than outreach_tasks_update when the intent is completion. Full parameter schemas live on the Outreach connector docs.
If you want the MCP interface without inheriting the Amplify gate, the DCR client requirement, and the seat-per-agent-identity constraint, Virtual MCP servers give you a scoped MCP endpoint over the connector you already configured.
You declare which connections and which tools the endpoint exposes. Do this once per agent role, not once per user. The response carries a static mcp_server_url.
Check that the rep's connected account is still active before every run, because OAuth grants expire and get revoked. Then mint a short-lived token bound to that user.
One server definition serves every rep across every customer org. Each run receives a token scoped to that individual's connected accounts, so rep A's sequences are never reachable by an agent acting for rep B on the same connection.
The endpoint is static; the identity is not. There is no MCP server to deploy, host, or maintain, and no per-user server configuration. Setup details are in set up and connect a Virtual MCP server.
Attribution is the thing that quietly breaks first, and it is the thing your customer's security reviewer asks about first.
A shared service account looks correct in a demo. In production every prospect created, every sequence enrollment, and every deleted record shows one actor in Outreach's activity history. When a rep asks why a prospect got enrolled in the wrong cadence, the trail ends at a bot.
Because Scalekit resolves the individual rep's credential before each call, Outreach's own activity history attributes the action to that rep. Scalekit's audit trail for agent auth carries the correlating record: which user, which tool, what came back, with 90 days of history that streams to your SIEM.
That is what turns "the agent enrolled 400 prospects" from an investigation into a query. For teams thinking about agent tool observability more broadly, per-user attribution is the foundation everything else is built on.
If your Outreach agent is interactive, user-present, and its job is retrieval and briefing, the hosted MCP server is the faster route, and the AI-native tools are genuinely differentiated. Confirm Amplify coverage across your customer base before you build on it.
If your agent updates records, runs on a schedule, needs tasks or templates or call logging, subscribes to webhooks, or moves volume, use the REST API. The absence of update tools on MCP is a stated product position, not a gap waiting to close.
Most production revenue agents will end up running both, and the credential layer underneath is identical either way. That is the part that needs production-grade infrastructure.
Building on Outreach and hitting the 14-day refresh window, the Amplify gate, or per-rep attribution? Bring it to the Scalekit Slack community, or talk to an engineer if you want help mapping your agent to the right path.
Browse the Scalekit Outreach connector or read the Outreach connector documentation.
