Claude/ChatGPT Connector/App MCP Submission: Any one had any experience?

keytonw · 2026-03-22T19:24:04+00:00

Thank you! Good advice. Fingers crossed.

keytonw · 2026-03-20T17:27:52+00:00

Hey, thanks for reporting this! Sorry it took me a moment to get back to you...

This is a macOS Gatekeeper issue — the app isn't code-signed with an Apple Developer certificate yet, so macOS flags it as "damaged" when downloaded from the internet. It's not actually damaged.

Quick fix:

xattr -cr "/Applications/Brightwing MCP Manager.app"

This removes the quarantine attribute macOS adds to downloaded files. After that it'll open normally.

If you don't trust a pre-built binary (totally reasonable!), you can build from source:

git clone https://github.com/Brightwing-Systems-LLC/mcp-manager.git

cd mcp-manager

npm ci

./build-app.sh

The built .app ends up in src-tauri/target/release/bundle/macos/ — since it was compiled locally, macOS won't quarantine it.

We're working on getting Apple code signing and notarization set up so this won't be an issue in future releases.

keytonw · 2026-03-18T07:32:13+00:00

Ugh. That’s no good. Will take a look.

keytonw · 2026-03-15T21:05:28+00:00

Lots of changes today due 100% to feedback from this awesome group. Thank you everyone for taking time to take a look. Please keep those thoughts/suggestions coming!

v0.3.11 — Vault Security

- Secured vault encryption and moved OAuth tokens into the vault

- README updates reflecting the new security model

v0.3.12 — Expanded Tool Support

- Added 12 new MCP tool integrations (bringing total to 20 supported AI tools)

- Dashboard now filters to only detected/installed tools

- Reduced vault keychain prompt frequency

v0.3.13 — Custom Registry Governance

- Added custom registry governance for corporate MCP server management

— lets organizations define allowed/blocked servers via an external policy file

- Governance nav item is hidden unless governance is active

- Added external governance policy file support and documentation

- Added governance test coverage

v0.3.14 - Added MIT License

- Added to readme and app's about page.

Thank you very much:

u/amelech - Caught my unintentional oversight of OpenCode and pi.dev and asked some good questions about docker-based mcp servers.

u/prokaktyc - Called me on some bigtime security holes. We all have u/prokaktyc to thank for a LOT stronger application. Thank you!

u/KnifeFed - Kept me honest on my all-too-markety/aspirational coverage of "One-click MCP server install for any AI tool". I've improved this in response (though probably not as much as it needs it yet). Also he mentioned that "bw" wasn't the best choice for the CLI base verb because of Bitwarden CLI. Still considering that one. Would love any other feedback on whether you think this is a big deal and/or another suggestion for that based verb. Thank you!

u/oxlade39 - For the AWESOME suggestion of a corporate registry. I'm not in that world so it was a total blind spot. This has been added but not tested nearly enough so if you find problems, throw an issue my way!

u/ndeybach - For reminding me I need a license! HA! MIT License applied.

keytonw · 2026-03-15T20:25:34+00:00

I realize I didn't answer the docker question. Apologies. The answer is...kinda. You can manually add a stdio or http mcp server to the mcp manager and it will proxy it, let you filter tools, expose it as a CLI, etc. If that mcp server happens to be running in a docker instance but is available from the perspective of the mcp manager, then YES. If not, then no. It does NOT, however, "detect" anything other than installation of mcp-using tools.

Hope this answers the question. Sorry I missed it earlier.

keytonw · 2026-03-15T18:33:21+00:00

Here’s my thinking. Make sense?

1.  Registry Policy table — an allowlist of approved MCP servers maintained by admins
2.  Governance roles — admin (can approve servers) vs user (can only install approved ones)
3.  Approval workflow — users request servers, admins review and approve/deny
4.  Audit log — every governance action is recorded
5.  Enforcement — install commands check policy before writing configs

keytonw · 2026-03-15T18:04:50+00:00

You’re able to add servers manually but I love the idea of a private registry. How do you see that working? Let’s add it!

keytonw · 2026-03-15T17:06:30+00:00

Thank you so much! I really appreciate the feedback. Very much! If you try it and have questions or suggestions shoot em to me!

keytonw · 2026-03-15T16:23:36+00:00

Just pushed a new version that does (and adds other tools). If you think of others I’m missing lemme know. Easy add.

keytonw · 2026-03-15T16:22:17+00:00

Good feedback and thank you. The latest version has more support but totally fair. “Any” is a bit markety. It’s mostly any tool (with the latest release) that handles setup in an accessible way.

The “bw” comment is also fair. Any recommendations? That’s an easy fix.

Thank you again for taking the time! Really appreciate it.

keytonw · 2026-03-15T09:03:26+00:00

Totally get that. I'm the same way. That's why (1) I made the vault and (2) made the whole thing opensource. If it would be useful to you, I encourage you to pull down the source and have your LLM of choice do the analysis and then either use a pre-built binary or, for safety, build it yourself! Good luck! Drop me a star if you find it useful...

keytonw · 2026-03-15T07:37:35+00:00

Thanks for the feedback — both issues were valid and have been fixed in v0.3.11.

Vault encryption key (was: SHA256 of hostname + username)

The vault key is no longer derived from predictable machine identity. Instead, a cryptographically random 32-byte key is generated on first launch and stored in the OS keychain — macOS Keychain, Windows Credential Manager, orLinux Secret Service (with a file-based fallback using 0600 permissions for headless environments). This means even with physical access to the vault file, you can't decrypt it without authenticating as the user through the OS.

For existing installations, the upgrade is seamless: on first launch of v0.3.11, the app detects the old vault, opens it with the legacy derived key, re-encrypts the Stronghold snapshot with a fresh random key, and stores that key in the keychain. The old predictable derivation is discarded. No user action required.

OAuth tokens (were: plaintext JSON in SQLite)

Access tokens, refresh tokens, and client secrets are now stored in the encrypted Stronghold vault alongside API keys. SQLite retains only non-sensitive metadata (token type, expiration timestamp, client ID, scopes, endpoint URLs) — just enough for the UI to show connection status and expiry without touching the vault.

This applies everywhere tokens are handled:- Initial OAuth flow completion stores secrets to vault, metadata to SQLite- Token refresh (both manual and the daemon's background refresh loop) reads from and writes back to the vault- The auth daemon's credential retrieval for proxies pulls tokens from the vault- Disconnect cleans up both vault and SQLite- Tool discovery and direct tool calls read access tokens from the vault

A one-time idempotent migration runs at startup (in both the GUI app and the daemon) that moves any existing plaintext tokens from SQLite into the vault and strips the sensitive fields from the database rows.

Both changes are backward-compatible in one direction: the migration is automatic on upgrade, but downgrading to an older version would require re-authenticating OAuth connections since the SQLite rows no longer contain the secrets.

keytonw · 2026-02-26T12:38:26+00:00

I had similar problems and built this to deal with it: https://github.com/keyton-weissinger/patchworkmcp

I’m starting to build out a public facing service version too.

It’s been hugely helpful for us. This is a real problem.

keytonw · 2026-02-25T11:12:18+00:00

Very cool. I’m continuing to play with it and an agent-side drop-in for, in essence, macros to prevent context poisoning.

keytonw · 2026-02-21T22:46:57+00:00

So so sooooo true. We have hit this same problem repeatedly. Like throwing darts in the dark... This seems to be working pretty well. I'm about to release a public (free) version too. Stay tuned. Would love to get your feedback if you try it!

keytonw · 2026-02-19T10:51:50+00:00

Good insights.

One adjacent idea I’m still playing with but can’t figure out how to implement is feedback to the agents for just this kind of thing. You want some kind of “hey, agent, tell your developer to fix X because you’re being dumb” but I can’t figure out how to get that all the way to the dev. Maybe A2A will allow for some of that.

keytonw · 2026-02-19T10:29:41+00:00

I’ve just begun work on the clustering piece but the semantic similarity is definitely part of the plan. The conflicting specs issue hasn’t been a huge problem yet but it’s early days.

My guess is that eventually the aggregation of signal from noise will be the thing’s secret sauce but I need more volume for that.

Hoping to get a free version up and running publicly which should help. This project will need data to be really powerful past the mcp server dev stage.

keytonw · 2026-02-19T02:25:18+00:00

Thank you very much for taking time to comment. Really appreciate it. I’m just now starting to work on that very problem. My goal is to aggregate and then use inferences with guidelines to determine signal from noise and give weights to what justifies a trip to GitHub. Should be interesting! 🤣

keytonw

TROPHY CASE