I agree specific DVM kinds is kind of quirky. I think the issue is that the observed usage is different from how the spec was conceived.
Spec: specify a kind and see which npub replies
Actual use: tag a specific npub
If someone tags and npub that is set up to give a certain response, then the kind number seems redundant.
But IMO this kind of thing is always the issue with defining a new spec, including if you were to define a new one. IMO better to evolve what is already in use.
It's fine to do its own thing. Most kinds evolve from a shared space with other stuff to their own thing over time. It helps streamline the use case and set up specifics that only LLMs have, like the context window.
Check out what Gzuuus DBTH etc are doing with DVMCP. Each tool defines it's parameters in a NIP-89 declaration, then responds in the DVM style (5910, 6910, 7000), when tagged, based on those params.
Very extensible for any tool to use (an AI, or any API, as a tool). Can define and require any parameters (context window size for an AI, stock symbol for a price query, etc).
E.g.
I define a npub that is an LLM that will respond to users.
The npub publishes it's spec as NIP-89 including anything e.g. context window size.
A user publishes a kind 5910 note, tagging the npub, with content complying with the spec.
The npub replies with 6910 for success response or 7000 for anything else.
