This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
I think the tool would depend very much on what you are trying to accomplish.
My team tried using something which was essentially a bug-tracking system to track stories, requirements, and tasks.
It turns out, whiteboards and post-it notes were much more appropriate for us.
If you look at it from the vantage point of purpose rather than tools, Agile is about making it possible to produce a good quality product in a given amount of time - or several given amounts of time.
Certain practices help achieve that. Certain tools might also be more helpful than others, but even a great tool would be no help at all if there is no place for it.
A burn-down chart is not going to help much, if the product owners add requirements and stories every day - whether it is on a digital dash-board or a low-tech whiteboard.
I while back I was involved in creating a small utility using TDD. It was basic, did two things, but the code pretty much read like a newspaper article. Certainly, it wasn't perfect, but it was a nice little piece of code.
After a while, another feature was needed. Within two days, a base class had been copy/pasted, renamed to plural in order to add a feature, the display code suddenly contained calls to the database and was making decisions based on a mysterious status code.
The purpose of making it nice and clean was so that when it needed to be extended, we would have the flexibility of adding a feature without breaking any windows... I kind of doubt that a library would have helped keep that code clean. (A couple of hours of refactoring, however, did wonders)
I guess my personal opinion about tools, are that if they can let you work in an agile fashion - great, but even the best tools probably aren't going to bestow agility.