we actually try to stay away from any specific tools, such as "you should use tool x for patterns work". Especially since Bruce and I both work for a tools vendor (IBM Rational) we felt that writing about specific tools would not benefit the message of which practices we have found make projects more successful. Tool are however very important, and can make a practice easy or very difficult to implement. This is why we have tool guidance as a key element of the Rational Unified Process, while making that guidance optional so you can choose whether to include it or not.
For each practice in the book, we have three adoption levels. Typically we tried to write the first adoption level so you need no or almost no tools. Often whiteboard, workd processor, etc. may be enough. For hgiher levels of adoption, we sometimes say that tings such as "for the more advanced level of this practice, you need a tool that can help you organize patterns into a reference architecture" or similar. We try to talk about the type of tool that may be useful, withouth being so specific so we talk about a specific tool.
Hopefully this helps explain how we thought about the topic of tools in the book, and our view of tools outside the book.