From you explanation I conclude that:
1. GetTokenAt could return multiple tokens depicting full tokens (type, name, namespace, parameteres, etc), for example multiple functions.
2. GetAutocompList returns also multiple tokens, but they are different from the ones returned in GetTokenAt.
They are just member function names, type info, parameters.
3. The debugger needs only the full name or better name it the expression. No need for function parameters, type, namespace, etc.
The debugger needs the name of a member expanded to the full expression used to access it.
At the moment if you hover over a member you'll get just the member and if you try to evaluate it, you'll get "variable not found in scope", because you tried to evaluate variable "member1" instead of "a.b->c->member1". The debugger needs a way to expand a particular string word to the full expression at the cursor. So we need a different method here again.
Also I don't think you need to worry too much if you add too many pure methods.
If the plugin developer thinks it is best to handle them the same, he can do so no problem (he can add a common method and convert parameters).
Providing clear and separate names is better for source readability. An API where you have a few functions that do lots of stuff is most of the times worse than an API with many functions doing simple things each...
Also don't worry, just iterate on the API until it feels good to you...