Consider adding `prefix` property to NamedArgument

Is your feature request related to a problem? Please describe.

The documentation of the NamedArgument name property is very clear:

"name": {
  "description": "The flag name, including any leading dashes.",
  "example": "--port",
  "type": "string"
 }

Yet it is widely misused in published servers. There are currently 49 instances of named arguments without leading dashes in the published servers and all of them are in error (according to their own docs, they require leading --).

I also did a brief search for any other MCP servers, SDKs, or toolkits that might use runtime or package args without dashes, and I did not find any (though I will grant that such use cases might exist, or might exist in the future).

Describe the solution you'd like

I would like to propose adding a prefix property to NamedArgument that contains the dash(es) (or presumably other) prefix, with that value defaulting to -- when not provided.

"prefix": {
  "description": "Optional prefix for the argument. Defaults to '--'. Set to empty string for no prefix.",
  "type": "string",
  "default": "--",
  "example": "--"
}

In our current situation, there is no way to detect or prevent the very common error of omitting required -- prefixes if we want to allow for the possibility (however remote) that the argument really doesn't have a prefix.

With an explicit prefix property (and default) we accomplish a few things:

• The documentation becomes even more clear and explicit
• The default behavior is correct for the mainline (only current?) use case and people who would have made the mistake of omitting dashes will be helped
• We have a mechanism to support communicating the case of an argument without a prefix if that ever happens ("prefix": "")
• By separating the prefix from the name, we can reasonably use the name without the prefix in template substitution, as in:

"transport": {
  "type": "streamable-http",
  "url": "http://127.0.0.1:{port}/mcp"
}

As opposed to how we would do this currently (if anyone using template substitution on a package transport actually used the correct notation, which they don't):

"transport": {
  "type": "streamable-http",
  "url": "http://127.0.0.1:{--port}/mcp"
}

Start by locating the NamedArgument definition and the package-transport template substitution handling. Review how the existing name property is validated and rendered, then define the prefix default and empty-prefix behavior; done means the schema, documentation, and affected substitution behavior consistently represent both prefixed and unprefixed arguments.