It's a fair point and really can only be answered by what functionality is required.
If the button click to load a source is only for the user's benefit (to inform the user that an object has been 'loaded'), then I wouldn't expect that data to need to go through to the model from the view. It can just be stored by the view until it's needed later.
The purpose of tool, model and view is to split the relative components into their respective systems. Ideally, this provides clarity, and robustness.
Even if the 'load source' button runs additional validation functionality to object viability then I would expect view to call a model.is_viable(node) check. I would still expect the view to retain the loaded object.
When the user presses 'apply', I would then expect the view to gather all relevant data and pass it to a single model entry point for executing.
The point being, you've written the model to be used without a view. You write the view to collect and pass data to the model.
If the line gets blurred then perhaps rethink your requirements, do you really need such separation? Is there another design that may be better suited?
If not, then pay the additional computational cost to maintain that separation. In the grand scheme of things, a user will typically expect a slight delay when applying an action via button anyway.
Sometimes optimisation isn't worth the cost of comprising a design pattern.
As for the concern regarding view -> tool -> model -> signal -> tool -> signal -> view, I understand the concern. It does seem overly complicated, and as I've mentioned, may not be the best design for your requirements.
The upside being, you could replace the view at anytime, without the need to manage functional code and you could use various models without the view ever needing to know which application it's being used in.
Edited: additional clarification.