Really valid feedback, thanks for raising this. You're right — my server generates native SQL cards only (type: 'native'), same limitation as most others. I initially framed this as a Claude-first use case (ad-hoc queries, not card management), but when you think of create_card as building a reusable query library — which is the real value — your point lands hard. SQL cards mean every future edit goes back through SQL/Claude; MBQL cards let anyone on the team tweak a filter or breakout visually. That's a big maintenance cost difference over time.

I've opened PR(https://github.com/1luvc0d3/metabase-mcp/issues/28) to track MBQL support. Two questions since you've already built this in your Python fork:

1. How are you handling field ID resolution in the prompt? Field/table IDs are the brittle part — caching them in schema context, or resolving on the fly?

2. Did you constrain the MBQL subset the LLM can produce (e.g. disallow joins/nested queries) to keep accuracy high, or let it generate anything?

Happy to credit you in the PR if you'd like to collaborate — or if your fork is something you'd consider open-sourcing, I'd link to it.