MVC is a quite general pattern. The idea is that you split code in three parts:
'Model' does data storage and data storage only. It should hold your raw numbers. Its job is to keep the data, and keep it consistent with each other.
It has an interface to query the numbers, and other properties, like how many you have etc. If your gui allows changing data, it should have an interface for that too, where it gets new data, or a request to change some data. The latter interface usually contains checks to see if changes are allowed.
Model on its own thus doesn't 'do' anything, it only provides an interface to get and change data. The details of how to handle a request (maybe you need to perform long and complicated computations to get some information) is hidden.
'View' is responsible for displaying things, and registering what a user does. It contains all visible boxes, buttons, etc, and catches user actions. Its main purpose is to hide all the details of the GUI, like sizes, layout, padding, fonts, colours, etc.
Like the model, a view doesn't do much on its own, it displays numbers if you give them to the view, and it sees "user pressed ok" things. It can also pop up new windows, like a data entry form.
The main purpose of view and model is to hide all the little details as much as possible, to make the work of the third component, the controller, easier. The controller 'glues' model and view to each other. It's contains the logic that decides what to display, and what to do when a user presses Ok, Cancel, or presses Escape.
The controller pulls information from the model, and passes it on to the view. It also receives the user actions from the view, and acts on it. It could get more data from the model (eg user presses 'next page'), or it could delete data from the model (user confirms 'delete this information? yes/no'), it can ask the view to display other gui elements (eg pop up 'are you sure you want to quit?').
I think the biggest problem is as people have said, design patterns are more of a guideline, and there are no concrete 'correct' ways that can cover all the different combinations of data processing that may be undertaken.
On the contrary, there are infinitely many concrete 'correct' ways to use MVC. It all depends on where you draw the border between Model, View, and Controller. In other words, you have the Model, View, and Controller concepts in your head, along with ideas what part should do what. From that, you can decide this class is Model and that class is Controller, etc.
Say you need to display the double value of some numbers to the user. Which element is doing the doubling?
The model could, as it provides values for the view. However, its job is to store data, not change it. The controller could, as its job is to forward data from model to the view, however, it should do logic and not computation. The display could, but its job is to display and not compute. In the end, you need to make a decision, and you pick the one that is 'best' (to you).
See MVC as a guide while you build the Gui. If you are manipulating data, it's Model. If you're handling details of Gui callbacks etc, it's View. If you are pulling data from the model when you are processing a button press, it's Controller.
By being aware of the partitioning, and the job of each of the three elements, you have a guide where a certain piece of code belongs. Try to put code with the same job close to each other, it should be beneficial.
On the other hand, don't use MVC (or any other pattern for that matter) as the one and only absolute truth that must be followed at all times no matter what the costs are. Patterns are general solutions for parts of the problem you are solving, which means that at some point you are crossing the border to 'outside the pattern'.
