Bazaar: GET /x402/discovery/bundles returns 500, making bundleSlugs unusable (+ follow-up on the curated flag)

_Filing here per the x402 repo's own routing: its issue templates state that Bazaar
catalog and discovery-API questions belong with the facilitator operator, not with
the open-source repo._

**1. Reproducible bug: the bundles discovery endpoint returns 500**

`search_resources` (Bazaar MCP) advertises a `bundleSlugs` parameter:

> *Filter to resources belonging to any of the named curated bundles (by slug). Multiple slugs use OR semantics. Available only when curation is enabled.*

The API reference documents the matching lookup as `GET /v2/x402/discovery/bundles` — *"Lists the available curated x402 workflow bundles. A bundle is an ordered, named grouping of curated x402 resources that together cover a common agentic workflow."*

Authenticated calls (CDP API key, JWT via `@coinbase/cdp-sdk/auth`), re-checked 2026-08-21:

```
GET /platform/v2/x402/discovery/bundles -> 500
GET /platform/v2/x402/discovery/bundles/ -> 500
GET /platform/v2/x402/discovery/bundles/ -> 500
{"errorMessage":"something went wrong","errorReason":"unknown_error","success":false}
```

Not a credential problem — same JWT, same minute:

```
GET /platform/v2/x402/discovery/resources?limit=1 -> 200
GET /platform/v2/evm/accounts -> 200
```

Unauthenticated the same path returns `401 Unauthorized`, so the request is
reaching the handler.

Impact: `bundleSlugs` cannot be used by any caller, because there is no way to
learn which slugs exist. Buyers can't filter by workflow, and sellers can't tell
which bundle their category belongs to.

**2. Follow-up on x402-foundation/x402#3136 — the `curated` flag shipped, thank you**

@ethanoroshiba, the flag you mentioned on 2026-08-18 is live. Confirmed on the
full catalog (15,183 resources) on 2026-08-21. Two small things worth a doc line:

- The field is **present and `true`** on curated resources and **absent** on
non-curated ones — not `false`. Clients have to test key presence, not value.
Worth stating explicitly, since the obvious `curated === false` check silently
matches nothing.
- The `curated` field isn't documented on the *Get discovered (Bazaar)* page yet;
the MCP `curatedOnly` default now *is* documented in the tool schema, which
already helps a lot.

**3. Category coverage — is European company data a gap you'd want closed?**

The curation requirements list *"category coverage"* as one of the editorial
criteria, so this is a question rather than a request.

Measured on the full catalog on 2026-08-21: 90 curated resources across 18 hosts.
As far as I can tell, none of them is a company registry / KYB source for
European jurisdictions.

For context on where I'm coming from: I operate **api.sirenic.eu**
(github.com/sirenic-eu) — 79 first-party endpoints over French and EU registry
data (company lookup, filings, beneficial owners, sanctions screening,
insolvency), all mainnet, all passing `POST /v2/x402/validate` with
`simulation.outcome: "accepted"`.

Two questions:

1. Is "European company data / KYB" a category CDP wants covered in the curated
tier or in a bundle?
2. You mentioned on 2026-08-18 that you'd raise a proper pipeline for soliciting
curation requests. Any update? Right now the Discord thread is the only
channel, and it has no acknowledgement path, so operators can't tell a queued
request from an ignored one.

Happy to provide endpoint lists, uptime history, or settlement data in whatever
form is useful

The report names no cdp-sdk files or tests; begin by confirming that Bazaar discovery is owned by the facilitator operator, then reproduce GET /platform/v2/x402/discovery/bundles with the documented authenticated and unauthenticated requests. Done means the responsible service no longer returns 500 and the Get discovered (Bazaar) documentation states curated-field presence semantics; the curation questions need an owner response.

Written by the indexing model from the issue text.