The builtin Tools supplied with SketchUp are not Ruby classes from which you can create new instances, in fact they are not accessible as Ruby objects at all. You can only tell SketchUp to activate one of them as John has shown if you know its name string or id number.
But perhaps more important is to understand that in the SketchUp Ruby API, “Tool” is not really a class, it is an “interface” or “protocol”. Yes, the API docs say “class”, but that is a conceptual error, probably stemming from the fact that in the underlying C++ language there can be “abstract” classes that declare but don’t implement methods. Possibly the built-in Tools are programmed using that technique. But Ruby doesn’t work that way because method invocation is always based on runtime lookup based on the name of the method. If there is no match, a runtime error results, but nothing has to be declared in advance.
The subsequent API doc text describing what a Tool does is more correct. That is, it defines a suite of methods that SketchUp may invoke on whatever Ruby object your code activates via Model#select_tool(). SketchUp uses Ruby introspection to detect which methods in the protocol your object will respond to and then invokes them as needed when the tool is active (i.e. the currently selected one). In that sense, whatever Ruby object has been activated using Model#select_tool is a “Tool”, even if it fails to implement any of the methods in the protocol!
The getMenu method (not Tool) is invoked when your Tool is active and the user right-clicks to open a “context menu”. This can be confusing, because the built-in Tools get “first dibs” at putting items on the context menu. You can’t change what they put there, and don’t even get access to the menu unless your Tool is active.