MCP for regulatory data, in practice.

MCP is the right shape for a class of integration that did not exist three years ago: an AI agent reaching into a third-party data source, calling a typed tool, and consuming the result inline. For regulatory data, that’s a high-leverage surface. An assistant inside a compliance product can answer ‘what changed at the SEC last week in the asset-management sector’ without leaving the conversation. That is a real customer want.

Most of the regulatory data infrastructure we run for customers is not the AI agent surface. It is a stateful pipeline. A nightly job ingests the last 24 hours of alerts into a customer’s data warehouse. A webhook listener fans out new SEC filings to a Slack channel. A daily export populates a regulatory-change dashboard. None of that wants MCP semantics. All of it wants a REST endpoint, a webhook, or a flat-file drop, exactly the way it has wanted them for ten years.

Pattern one is MCP for the assistant, REST for the warehouse. Customers wire the same data layer through both: the AI surface uses MCP tools to answer end-user questions, and the back-end pipeline keeps the warehouse fresh through scheduled REST polls. Pattern two is webhook-first, MCP for ad-hoc lookups. The platform consumes new alerts in real time, and only reaches for MCP when an analyst is doing exploratory work. Pattern three is flat-file ingestion plus MCP for everything fresh. Heavily regulated environments want a SFTP drop for the corpus and a tool-call surface for the day’s news.

The right delivery shape is the one that fits the use case. We have customers running all four mechanisms in the same product, and we have customers who have settled on one and never look at the others. The point of the data layer is that the choice is yours, and the data is the same.