How thin should be controller in mvc

Last time I saw a lot of same mvc controllers which look like (it's not depend on difficulty of business logic method):

public async Task<A> MethodB(C c) => BllExceptionToCode (() => {
    return _bll.MethodB(c.ConvertToBll()).ConvertToApi();
});

So controller only does convertations between business logic and http.

Everywhere it's said that controller should be as thin as possible. But I think here can be some issues (for example above):

1. When controller method signature changed also should be changed business logic signature.

2. Overheaded methods in business logic, e.g.:

   public class Bll{
       public B GetById(int id){
           ...
           throw new BllNotFoundException()
           ...
       }
   }
   public class WebApiConverter{
       public void BllExceptionToCode(...){
           try{
           } catch (BllNotFoundException):{
               return SomeHttpCode()
           }
       }
   }
   
   

   In my opinion it's too overheaded. Why just not write like this:

   public class Bll{
       public B[] Search(SearchArgs args){
           ...
       }
   }
   public async Task<HttpResponseMessage> MethodB(C c) {
       var found = _bll.Search(c.id);
       if (found.Length == 0)
           return SomeHttpCode();
   };
   
   

   Some people said that the controller has business logic code in compare with zero, but I don't agree with them. Here is just transformation for WebApi contract (upper level contract should not affect lower level contract). Also this variant is more convenient for use then variant with exception. I think exception like NotFound should throw only method which guarantee object existance and it shouldn't affect lower levels.

So my questions are: How thin should be controller? Which operations he could be able to do except convertations to/from bll calls? Is it good to mirror WebApi inteface in BLL interface? Is it good to follow principle "call just one method from bll in controller method" ?