DAP Bellwether

DAP Bellwether

A regulatory change feed for financial regulators in Canada, the United States, the United Kingdom and the European Union, delivered as an MCP connector.

Free for people. Agents pay per call. Institutions can take a licence, billed by invoice.

Built and maintained by Dartmouth Advisory Partners, Toronto.

What it does

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.

Using it

Add the server as a custom connector in Claude:

https://bellwether.dap.solutions/mcp

1. In Claude, open Customize, then Connectors.
2. Click the plus button next to Connectors and choose add custom connector.
3. Give it a name, paste the URL above, and click Add.
4. In a chat, click the plus button, hover Connectors, and toggle it on.

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.

Tools

All four are read-only. There is no write surface.

Each tool's description, which is what an agent reads before it calls, opens with when to use the tool, then says what it does, then the price, in under 300 characters, for example: "Use when you have a record id and need to know whether the publication was amended and what changed. Returns the record in full with every revision observed since first collection. Free for 50 calls per caller each UTC day, then $0.01 USDC on Base per call via x402." The lines live in src/descriptions.js, which the tool list, the price list and the OpenAPI file all read; what an agent needs to build a call is in each tool's input schema.

Price

Free for people: 50 calls a day from any one address to the three data tools, reset at 00:00 UTC. An IPv6 caller is counted per /64, and every /64 in a /48 also shares a ceiling of ten allowances, so a larger block cannot be rotated into free calls. Only answered calls count. list_coverage, initialize and tools/list are always free.

Agents pay per call past that: $0.01 in USDC on Base, with x402 through DAP Agent Payments. An agent that cannot pay gets a payment required result, with the price and when the allowance resets. A call that fails is never charged and does not count. An answer is released only once its payment has been sent to the chain, one payment buys one answer however many Worker instances it reaches, and a payment may stay valid for at most an hour.

The paid tier is off until it is switched on (see Deploying). While it is off, every call is free and nothing is counted per caller. The landing page, /health and the MCP instructions all say which state is live.

JSON API

The same records as JSON over HTTPS GET, for agents and systems that do not speak MCP. Described in OpenAPI 3.1 at https://bellwether.dap.solutions/openapi.json.

There is no free allowance on the API: people use the connector, and an agent calling an API can pay. That is also what lets x402 directories such as Coinbase's Bazaar list it, since they index an endpoint by calling it and expecting the price. A request with an unknown parameter or a bad value is refused with 400 before any payment is asked for. A record that does not exist answers 404 and is never charged. since and until are compared as UTC times: a year, a month or a date alone covers that whole period, a time may use T or a space, and a time without a zone is UTC. A date the regulator did not publish is null, never our collection time. The record id is a query parameter so it never reaches the payment facilitator, which sees the path only.

Every priced endpoint's 402, and every payment required result from a data tool on /mcp, carries an x402 Bazaar listing: an example call that the endpoint answers with the price, its parameters field by field (as strings on the API, with what is required, the values an enum takes, integers as digits), and an example answer with a small schema, so a directory can list the call and an agent can build a valid one before it pays. /.well-known/x402 names all three priced endpoints. The listing is the same for every caller and holds nothing a caller sent. The examples are in src/bazaar-examples.json, written by npm run build:bazaar, which runs the real ingest, API and tools over records in the test D1 database and cuts each answer to its first record; the file says where its records came from and when. The copy here was built from the test regulator the tests use, a made up source at example.test. To list real publications instead, run npm run build:bazaar -- --feeds on a machine that can reach the regulators, then npm test, before deploying.

Institutional licences

Institutions can take a licence instead of paying per call: one agreement, one invoice, and a key for their agents, with no crypto wallet. One DAP licence also covers the Compute Market Tracker at dap.solutions/compute/. Licences live in their own D1 database, dap-licences (licences.sql), which both Workers bind as LICENCES and nothing else binds; the tracker counts its calls under endpoint names starting compute:, so one usage report covers both, and neither Worker can reach the other's records. The key (dapk_ and 43 characters) is sent as Authorization: Bearer or X-API-Key: on /mcp and /api. A licensed call skips the allowance and x402, and each answered call to a data tool or data endpoint adds one to the licence's daily count, which is what the invoice reads. On /mcp and the priced /api endpoints, an unknown or revoked key answers 401 rather than falling back to the free or paid rails, so a licensee finds out at once; /api/coverage, which is free, does not read keys. A key in any other shape, or two different keys, is refused the same way. A licensee may batch MCP calls while the paid tier is off, as anyone may, if every call in the batch carries a string or number id of its own; the batch's counts are written in one transaction before it is released. Any other Authorization header is ignored. Every licensed answer is counted before it is released; if the count cannot be written, the answer is withheld with 503. Keys are for the licensee's own servers and agents: the browser preflight does not allow these headers.

Coverage

Canada: OSFI, OSC. United States: SEC (press releases, and proposed and final rules through the Federal Register), 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:

• CIRO returns 403 to automated clients at every address, including the site root, so there is nothing to collect.
• TPR publishes no RSS feed.
• EIOPA publishes no RSS feed.

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:

• ESMA publishes no date on its items. Those records are ordered by when Bellwether first collected them, and every result says so in place of a date rather than showing a collection date where a publication date belongs. Their first appearance is a burst of items all collected the same day.
• The United Kingdom rests on the FCA alone. If that feed breaks, the jurisdiction goes dark, and list_coverage will show it.

Source limits

Some regulators' terms restrict commercial reuse. Records from OSFI, the OSC, the FCA and FINRA answer with title, date and link, so the regulator's own page remains the place to read them. FINRA collection is paused. ESMA material is available free of charge on the ESMA website.

Use of the API and connector is under the DAP API terms.

Architecture

cron (every 6h) -> ingest -> normalise -> hash -> D1

| MCP tools <---------+

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.

Notes on choices

• No auth. The entire surface is public regulatory material. There is nothing here to protect and nothing a user can damage, and skipping OAuth removes the largest source of directory review friction.
• Metering by address, not by account. An account would mean a sign in, which MCP hosts handle differently and many agents cannot do at all. A daily count per network address keeps the connector keyless, and x402 lets an agent pay per call without signing up for anything.
• D1 rather than Postgres. The store lives inside the same Worker with no external credentials and no egress. For a public read-only surface, fewer moving parts wins.
• The MCP layer is written directly against JSON-RPC. The reference SDK's HTTP transport expects a Node request and response pair, and the Workers path around it wants Durable Objects for session state. A read-only server has no session state worth keeping, so the stateless JSON mode the specification already permits is simpler and has less to break.
• Keyword search is `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.

Deploying

npm install

npm test # 173 tests, no network required (Node 22.5 or later) npm run verify:sources # confirms every feed endpoint is live, requires network

`verify:source