The guidance makes mention of parameters needing to be camelCase. Is this something we'd want to enforce or is it safe to assume parameters will almost always be conformant?

For method names, the .NET guidelines differ, so I think it makes sense to proactively apply a transform.

For parameters, the guidance is the same, so I think we just don't bother unless we see notable problems.

The name is also much more prominent, in that it's the main thing that someone would use to opt-in / out a tool from being used.

I think applying a transform by default to automatically convert .NET to MCP naming conventions is a great idea. Ideally something that users can remove or override in case it does the wrong thing for specific cases.

Ideally something that users can remove or override in case it does the wrong thing for specific cases

Yes, this is already the case, using either the Name property on the attribute or on the options passed to the Create method.

Adding the breaking-change label. This PR changed the default name casing for tools, prompts, and resources created via McpServerTool.Create, McpServerPrompt.Create, and McpServerResource.Create from PascalCase to lower_snake_case (tools/resources) and camelCase (prompts). Consumers relying on the default-derived names will see different names after upgrading (e.g., Echo → echo, EchoWithUserName → echo_with_user_name). An explicit Name on the attribute or create options preserves existing behavior.