Hello again, Is there any way for a shared dive to be edited by another admin who’s not the owner ? Claude and Cursor can’t find dive which are not owned by connected user even if he’s admin
I also tried this remix this dive, or by giving the id, but it never works
Hi Adrien, at this time updating another person's dive is not supported. Are you able to see the dive and its data in your org? And what happens when attempting to remix the dive?
Hi, Olivia, In web interfaces, I’m able to see the dives. I use a shared db link, so I can see the data and it works “fine” after some tweaking. When i try to “remix this dive”, AI first sees it, and gives the good informations, then it tells the user it can’t access it and ask if he wants to create a new one. Here’s a transcript
.png){kind=logo}
Here's what happened:
update_dive failed with Could not find Dive. With the MotherDuck MCP credentials in use, list_dives only returns these dives (owner_name: xxx):
[diveID#1] — [diveName#1]
[diveID#2] — [diveName#2]
[diveID#3] — [diveName#3]
...
Your [diveName#1] dive ([diveID#1]) is not in that list. read_dive still works on that ID (you can open shared or otherwise readable dives), but updating metadata requires ownership (or equivalent write access) for that dive, which this MCP session doesn't have.
What you can do
In the browser (recommended)
Open the dive while logged in as whoever owns it, use the UI to rename it to:
[diveName#1]
If you believe it's yours
Confirm you're logged into MotherDuck with the same account that created it. If MCP uses a different token/account than the app, align them (same user / PAT) and we can retry update_dive.
If you only have read access
You can't rename the original; you'd need the owner to rename it, or save a copy under your account with save_dive and the new title (that would be a new dive ID).
I can't complete the MotherDuck rename from this environment until updates are allowed for [diveID#1] with the current MCP identity. If you switch MCP to the owning account's token, say the word and we can call update_dive again.But it’s a shame because we would really like to use the tool to collaborate on dashboards for all our admin. The fact that we can’t edit the databases nor the dives that do not belong to us and that we cannot manage the permissions on it, is a big break. ❤️🩹💔
Missing database features aren’t a deal-breaker because of our automations, but we really need better collaboration on dives. Right now, our CEO creates dashboards that directors can view but not edit, which creates a bottleneck. We’ve paused our rollout for now, but as soon as collaborative editing is live, we’ll be all-in on MotherDuck. We really love the product! ☀️
The IT team also manages SQL and UI adjustments. Right now, they handle this by duplicating dives and performing optimizations locally. Once verified, they pass the code to director / CEO, who then uses AI to override his dive. 🙈
Hi Adrien, thanks for the detailed feedback! I've forwarded this to the product team. The collaboration bottleneck you're describing (CEO owns dashboards, IT team needs to edit them) is a compelling use case, and the fact that it's blocking your rollout is important signal for us. This is a known limitation today: dives can only be edited by their owner, and MCP only surfaces dives you own.
One thing that might work well for your team: we support Dashboards as Code. Dives can live in a git repo, and your IT team can propose changes via PRs (Claude can even open them for you). This gives everyone a proper edit-review-merge workflow without needing to be the dive owner: https://motherduck.com/blog/dashboards-as-code-dives/
Thanks for the input. We’ve already set up local dev logic to edit, improve, navigate through dives, add logics, buttons, ... But our goal is seamless dev/non-dev collaboration. Right now, and it seems also the CI/CD you linked, don’t allow to “pull” AI-driven changes made by directors back into our repo. Our “ultimate dream” is a bi-directional sync: non-devs create in MotherDuck via AI, then IT uses an MCP to pull those dives, refine the logic with internal snippets, and push the updates back. As mother duck handles versioning, it’s the perfect stream for us, as we make everything smooth for everyone.
Our current workaround is manual: we copy dive code from MotherDuck to our local repo, make changes, send it to non dev user, and he asks his AI buddy to update his dive. The bottleneck is that “send-back” phase; when the non-dev tries to use AI to edit our refined code, the AI often struggles. Even a web interface to update the code directly would solve this friction as mother duck already handle versioning
Would it be possible for your use case to implement the MD_GET_DIVE SQL function to (periodically) load the latest dive back to the repo? That way you can implement the changes onto the latest version of the dive, if edited by the directors/owner of the dive. Let me know if that would work, otherwise happy to think along for further solutions
Thanks for this input. We will implement MD_GET_DIVE to retrieve non devs created dives. But the main problem of no being able to update a dive if someone else owns it remains...
If IT owns the dive, “no-dev” users can’t update through AI.
If “no-dev” users own the dive, IT can’t update through CI/CD.
A temporary simple fix would be to allow us to add a new version of the code via the web interface. Owners/users could just “drop” or paste the new code into the UI, which would fix the collaboration problem between IT and non-devs...
and will remain the problem of two non devs trying to collaborate 😇
Absolutely, I have forwarded your feedback (both on the Dive ownership and the UI) to our product team! I understand that the current 1 owner setup adds difficulty to your setup but hope this workaround of CI/CD dives unblocks your collaboration on Dives!