The MCP handshake reaches the buy-side: what expert networks and transcript vendors owe an agent runtime

A year ago, Model Context Protocol was an Anthropic release note. Today it is the connector layer that OpenAI, Google DeepMind, and Microsoft have all publicly endorsed, and the integration pattern that a growing set of buy-side agent frameworks assume by default. For expert networks and transcription vendors, the practical consequence is narrow and specific: the way a Citadel analyst's agent reaches a Guidepoint transcript in 2026 is unlikely to be the same REST call a research associate made in 2023.

That is not a prediction about any vendor's fortunes. It is an observation about where the integration surface is moving, and about the work required to sit on the new surface without giving up the compliance posture the old one was built to protect.

From developer curiosity to enterprise default in twelve months

Protocols usually take years to reach consensus. MCP took roughly six months to move from Anthropic's own release into the roadmaps of every major frontier lab. OpenAI added MCP support in March 2025 as part of its Responses API refresh. Google DeepMind followed in April 2025, aligning Gemini's tool-use surface with the same manifest pattern. Microsoft added MCP to Copilot Studio and Windows in May, which mattered less for the technical detail than for the signal: the largest enterprise software distributor in the world was going to ship MCP into the desktop.

What this cadence tells us is that MCP has cleared the bar every prior candidate for an agent-tool standard failed to clear. It is model-agnostic. It is not owned by a hyperscaler. It handles the two things that always break bespoke integrations: the discovery problem (how does an agent find out what a tool can do) and the auth problem (how does a tool trust the agent's caller).

For buyers of research, none of that is interesting on its own. What is interesting is the second-order effect. When every major agent runtime speaks the same protocol, integration cost for connecting one more data source collapses. Collapsing integration cost is what turns a fragmented vendor stack into a routed one.

What buy-side agent workflows actually look like now

The frame that matters is the shift from monolithic API integration to tool-call composition. In the old pattern, a hedge fund's research platform team would negotiate an API with Guidepoint, another with Tegus, another with Bloomberg, and stitch the responses together in application code. Each integration was a project. Each renewal was a project. Each schema change was a project.

The agent-runtime pattern inverts this. Rogo, Hebbia, and Perplexity's Comet product all assume the agent will decide at runtime which tools to call, in what order, with what parameters, to answer a specific analyst question. The tools themselves are declared through manifests the agent can read. If a new tool appears on the manifest, the agent can use it on the next query without a code deploy.

Perplexity's Comet has already shown what this looks like in practice by routing licensed queries to Guidepoint, D&B, and IBISWorld through a single agent surface. Datasite's Rogo integration is an early example of the same pattern in a deal-workflow context, where licensed research is surfaced through the agent runtime rather than through a separate portal. Internal builds at Citadel and Balyasny reportedly follow similar architectures, though the details are not public and we will not speculate about them.

The common feature is that the analyst no longer picks the vendor. The agent picks the vendor. And the agent picks based on what is on its manifest, what it has permission to call, and what it has been told the tool is good for.

Why REST APIs and portal SSO are not enough anymore

Expert networks and transcript vendors did the right integration work for the last cycle. AlphaSights, GLG, Guidepoint, AlphaSense (via Tegus), and Dialectica all ship REST APIs to enterprise customers. Aiera and Quartr have shipped programmatic access to earnings-call transcripts for years. Portal SSO through Okta or Azure AD is standard. For a research team that wants to pull a batch of transcripts into a data lake overnight, this stack works.

It works less well for an agent that wants to make three tool calls in eight seconds while an analyst is still typing the question. The frictions are specific:

• Discovery. A REST API assumes the caller already knows the endpoint, the parameters, and the response shape. An agent runtime prefers a declarative manifest it can read at load time and reason about at query time. Without a manifest, the agent has to be hardcoded to know the vendor exists, which is exactly the coupling MCP is designed to break.
• Auth granularity. Enterprise SSO authenticates the human. Per-call auth authenticates the agent action on behalf of the human, with a scope narrow enough that a compliance team can defend it. Most REST APIs today issue a long-lived bearer token, which is the opposite of what a compliance officer wants inside an agent loop.
• Permission scoping. Expert networks live and die on entitlement logic: which analyst can see which transcript, whether a call has cleared compliance review, whether a specific expert's content is embargoed for a named account. Portal UIs encode this logic; REST APIs partially expose it; MCP endpoints have to expose it declaratively, per call, in a form the agent can respect.
• Observability. Compliance teams need to reconstruct after the fact which agent asked for what, on whose behalf, and what it was shown. REST logs answer some of this. MCP is being built with a richer audit surface because the whole premise of the protocol is that an autonomous caller is making decisions a human did not directly authorize.

None of these frictions is unfixable inside a REST stack. Vendors have been extending their APIs for years. The point is that the extension work now has a target: what an MCP endpoint looks like, what it exposes, what it withholds, and how it authenticates.

The routing risk, stated plainly

The commercial stakes come down to one sentence. If a buy-side agent framework can only reach vendors that speak MCP, non-MCP vendors get routed around even when they are on the licensed roster.

That sentence deserves to be sat with. A vendor can be paid for, contracted for, and technically available, and still lose queries to a competitor that is one line easier to reach from the agent's manifest. The licensed roster does not disappear. What changes is which item on the roster the agent picks when three of them can plausibly answer the same question.

This is not a hypothesis about a specific vendor. It is a well-understood property of any system where a routing layer sits between the user and the supplier. Search engines routed traffic based on crawlability. App stores routed installs based on discoverability. Agent runtimes will route queries based on manifest quality, auth simplicity, and response latency. The vendors who invest early in those three surfaces get the routing volume. The vendors who wait get the residual.

The read for a Head of Research at an expert network is straightforward. The question to ask the product team is not whether the vendor has an API (it does) or whether the API works (it does). The question is what the vendor's tool manifest looks like when a Rogo or Hebbia agent asks for it, and whether the answer is defensible to a compliance officer who has to sign off on autonomous agents calling it.

Compliance is the harder half of the problem

The technical work to expose an MCP endpoint is bounded. The compliance work to make that endpoint safe for an autonomous agent to call is not.

Expert network content is governed by a body of policy that developed over two decades of enforcement action, MNPI risk, and the specific incidents in China involving Capvision and Bain in 2023 that led several networks to pause parts of their APAC coverage. The compliance posture inherited from that history assumes a human moderator sits in the loop, that expert calls are recorded and screened, and that transcripts are released to specific named accounts under specific terms. Every one of those assumptions has to be re-examined when the caller is an agent, not a person.

Some of the questions are technical: how does the endpoint verify the agent is calling on behalf of an entitled human, how are per-call scopes issued and revoked, what happens when an agent asks for content that would be within the human's entitlement but outside the agent's scope. Some are legal: does an agent call constitute the same delivery event as a human view for the purposes of the vendor's terms, and if not, what does. Some are operational: who audits the agent traffic, at what cadence, using what tooling, and can the vendor produce an audit trail that satisfies a Big Four DD in a due-diligence event.

Our view is that the vendors who treat this as a compliance product surface, and not just an integrations checkbox, will be the ones that survive the transition intact. Exposing an MCP endpoint is easy. Exposing an MCP endpoint that a Chief Compliance Officer will sign off on for autonomous agent access is a genuine piece of product work. The gap between those two things is where the next eighteen months of vendor differentiation lives.

Three scenarios for how the vendor landscape re-sorts

The honest way to think about this is scenario-based, because the specific outcome depends on choices individual vendors have not yet publicly made.

Base case: MCP becomes table stakes, differentiation shifts to content. In this scenario, every serious expert network and transcript vendor ships MCP endpoints inside twelve to eighteen months. The protocol becomes as unremarkable as REST is today. Vendor differentiation reverts to what it was before: coverage depth, expert quality, transcript accuracy, geographic reach, compliance posture. MCP is a hygiene requirement, not a moat. This is the outcome we assign the most weight to, because it is what usually happens to enterprise protocols once the frontier labs agree on them.

Bull case for early movers: manifest quality becomes a durable routing advantage. In this scenario, the quality of a vendor's manifest, the granularity of its scoping, and the latency of its endpoint start to matter as much as the underlying content. An agent that can call vendor A in 400ms with clean per-call auth will pick vendor A over vendor B at 1.2s with a bearer token, even if vendor B has the better transcript. Early investment in the integration surface compounds into routing share, and the gap becomes hard to close. This scenario rewards the vendors who have already been building agent-friendly infrastructure and disadvantages those who wait for the standard to fully settle.

Bear case: compliance friction fragments the market. In this scenario, the compliance work turns out to be harder than the technical work, and no vendor manages to expose an MCP endpoint that satisfies both the frontier labs' agent runtimes and the buy-side compliance teams. Agents route to the small set of vendors who solve the compliance problem first, and the rest of the market gets pushed back to human-mediated workflows for high-stakes queries. The buy-side ends up running two stacks in parallel: an agent stack for low-sensitivity research and a human stack for the calls that carry real MNPI risk. This scenario is less likely than the first two, but it is the one that would reshape the vendor landscape most.

The scenarios are not mutually exclusive at the segment level. Transcript vendors, whose content is already public and whose compliance surface is narrower, will likely land in the base case. Expert networks, whose content is bespoke and whose compliance surface is deeper, are more exposed to the bull and bear cases.

The questions a research analyst should be asking now

If you are on the buy-side and you are trying to calibrate this shift with your vendors, the useful questions are specific:

• What does your MCP tool manifest look like today, and if you do not have one, what is the roadmap and who owns it internally?
• How do you handle per-call auth for an agent acting on behalf of an entitled analyst, and what scopes are available?
• What audit surface do you expose for agent traffic, and can you produce a defensible record for a compliance review?
• How are you thinking about the delivery-event question in your terms of service when the caller is autonomous?
• Which agent runtimes have you tested against, and what were the latency and error-rate results?

If you are on the vendor side, the same questions are the ones your product and compliance teams should already be answering internally, because your customers are about to start asking them.