fix(server): reject non-string group names - #3630

Good catch on name validation! :)

Is there a reason to completely reject non-string names? For MCP specification, the tool name have these rules (https://modelcontextprotocol.io/specification/draft/server/tools#tool-names) :

• Length: 1–128 characters
• Case-sensitive
• Allowed characters: A-Z, a-z, 0-9, _, -, .
• No spaces, commas, or special characters
• Unique within a server_

Seems like numbers and certain characters are allowed~ should we follow these? prompt names does not have any rules.

Thanks a lot @Yuan325,

The key distinction here is between the allowed characters inside a name and the underlying data type parsed from the YAML.

While the MCP spec allows digits (0-9) as characters, the protocol uses JSON-RPC, meaning the name identifier must fundamentally be typed as a string.

If a user writes name: 123 in their config without quotes, the Go YAML parser strictly evaluates it as an int. This correctly causes the .(string) type assertion to fail because an integer is not a string.

If we were to accept raw integers and secretly convert them to strings under the hood, we'd be bypassing strict YAML typing, which is innaccurate (e.g., a boolean name: true turning into "true").

Users are still completely free to use numbers in their names! They just need to explicitly quote them (e.g., name: "123"). The YAML parser will then treat it as a string which passes the type assertion, and our NameValidation regex perfectly handles validating the characters against the spec.

Hi @Deeven-Seru, in the config file, if a user defines name as an integer (like name: 123) and our server rejects it, that is completely acceptable and expected. Because we unmarshal into a generic map[string]any first, the parser evaluates 123 as an int, meaning the .(string) type assertion will fail and safely return an error stating that a string is required.

I also noticed that @twishabansal has already added test cases specifically covering these scenarios (like name: 123), which should address your concerns and ensure our validation behaves correctly.

LMK if you have any other thoughts! :)

I also just realized that the NameValidation was removed previously during migration to flat-format config file, I'll submit a PR to add that back to Tool's unmarshaling~ Thanks for point that out @Deeven-Seru :)

🧨 Preview deployments removed.

Cloudflare Pages environments for pr-3630 have been deleted.