The most interesting API Outreach publishes is not one of the 50-plus REST resource pages the catalog lists for it. It is the Outreach MCP Server, a remote server at https://api.outreach.io/mcp that exposes the sales engagement platform as 41 agent tools: 27 read, 11 write and 3 for schema introspection. It runs over streamable HTTP and is authorized with OAuth 2.1, PKCE and RFC 7591 Dynamic Client Registration. Tool calls inherit the signed-in user’s RBAC profile and are attributed to that user in Outreach’s activity history.
That last detail is the one that matters. An agent acting in a CRM-adjacent system is acting as a named seller, under that seller’s permissions. Outreach built that in rather than issuing a service token.
How we found the endpoint
Outreach’s documentation never prints the server URL. Its getting-started checklist tells you to ask Outreach for it. We established it from Outreach’s own RFC 9728 protected-resource metadata. /.well-known/oauth-protected-resource returns 200 naming https://api.outreach.io/mcp as the resource. A POST to that URL returns 401 with a WWW-Authenticate header that points back at the metadata. No guessing was involved, and mcp.outreach.io does not resolve. This is discovery working the way the standards intend, and it is why Outreach’s Agent Readiness record shows protected resource metadata as verified and dynamic client registration as lit.
The provider scores 79.3, exemplar, and 54.0 on Agent Readiness. That is agent-ready, held back by a gate from agent-native.
The narrow projection
We built a crosswalk that binds each tool to the REST operation behind it. It is a derived artifact, so it is our work, not Outreach’s.
| Count | |
|---|---|
| REST operations in the OpenAPI | 253 |
| Tools bound to a REST operation | 33 |
| …at high confidence | 22 |
| Tools with no REST equivalent | 8 |
| Share of REST operations with a tool | 13% |
The MCP surface is deliberately narrow. On the write side it offers create and delete for four entity types and nothing else. REST, by contrast, exposes 27 batch actions, 9 task actions, 4 sequence-state actions and the whole import pipeline. The MCP server goes the other way in a few places. It adds runtime schema-introspection tools and two server-side LLM tools, account_answer_question and opportunity_answer_question, which have no REST route at all. So an agent gets fewer verbs than a developer does, plus some answers a developer cannot fetch.
Where the record frays
Outreach’s own pages disagree about the tool count. The Tool Catalog is titled 41 tools and lists 41. The overview and authentication pages both say 32. A prepare_for_meeting tool is documented as invokable but missing from the catalog table. The authorization server advertises a single scope, prospects.all, for a surface that reaches accounts, opportunities and tasks. And tools/list is gated behind authentication, so the input schemas could not be captured anonymously. The tool names on apis.io come from Outreach’s published catalog, not from a live listing.
One more gap sits beneath the crosswalk. The REST OpenAPI declares no operationId on any of its 253 operations, so the only handle a tool can bind to is METHOD /path.
Takeaway
Three fixes would move this API. Outreach could print the endpoint, reconcile 41 against 32, and publish scopes narrower than prospects.all. Adding operationIds to the REST contract would make every tool-to-operation mapping exact instead of inferred. What is already there is a working, standards-discoverable, user-attributed MCP server, and that is still uncommon.
Read Outreach’s own docs at developers.outreach.io/mcp-server, and the catalog entry at apis.io/apis/outreach/outreach-mcp-server/.