Disagree.
Language is not an immutable thing and is always evolving in its use to reflect the concepts of the people using it. I think capitalizing Agile as a noun makes it a "thing" that we can refer to collectively and ultimately helps us communicate about the concepts that it entails. The unfortunate down-side is when a popular term is misused due to ignorance and misunderstanding by a large group of people - which will happen more prevalently as a word becomes popular.
As someone who has had the pleasure of receiving Scrum coaching from Jeff Sutherland, I can say that there is a HUGE difference in understanding between people who spend time to learn it (from a book or coach) and those who muddle their way through - never taking the time to learn about it more deeply and put it to practical use (the only way to truly learn is through doing).
I work at a small company and teach an internal course on the principles of Scrum to our project managers, so I have first-hand exposure here. It's amazing how really smart people who have heard the terms used for several years and even claim to have been involved in Scrum teams at past jobs still have many misconceptions about the core principles and how to practically apply them when the situation arises. There is definitely a shallow understanding amongst a good majority of developers and it's exacerbated by companies that claim to use "Agile" practices yet have only really scratched the surface. It's immediately clear that many have used "Scrum-but" and really only do standup meetings as if that will be all that is needed. Actually many people think Scrum is "that process where you hold standup meetings".
I like Scrum because it brings together not only a way to manage a project, but more importantly a way to lead a team of people! I think being a servant leader to the team and providing them the necessary resources to be at their peak effectiveness is a trait of a good leader. It's actually kind of amazing all the different ways even very smart people can get "stuck" - distracted by a less important task that is shiny and interesting, slog through hours of debugging to resolve an issue that someone else on the team could have helped them with, not communicating with other team members that they can't get their part done unless another has provided them something first. From experience, just helping people identify these blockers and get the team unstuck has been a big win.
I think tools absolutely are a big help too. I've used sticky notes on whiteboards and it's good for small teams that are co-located. It breaks down for distributed teams. We just started using JIRA and it is surprisingly good at helping us managing all of our work which would grow unwieldy using more primitive methods.
I'm not sure how I feel about the agile manifesto. I guess it has its historic place as a reaction against the poor waterfall practices of the past and paved the way for new methods to emerge. Besides that, it seems a bit dated and hasn't served a useful practical purpose for me.