[everything] Documentation and implementation mismatch for complex_prompt temperature argument type

[PederHP]

Describe the bug
The everything server's documentation and implementation are out of sync regarding the type of the temperature argument in the complex_prompt. Additionally, this reveals a broader protocol limitation regarding argument type specifications.

To Reproduce
Steps to reproduce the behavior:

1. Send a GetPromptRequest JSON-RPC call to the everything server:

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "prompts/get",
    "params": {
        "name": "complex_prompt",
        "arguments": {
            "temperature": 0.7,
            "style": "formal"
        }
    }
}

2. The server fails because it expects temperature as a string, but the documentation implies it should accept a number.

Expected behavior
Either:

1. The server should accept a number for temperature as implied by the documentation, or
2. The documentation should specify that temperature must be a string

Additional context

1. This issue is masked in the Python SDK because it uses a string-to-string dictionary for arguments (dict[str, str]), automatically converting all values to strings.
2. This highlights a limitation in the MCP protocol: ListPromptsResult doesn't provide a way to specify argument types, making it difficult for clients to handle type conversion correctly without relying on external documentation.
3. Consider enhancing the protocol to include type information in the ListPromptsResult schema, or standardize on string arguments for all prompt parameters.
4. A possible enhancement to the protocol would be to add a type field to the PromptArgument schema:

"PromptArgument": {
    // ... existing fields ...
    "properties": {
        // ... existing properties ...
        "type": {
            "description": "The expected type of the argument (e.g., 'string', 'number', 'boolean').",
            "type": "string",
            "enum": ["string", "number", "boolean", "object", "array"]
        }
    }
}