The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the DAP Bellwether listing page.
A free regulatory change feed for financial regulators in Canada, the United States, the United Kingdom and the European Union, delivered as an MCP connector.
No account. No key. No seat licence. Paste a URL and it is there.
Built and maintained by Dartmouth Advisory Partners, Toronto.
Bellwether collects what financial regulators publish, normalises it into one record shape, and serves it to any MCP client as a set of read-only tools. It holds prior state, so it can tell you that a document was amended after publication and what the earlier text said. That is the difference between detecting change and displaying a list.
Coverage begins from when the service first collected each source. It is not a complete historical archive, and the tools say so rather than letting an absence of results look like an absence of regulation.
This is a public information service. It is not legal or compliance advice.
Add the server as a custom connector in Claude:
There is nothing to authenticate and nothing to configure. Adding a connector does not switch it on by itself, so the last step matters. Free plan users are limited to one custom connector, which is one reason a Connectors Directory listing is worth pursuing. No submission has been made yet. On Team and Enterprise plans an owner adds it for the organization first.
The Worker also answers on https://dap-bellwether.dap-solutions.workers.dev/mcp, which is kept enabled as a fallback and serves an identical response. Hand out the bellwether.dap.solutions address.
| Tool | What it answers |
|---|---|
search_regulatory_changes | What has a regulator published on this topic, or in this window |
recent_regulatory_changes | What is new across all regulators |
get_regulatory_change | Full record, plus every revision observed since first collection |
list_coverage | What is monitored, and how fresh each source is |
All four are read-only. There is no write surface.
Canada: OSFI, OSC. United States: SEC (press releases, and proposed and final rules through the Federal Register), FINRA, CFTC. United Kingdom: FCA. European Union: ESMA, EBA.
The live list is always what list_coverage returns, since a source that fails verification is disabled rather than shown.
Verified against the live web on 2026-07-24. Three regulators are deliberately absent:
They are listed as not monitored rather than quietly omitted, because the point of list_coverage is that an absence of results can be trusted to mean an absence of publications.
Two limits worth knowing:
list_coverage will show it.A scheduled job pulls each feed, normalises RSS 2.0, RSS 1.0 (RDF) and Atom into one record shape, hashes the content, and writes to D1. The MCP tools read only from D1 and never call a regulator during a user request.
That separation is deliberate. If the tools fetched regulators on demand, then every outage, rate limit or retired feed would become a broken connector in front of a user, and there would be no prior state to compare against, so nothing could actually be detected as a change.
Sources are isolated during ingest. One regulator failing is recorded against that source and reported through list_coverage; the rest of the run continues.
LIKE, not FTS5. At the volumes these feeds produce, LIKE with the jurisdiction and date indexes is comfortably fast, and it avoids keeping an FTS index in sync through revisions. Worth revisiting if the corpus grows an order of magnitude.verify:sources must pass before the first deploy, and again after any change to the registry. It checks that each feed resolves, parses, carries recent items and carries dates. The last two matter more than they sound: the first sweep of this registry produced two passes that were false, an SEC feed answering 200 while frozen since 2023 and an FCA feed returning twenty items with no parseable date between them. Both would have shipped as healthy coverage against a check that only asked whether a document arrived.
Anything that fails is corrected or set to enabled: false. Feeds that are legitimately sparse or legitimately undated carry an explicit flag on the registry entry, so the exception is recorded and reported on every run rather than the threshold being lowered for everyone.
Then:
The first ingest runs on the next cron tick. To trigger one immediately against the deployed database rather than waiting up to six hours:
Use --remote rather than plain wrangler dev. Local workerd cannot reach every regulator: OSFI and CFTC both fail there with a header-independent connection error while succeeding from Cloudflare's network, so a local run will under-report coverage and tell you a source is broken when it is not.
/health reports record count, feeds monitored, and any feed currently failing.
Both hostnames should return byte identical output. If the custom domain fails while the workers.dev fallback answers, the problem is DNS or the certificate, not the Worker.
Add an entry to SOURCES in src/sources.js, run npm run verify:sources, and deploy. Nothing else changes: the parser handles the three feed dialects, and the tools read whatever is in the store.
The connector collects no personal data. This page counts visits without cookies or identifiers.
This section is kept word for word in step with the privacy section rendered on the landing page, in src/landing.js. Change one and change the other.
MIT. Use it, fork it, run your own. No lock-in.