Totally. As I tell people, it's neither a query language, nor particularly graph-oriented. I describe it instead as a toolkit for writing custom domain-specific languages for your services.
Eh, I’d call it a query language in the same way that I’d call XML a language. I’ve heard the term metalanguage bandied about for XML, but it never really seemed to catch on. GraphQL could perhaps be called a query metalanguage, defining grammar and language semantics.
They're both metalanguages to me. You use them to define domain-specific languages. We may as well throw JSON in the mix, too. Sure, it's a language with its own grammar, but it's only really useful when implementing the semantics of an API contract (whether that contract is explicitly specified or not).
The reason I object to the "query" part is that GraphQL has no built-in operators that true query languages invariably have. All you really get is inclusion of fields into your request and parameterization. All other semantics have to be implemented by the user in their own spec.