Say you run sales operations and a vendor pitch has just landed in your inbox: an agent that works your sales engagement platform for you. Outreach is the platform. You want to know what an agent can actually do there, and whose name is on it when it does.
Start with the thing most people would skip. Of the 50-plus REST resource pages the catalog lists for Outreach, the most interesting API is none of them. It is the Outreach MCP Server, a remote server at https://api.outreach.io/mcp. It exposes the 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.
Here is the detail that matters to you. Tool calls inherit the signed-in user's RBAC profile and are attributed to that user in Outreach's activity history. So when an agent acts, it acts as a named seller, under that seller's permissions. Outreach built that in rather than issuing a service token. If you worry about who did what in your CRM-adjacent system, that is a good answer.
You might wonder how anyone found the endpoint, because Outreach's documentation never prints the server URL. Its getting-started checklist tells you to ask Outreach for it. The catalog worked it out from Outreach's own RFC 9728 protected-resource metadata. The /.well-known/oauth-protected-resource path returns 200 and names https://api.outreach.io/mcp as the resource. A POST to that URL returns 401 with a WWW-Authenticate header pointing back at the metadata. No guessing was involved, and mcp.outreach.io does not resolve. That is discovery working the way the standards intend. It is also 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: agent-ready, but held back by a gate from agent-native.
Now the number that should shape your expectations. The catalog built a crosswalk binding each tool to the REST operation behind it. It is a derived artifact, so it is the catalog's work, not Outreach's. The OpenAPI has 253 REST operations. 33 tools bind to one, 22 of them at high confidence. 8 tools have no REST equivalent. The share of REST operations with a tool is 13 percent.
That narrowness looks deliberate. On the write side the server 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. Your agent will not be running bulk jobs through this door. But the server also goes the other way in 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. An agent gets fewer verbs than a developer does, plus some answers a developer cannot fetch.
Then the part the catalog filed against Outreach's own record, which you should know before you sign anything. Outreach's pages disagree about the tool count. The Tool Catalog is titled 41 tools and lists 41, while 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 sits 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 under 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. That is why some bindings are inferred rather than exact.
What you take away: ask the vendor to print the endpoint, reconcile 41 against 32, and publish scopes narrower than prospects.all. Ask for operationIds in the REST contract. And credit what is already there, a working, standards-discoverable, user-attributed MCP server, which is still uncommon.
Read the original: https://apis.io/2026/10/24/outreachs-mcp-server-covers-one-in-eight-rest-operations-and-that-is-the-design/