DC Hub adapter merged — is there a public listing URL to link to?

[azmartone67]

The DC Hub adapter merged last week — thanks for building it. #653, adapter slug dchub, tracked on #652.

Is there a canonical public URL for the listing yet?

We'd like to link to it from https://dchub.cloud/connect, where we point people at the catalogues DC Hub is reachable through. Our CI refuses to ship a placeholder link on that page, so the card is written and parked until there's a real URL to put in it.

Checked today and couldn't find one, so we're likely looking in the wrong place:

URL
https://anythingmcp.com/marketplace	200, but no DC Hub entry
https://anythingmcp.com/connectors/dchub	404
https://anythingmcp.com/adapters/dchub	404
https://anythingmcp.com/integrations/dchub	404
https://anythingmcp.com/guides/connect-dchub-to-claude	404
https://anythingmcp.com/guides/connect-dc-hub-to-claude	404

If it lives under a slug we haven't guessed, just point us at it and we'll link that exact URL. If listings are generated on a schedule rather than at merge, knowing the cadence is enough — we'll wait and check back instead of probing.

Second, smaller question: dchub.live.spec.ts in #653 looks like a live conformance check. If it runs against production on your CI, roughly what does it call and how often? Nothing is wrong on our side — we'd just rather recognise it in our own traffic than treat it as unexplained, and if it needs a key or a higher rate limit to be genuinely useful, we're happy to arrange that.

Asked the first question on #652 as well, but that issue is closed and the PR thread is locked, so posting here per the contact-links guidance. Happy to answer anything about the OpenAPI spec or the tiering if it helps the adapter.

[keysersoft]

Both answered, and thank you for the second question in particular — the honest answer to it is not flattering to us.

The URL

https://anythingmcp.com/marketplace/dchub — live as of a few minutes ago, so your CI will accept it now.

The pattern is /marketplace/<slug>, which is why none of your six guesses hit. Localised variants exist at /<locale>/marketplace/dchub for de, it, es, ja, ru, zh, and there are setup guides at /guides/connect-dchub-to-<client> for claude, chatgpt, cursor and gemini.

On cadence: listings are not generated on a schedule. The page renders from our Cloud catalogue, so a connector appears once the backend image carrying it is deployed. That had not happened when you checked — the adapter merged four minutes after the deploy that would have carried it, which is the whole reason you found a 404. Not a cadence you can wait out; it needed a human.

The live spec

It does not run on your production, or anywhere, in CI. dchub.live.spec.ts is gated behind RUN_DCHUB_LIVE, and that variable is set in no workflow in the repository. CI runs the static half only — it reads the adapter JSON and asserts things about it, and makes no network calls.

It runs when someone sets the variable by hand. That happened twice this morning, both times me. If you see a burst of roughly 16 requests from one address hitting /api/v1/stats, /api/v1/facilities, /api/v1/markets, /api/v1/dcpi/scores/northern-virginia, /api/news, /api/v1/transactions, /api/v1/pipeline, /api/site-score, /api/grid/fuel-mix, /api/energy/prices/VA and the two POST analysis endpoints, over about twenty seconds — that is this file. Thank you for offering a key or a raised limit; it genuinely does not need either at that volume.

What that run found, since it concerns you

The adapter shipped describing two of the sixteen tools as needing credentials. Four do:

tool	we said	your API says
dchub_pipeline	keyless	403
dchub_energy_prices	keyless	403
dchub_site_score	keyless	403, and it needs Pro — no free key unlocks it
dchub_facility_detail	"requires a key, returns 403"	200, with _gated: true and coordinates at 2 dp

We read your old spec. Your corrected one declares all of this properly, and it was published after we had already merged. Our mistake, not yours, and it is fixed on main (#655, #656) along with the guides, which are generated from the adapter and had inherited the same four claims in seven languages.

The one that worried me most is facility_detail, because it does not fail. A model asking for a facility gets a plausible record with the contacts missing and nothing in the shape of the response to say so — only _gated in the body. Our tool description now says to check it. If you ever wanted to make that louder from your side, a _gated in the response is easy to miss next to a 200.

Also removed: 22,900+ facilities from our copy, per the request not to bake counts we cannot update. A test now keeps numbers out of the description, the instructions and every tool description — it had survived the first pass by hiding in one of the sixteen.

Happy to keep the conversation on the spec here rather than over email if it is useful to have it in public.