Most won't do a full disassembly as it won't assemble again without a lot of work.
Instead a more targeted approach will be opted for.
I don't know what the kids are suggesting for a GB/GBC debugger these days. I quite liked bgb's debuggerhttp://bgb.bircd.org/
but another may have snuck in during the meantime (many GBA emulators do GB/GBC as an afterthought and some of those have some very nice debugging options).
The approach is simple enough regardless.
Standard cheat search to find the mana. https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial
, or in this case hopefully it is just a matter of use spell, check for change, use spell, check for change, use spell, check for change, maybe do nothing and check for what remained the same... If by some craziness you have some kind of anti cheat or pointer on a GB game (would be super rare but not impossible) then you can try to cut through it if you want but as you are already going to be fiddling with code as part of this might as well use that (it might not be what you want but if it changes as a result the point is moot).
Set a break on write to the mana location you just found. Cast the spell, it should then say hold up something just wrote to the area. This will be the end result of the calculation but you get to follow it back up the line.
Whether it will be its own individual code for the spell (possible but who knows, makes it harder to NOP a subtract) or fetches spell cost from a table (change table to 0, or whatever, in that case). You may need to go one further and do a check on reading the area if the game does some kind of check to see if you have enough mana to cast it in the first place, in which case break on read. Some might go for a break on read first of all and it is a path you can take.
If you need a GB/GBC hardware listing most would point you at the pandocs, including its weird flavour of 8080/Z80 instructions.https://gbdev.io/pandocs/