fix(mcp): seed new catalog entries on every onStart + integrations-first UI layout - #84
Merged
Merged
Conversation
…rst UI layout Two follow-ups to PR #83: 1. **Catalog seed was first-run-only.** The cf-portal entry I added to `mcp-catalog.ts` never appeared in `/api/mcp-catalog` because the endpoint reads from UserControl's `approved_mcps` table, which is seeded once when the table is empty. Existing DOs (i.e. mine, and everyone else's) had been seeded back when the catalog was just browser-rendering + github, so the new entry never propagated. Fix: use `INSERT OR IGNORE` on every onStart, keyed by `mcp_url` (PRIMARY KEY). New catalog entries flow through; admin edits and soft-deletes on existing rows are preserved. 2. **Integrations buried below Skills + Tools.** Settings panel order was Skills (~50 entries) → Tools (~30 entries) → Integrations. Moved Integrations above both. Skills and Tools are now wrapped in collapsed `<details>` so they don't dominate the scroll. No tests added — the seed behaviour is exercised implicitly by every test that hits `/api/mcp-catalog` (which seeds via onStart). The UI move is markup-only. beep-boop-🤖
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two follow-ups to #83 — the cf-portal entry wasn't showing up in the UI.
1. Catalog seed was first-run-only
/api/mcp-catalogreads from UserControl'sapproved_mcpsSQLite table. The seed code only ran when the table was empty, so existing DOs (seeded before cf-portal was added to the catalog) never picked up the new entry.Fix: Use
INSERT OR IGNOREon everyonStart, keyed bymcp_url(PRIMARY KEY). New catalog entries flow through; admin-edited / soft-deleted rows are preserved.Verified live: the deployed catalog endpoint returned only 3 entries (browser-rendering, dodo-self, github) — cf-portal was missing despite being merged in #83. With this fix, the next request triggers an onStart pass that inserts cf-portal.
2. Integrations buried below Skills + Tools
Settings panel order was: Skills (~50 entries) → Tools (~30 entries) → Integrations. You couldn't see the OAuth catalog without scrolling past everything.
Fix: Move Integrations to the top of that section. Skills and Tools are now wrapped in collapsed
<details>so they don't dominate the scroll either.Verification
npm run typecheckcleannpx vitest run817/817 passBonus context: CF Access bypass
Earlier you asked about the bypass. I checked — no bypass needed. The OAuth callback (
/agents/oauth/callback) is on the same origin as Dodo, so the popup inherits the user'sCF_AppSessioncookie when it returns from the OAuth provider. Verified with chrome-devtools by fetching the callback path from an authenticated tab — got 404 (route works, no OAuth code) instead of 302 to Access login. The existingDodo MCP (Bypass)Access app atdodo.jonnyparris.workers.dev/mcpalready proves the cookie-inheritance model; we don't need an analogous bypass for the OAuth callback path because the callback IS authenticated via the user's already-valid cookie.beep-boop-🤖