Extend resource NameValidation beyond tools (sources, authServices, prompts)?

[he-yufeng]

Background

#3654 added NameValidation (MCP v2025-11-25 tool-name rules) and the code comment above it says "we'll be implementing it across Toolbox", but as of main it is only wired into UnmarshalYAMLToolConfig (internal/server/config.go:387). Sources, authServices, prompts, and embeddingModels still accept any name.

Question

Which kinds should get the same validation, and is there a breaking-change window to respect?

• Prompts seem the clearest next step: prompt names go over the MCP wire via prompts/list and prompts/get, the same protocol surface as tool names, so the spec's name rules arguably apply there too.
• Sources / authServices are toolbox-internal references (a tool's source: field points at one). Names with spaces or commas currently parse fine, so tightening them would break existing configs that fix: add name validation to tools name #3654 deliberately left alone. If these should be validated too, a deprecation path might be needed rather than an outright rejection.

Happy to open a PR for whatever scope you prefer (prompts only, or prompts + sources with some compatibility story). Asking first since the right cut is a spec/policy call rather than a technical one.

[anubhav756]

Thanks for raising this @he-yufeng!

Agree that applying NameValidation to prompts makes sense and directly aligns with the MCP specification. A PR adding validation to UnmarshalYAMLPromptConfig would be very welcome! :)

Passing this to @Yuan325 for her thoughts. Because adding validation to internal refs could break existing user configs, and we might want to introduce a deprecation path?

@averikitsch for viz

[averikitsch]

Hi @he-yufeng what is the motivation behind this feature request? Have you seen any issues? This would be a breaking change for our users so I am hesitant to implement this type of validation. For MCP primitives like prompts, I would like for MCP to set this requirement so all clients/servers adhere to this. For Toolbox resources like authSources, EmbeddingModels, etc, these names are validated when the YAML is parsed. More validation shouldn't be required because they are not used by other systems.