You don't really want to do this. It provides for more overhead for one thing. Secondly when multiple SP's are in question often times it is a case of say the first SP stores some data and also gets the result of something (sets a bit field, or gets some value or derived value) which perhaps influences the next SP that is called, or if it is called at all, and so on.

If you have what I call a lead SP then it can call what it needs to as well as handle the business rule chain if there is one.

As an example you call your Lead SP. Based upon the data supplied it calls SP 2 and does an insert. Also because of the data it has or perhaps a mix of what it was fed as well as some return value from SP 2 it does not call SP 3 rather it calls SP 5 then 6 and skips 7 because of some accumulated result.

If the outcome had been different with the initial insert using SP2 perhaps it would have called SP 3 and that would have been the end of it.

You really don't need this logic at the application layer. This can all be handled with a single 'transaction' between the client and the DB resulting in a returned result to the client side.

Additionally business rules can be more dynamic without having to make calls to the DB as they can be stored in tables and acted upon within SP's.