It's obvious isn't it? Anyone who has used agile practices with any frequency knows that there is no one particular ‘Agile’. There is no methodology - only a set of practices which, if followed correctly, will help a team be adaptive enough to actually deliver valuable software.  

Not only do the practices vary across schools of Agile - like Scrum, XP, and Crystal - but projects within one school vary widely even when delivered by the same group of people. Although this is disconcerting to many people from more traditional IT backgrounds, where process ensures consistency, the adaptability of agile is its secret sauce. If I prescribe how a team should work, then I inherently constrain it from creating a process that works for its problems or changing when a need arises.  The key is to let a team do its own thing with a minimal level of constraint to assure accountability, not consistency.

If we take the variety, ‘fungiblilty’ and adaptability of agile as given and I start to think about the agile tools space, I'm confused.  Why would I want to use a tool that, by its design, prescribes a way for me to work?
Sounds like more unnecessary constraints to me.

Clay Shirky has done some really top-notch thinking on ontology and flawed categorization schemes (see Clay's post for a breakdown of the word ‘ontology’).  As part of his talk, he suggests that ontological categorization schemes are often problematic because they need to optimize organization in a way that's convenient for something or someone other than the user.  I think the agile tools space has been saddled with a categorization scheme that fits a similar mode of thinking.  It's familiar. There are projects - which have releases, which have iterations, which have stories, which have cards or tasks, etc.  In a sense, these tools have categorized your project artifacts before you've even created them.

For example, what if I want to run a lean project without iterations and do
everything just in time?  If I'm using a generic agile PM tool, do I need to shove everything into one iteration just to make the tool work?  With Mingle, I don't have to do that.

As Clay indicates, Google revolutionized the way people find things on the web, by hearing from the user and not trying to suggest a classification a priori - as Yahoo! did.  Similarly, Mingle will smartly give users the tools to define the way they work themselves.  It's designed to give users the tool support for their processes, not the "ThoughtWorks agile way." In encapsulating ten years of agile thinking into Mingle, we've determined that indirectly pushing you toward a particular process isn't very ‘agile’.