## Summary

The bundled **Small Business** plugin ships QuickBooks at `https://ai-inc.quickbooks.intuit.com/v1/mcp`. That host returns an Akamai `403 Access Denied` to **every** request, including `/.well-known/oauth-protected-resource`. Because OAuth discovery is the first step of the sign-in handshake, the connector can never leave the `needs authentication` state and clicking sign-in does nothing.

This is not a stale bundle and not a local misconfiguration. The URL on disk is byte-for-byte identical to what the live connector registry serves today, so restarting the app and reinstalling the plugin both re-fetch the same correct config and change nothing. I verified both before filing.

The same 403 affects every Intuit `ai-inc` MCP host, not just QuickBooks.

## Reproduction

```bash
curl -s -o /dev/null -w "%{http_code}\n" \
https://ai-inc.quickbooks.intuit.com/.well-known/oauth-protected-resource
# => 403

curl -s -o /dev/null -w "%{http_code}\n" -X POST \
https://ai-inc.quickbooks.intuit.com/v1/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}'
# => 403
```

Response body is the standard Akamai `

Access Denied

` page, not a JSON or MCP error.

## Evidence

Discovery endpoint (`/.well-known/oauth-protected-resource`) status by host:

| Connector | Host | Status |
|---|---|---|
| QuickBooks | `ai-inc.quickbooks.intuit.com` | 403 |
| TurboTax | `ai-inc.turbotax.intuit.com` | 403 |
| Mailchimp | `ai-inc.mailchimp.com` | 403 |
| Stripe | `mcp.stripe.com` | 200 |
| Canva | `mcp.canva.com` | 200 |
| DocuSign | `mcp.docusign.com` | 200 |
| HubSpot | `mcp.hubspot.com` | 401 |

Every non-Intuit sibling responds correctly. HubSpot's 401 is a valid "credentials required" reply, which is what QuickBooks *should* be returning.

Things I ruled out:

- **Not user-agent filtering.** Reproduced with a normal Chrome UA string as well as curl's default. Related to the already-closed #47390, but that fix does not apply here since a real browser UA is still refused.
- **Not a local network block.** Reproduced identically from a residential/office Mac and from an unrelated Azure VM in `westus2`.
- **Not TLS interception.** Chain presents `CN=*.quickbooks.intuit.com` issued by `DigiCert Global G2 TLS RSA SHA256 2020 CA1`, and DNS resolves normally through `edgekey.net` to Akamai.
- **Not a stale or corrupt plugin bundle.** The on-disk `.mcp.json` carries the correct URL, the bundle is marked updated and verified, and the URL matches the connector registry entry for "Intuit QuickBooks" exactly.

## Impact

QuickBooks, TurboTax, and Mailchimp connectors are unusable and unfixable from the user side. Every Small Business plugin skill that depends on QuickBooks (`cash-flow-snapshot`, `month-end-prep`, `invoice-chase`, `tax-season-organizer`, `plan-payroll`, and others) silently loses its primary data source.

The failure also presents misleadingly. The UI says "needs auth", which reads as "the user has not signed in yet" and sends people through restart and reinstall loops, when the actual cause is server-side and outside their control. A discovery-time 403 would be worth surfacing distinctly from an un-authenticated connector.

## Secondary, lower priority

Several bundled plugins declare MCP servers with an empty `url`, which render in `/mcp` as **"No URL configured"** and look like corruption to users:

- `small-business`: `gmail`, `google calendar`, `google drive`
- `finance`: `snowflake`, `databricks`, `google calendar`, `gmail`
- `legal`, `marketing`, `human-resources`: `google calendar`, `gmail`

If these are intentional placeholders for connectors that are not wired up yet, they should probably be omitted from the shipped config or labeled as unavailable, rather than displayed as broken entries alongside genuinely broken ones. The mix made the QuickBooks problem considerably harder to isolate.

## Environment

- Claude Code 2.1.269, desktop app
- macOS 26.6.2, arm64
- Small Business plugin 0.3.0, from the `knowledge-work-plugins` marketplace

Start by rerunning the two curl probes against the Intuit discovery and MCP endpoints, then inspect the bundled Small Business .mcp.json and the /mcp rendering for empty URLs. Determine how a discovery-time 403 is represented separately from needs authentication, and whether placeholder entries can be omitted or labeled unavailable; done means the failure is surfaced accurately without restart or reinstall loops.

索引モデルが issue の本文から書いたものです。