When you use a virtual service, you are testing the thing that calls the virtual service. You are not testing any back-end logic. Your virtual service should therefore not be replicating any back-end logic (see Joel's response for a "better" explanation of this ).
Look at the panel of requests at the bottom-left of the Service Image window. You can see that it has two examples there. The first is called "META", which would be your usual response (either make it always work, or always fail, depending on the reason for your testing). The second is the name of your operation with the specific values for "a" and for "b" that you recorded. There is also a "+" button at the bottom of that panel, for you to add extra instances of the operation.
For any extra responses that you add, you can do some great things, so go ahead and add an operation there. Highlight it, and then look at the information to the right. You want to expand the "Request" section, and change your "a" and "b" values. Make them both "99" for now. This response will be selected when you set both "a" and "b" to "99".
Now expand the "Response" panel, and you can manipulate the response that you expect for the instance when you try to add 99 to 99. This could be anything you want to test. It might be that your "calculation" gives an invalid value (9999999999, "fish", true, etc), it could be that it gives a boundary condition (0, -1, 32767, 32768, 4294967295, 4294967296, etc), it could be that it uses invalid separators for your locale (1.234,00, etc).
But remember that this is a service that will execute in a distributed platform, so there are other things that need to be tested. Look at the "metadata" tab for this response. It has a response code of "200". You should be testing that your client can cope with other response codes in an elegant manner, so get it to respond with a "404" (and change the response code text to "not found").
Finally, how do you test what happens in your client application if you send the response at an unexpected time? You look at the bottom of the response panel, and change "think time" to an interesting value; perhaps 0, or 1 millisecond over your HTTP timeout value, or a few hours.
So, for this one example of adding 99 to 99, I have given examples above of about 14 different incorrect responses, each of the incorrect responses designed to test a different thing in your client application. Your "correct calculation response" is only one response to add to that, and it's the least important one, because you could have an instance of your operation (add an instance of 99+98) that responds with 197.
So, you add all 15 of these different response instances for your operation, each one having a different reason and testing a different thing, and you let your tester know about all the different negative tests they can use. Suddenly, their testing can encompass all the client error parsing logic, the code coverage of their tests is (more) complete, both risk-based testing and test-driven development are enhanced, and none of this enhanced functionality has needed a single line of scripting or coding.