The interoperability layer: how MCP registries are becoming the discovery surface for buy-side research vendors

The interesting shift in buy-side research infrastructure is not that agents can now call vendor APIs. It is that agents increasingly do not know which vendor API to call until a registry tells them.

Anthropic released the Model Context Protocol in November 2024 as an open standard for connecting language models to external tools and data. Two years on, MCP has settled in as the default wiring between agents and enterprise systems, with OpenAI's Responses API and Cloudflare's remote MCP hosting both building around it. The protocol itself is now the boring part. The interesting part is the layer above it: the registries that decide which MCP endpoints an agent can discover, invoke, and trust.

Our read is that this discovery layer, rather than any individual MCP deployment, is becoming the point at which vendor selection is decided for buy-side research. It changes what procurement looks like, what distribution looks like, and where the compounding advantages sit.

From RFP to runtime

The procurement model for buy-side research has been recognisable for two decades. A firm evaluates expert networks, market data providers, alternative data vendors, and workflow tools; runs an RFP; negotiates seat counts; signs a multi-year contract; provisions logins; and trains analysts to use the platform. The unit of selection is the vendor. The unit of usage is the human analyst opening the vendor's UI.

MCP disturbs both units. When an analyst asks an agent inside Claude, ChatGPT, or a firm's internal copilot for channel checks on a semiconductor supplier, or for the transcript excerpt where a CFO discussed pricing power, the agent decides at runtime which tool to call. That decision is bounded by what MCP servers the agent can see, which is bounded by what the registry , public, enterprise-internal, or embedded in the model vendor's product , has surfaced and sanctioned.

The unit of selection is no longer the vendor. It is the endpoint. And the unit of usage is no longer the analyst clicking through a UI. It is the agent resolving a tool call. That is a different distribution model, and it has different economics.

A useful analogy is the shift from desktop software to mobile app stores. In the desktop era, a vendor's distribution was the sales team, the IT partnership, and the login page. In the mobile era, a vendor's distribution was the app store listing, the search ranking, the default-app slot on a new device, and the OS-level permission scope. The MCP registry is beginning to play the app-store role for agent-accessible research tools. The vendors that have been thinking about MCP as a plumbing upgrade are, in our view, underestimating what the registry layer is doing to their distribution curve.

What the registries actually are

There is no single MCP registry, and the plurality itself matters. Anthropic maintains a directory of MCP servers alongside the protocol specification hosted at modelcontextprotocol.io. Community-run registries such as Smithery and PulseMCP catalogue servers with metadata, install commands, and popularity signals. Cloudflare offers remote MCP server hosting, which turns the deployment question into a Workers configuration and reduces the barrier to publishing a server. Model vendors themselves embed curated connector menus: Claude Desktop has its own set of first-party and verified integrations, and Perplexity's Finance product surfaces a specific set of financial data sources rather than the entire open web of MCP servers.

The registries are not equivalent. They differ along at least four axes that matter for a buy-side buyer.

• Curation model. Some are open catalogues where any developer can list a server. Others are curated, with a review process and a verified-publisher tier. The curated tiers are where enterprise buyers look first because listing there is a proxy for vetting.
• Trust surface. A registry that ships inside Claude Desktop or a Perplexity Finance workspace carries the model vendor's implicit endorsement. A community registry carries the community's. An enterprise-internal registry, provisioned by a firm's IT function, carries the firm's own compliance sign-off. These are different trust surfaces and they layer.
• Auth and scope. OAuth-based MCP servers can expose granular scopes: read-only transcript access, write access to a portfolio system, permission to place a trade. Registries increasingly surface these scopes as part of the listing so a compliance team can evaluate before enabling.
• Rate and cost primitives. Some registries and hosting layers impose their own rate limits, quotas, and metering. That is a distribution primitive: a vendor whose server is throttled at the registry layer effectively has a lower ceiling on agent-driven query volume regardless of the vendor's own capacity.

The useful mental model is that the registry is not one thing. It is a stack: the protocol, the hosting, the catalogue, the model-vendor curation, and the enterprise policy layer. Placement in any one of those layers is a distribution asset. Placement in several, compounded, is a moat.

Why default-connector status compounds

The reason discovery-layer placement matters more than a first-order infrastructure story would suggest is that the effects compound in three directions at once.

Query volume. An endpoint that is the default resolver for a common analyst query , channel checks, transcript search, consensus estimates, ownership data , receives most of the agent-driven volume for that category. The other endpoints receive the residual. In markets where agent-driven queries become a meaningful share of total workflow volume, the gap between default and non-default is not incremental. It is a step function.

Usage telemetry. The endpoint that fields the queries sees what analysts ask, in what sequence, with what refinements. That telemetry is a product input. It informs which fields to add, which query patterns to optimise, which adjacent tools to build. Vendors that see the query stream can iterate on it. Vendors that do not, cannot.

Retraining and grounding signal. Where agent responses are evaluated, corrected, or used to train downstream models, the endpoints that were called become part of the grounding record. Being the source that the model learned to trust for a class of question is a durable asset. It is not quite the same as being the highest-ranked search result, but it is closer to that than to being a vendor on an RFP shortlist.

These three loops feed each other. Volume produces telemetry, telemetry improves the product, improved product retains default status, default status produces volume. Any vendor that has watched a distribution channel commoditise knows the shape of this curve. The relevant historical parallels are search engine indexing in the early 2000s, iOS default apps in the early 2010s, and cloud marketplace featured listings in the late 2010s. In each case, the platform's discovery mechanic became more important to vendor economics than the underlying product parity would have predicted.

We are not claiming MCP registries will play out identically. The buy-side research market has structural features , compliance requirements, custom entitlements, deep incumbency , that dampen platform dynamics compared with consumer software. But dampen is not eliminate. The direction of travel is the same direction.

The buy-side procurement question, restated

A head of research at a hedge fund used to ask: which expert network do we contract with, which market data terminal do we standardise on, which alternative data vendors clear compliance. Those questions remain live. But they now sit on top of a more operational question.

When a portfolio manager or analyst opens the firm's sanctioned agent , a Claude workspace, a firm-internal copilot, a Perplexity Finance seat , and asks a specific research question, which MCP endpoints does that agent have permission to call, and which one does it default to for each class of question. That is the question that determines what the analyst actually experiences, what data the answer is grounded in, and what the audit trail looks like when compliance reviews the interaction.

Answering it requires the firm to make decisions that used to sit inside vendor UIs. Which registries does the firm trust as sources of MCP servers. Which OAuth scopes will it approve for which classes of query. What rate limits does it want at the enterprise gateway, independent of what the vendor imposes. Which endpoints are the default resolver for common queries, and which are optional secondaries that the analyst has to explicitly invoke. These are policy decisions with the operational weight of vendor selection, and most firms do not yet have the org design to make them cleanly. The people who understand the compliance implications are not the same people who understand the tool-call semantics.

We read this as the emergence of a new procurement discipline. Call it agent-runtime vendor management. It sits between traditional procurement and IT operations, and it is where a growing share of research-vendor value will be decided. The firms that build this capability early will select endpoints deliberately. The firms that do not will end up with the defaults their model vendor happens to ship, which is a decision made by someone else's product manager.

Counterargument: why this might not play out

A neutral read requires taking the other side seriously. There are at least three ways the registry-as-distribution-layer thesis is wrong or overstated.

Enterprise gateways route around public registries. Large buy-side firms may standardise on enterprise-internal MCP gateways that abstract away the public registry layer entirely. In that world, the firm's IT function maintains its own catalogue of approved servers, and the public registries matter only as a sourcing input, not as a distribution channel. Vendors would then compete for enterprise-internal listing, not public-registry placement. This is a real possibility. It does not eliminate the registry dynamic; it moves it inside the firewall and makes it firm-specific.

Custom entitlements resist commoditisation. Buy-side research contracts are heavily customised , seat counts, industry restrictions, compliance carve-outs, expert-call quotas. Agent-runtime resolution has to respect those entitlements, which means every tool call is entitlement-aware. That friction may slow the shift toward default-connector economics because the default is per-firm, not per-registry. Again, this dampens the dynamic without eliminating it.

Model vendors may commoditise the registry. If Anthropic, OpenAI, and Perplexity all converge on similar curated menus with similar verified-publisher criteria, the registry stops being a scarce inventory and becomes a table stakes listing. In that scenario, placement is easy to obtain and the compounding effect is weaker. The historical evidence from app stores and cloud marketplaces suggests convergence rarely goes that far , model vendors have product reasons to curate differently , but it is possible.

On balance we think the direction of the thesis holds even under these counterarguments. The magnitude and the timeline are more uncertain. A vendor that treats registry engagement as a 2027 problem is, in our view, likely to be moving too slowly. A vendor that treats it as the only problem is likely to be neglecting the enterprise-gateway and entitlements work that will govern the largest accounts.

What this looks like for named categories

The useful test of a category-level read is whether it changes how one thinks about specific segments. Without predicting any individual firm's outcome, we can sketch what the shift looks like across the segments INFLXD covers.

Expert networks. The traditional distribution mechanic , a research analyst logging into the network's UI to schedule a call, then waiting for a transcript , becomes one of several paths. The other path is an agent, mid-workflow, resolving a transcript-search or expert-availability tool call to whichever MCP endpoint it has permission to call. Networks that expose well-scoped MCP servers and secure verified-publisher slots inside the model vendors' curated menus will get more of the agent-driven query volume in the segments they cover. Networks that treat MCP as a compliance-only exercise will still get the human-driven volume, which is not zero, but they will not get the agent-driven flow.

Market data and analytics vendors. The historical moat has been depth of coverage and integration with the analyst's terminal. In an agent-runtime world, the moat also has to include being the endpoint the agent resolves for specific query classes. That means clean tool definitions, well-documented scopes, low latency, and a listing surface that a compliance team can evaluate without ambiguity. The vendors that already ship enterprise-grade auth and observability are advantaged here; the vendors that ship a single API key are not.

Alternative data providers. Historically the hardest segment for distribution because each dataset is niche and each buyer is bespoke. MCP registries are, in principle, a distribution improvement for this segment: an analyst's agent can discover a niche dataset via registry search in a way that would never have surfaced in a traditional RFP. Whether that improvement materialises depends on whether the registries develop the metadata and trust surface to make niche listings discoverable to enterprise buyers, or whether they collapse toward a small set of heavily marketed defaults.

Workflow and transcript infrastructure. Tools that sit close to the analyst's active work , transcript libraries, note systems, portfolio analytics , are particularly exposed to the agent-runtime shift because their value is realised inside the analyst's active loop, which is where the agent operates. Being the tool the agent calls by default when an analyst says find the passage where the CEO discussed pricing is a materially different distribution position than being one of five tools the analyst could have opened.

What we would ask an expert next

A neutral read closes with the questions that would sharpen it, not with a verdict. If we were setting up expert calls to test this thesis over the next six months, the questions would be specific.

• For a head of research at a multi-strategy hedge fund: what is the current org design for approving MCP endpoints inside your sanctioned agents, and who owns the decision , procurement, IT, compliance, or a new function?
• For a product lead at an expert network or data vendor: what share of your API-driven query volume in 2026 is coming from agent-runtime calls versus traditional programmatic access, and how is that mix trending quarter over quarter?
• For an engineer at a model vendor: what are the criteria for verified-publisher status inside your curated MCP menu, and how are those criteria evolving as more financial-services vendors apply?
• For a compliance officer at an asset manager: how do you audit an agent-driven research workflow when the tool selection happened at runtime, and what would you need from the registry layer to make that audit tractable?
• For a founder building an MCP-first research tool: which registry has produced the most durable installed base for you, and does that match where you thought distribution would come from twelve months ago?

The answers to those questions will decide whether this shift is a 2026 story, a 2027 story, or a slower migration. Our current read is that the shift is already underway at the infrastructure layer and lagging at the procurement layer, and that gap is where the interesting decisions get made over the next several quarters.