Skip to content

Change default name casing of McpServerXx.Create tools/prompts #568

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 1, 2025

Conversation

stephentoub
Copy link
Contributor

@stephentoub stephentoub commented Jun 27, 2025

Following the guidance at https://code.visualstudio.com/docs/copilot/guides/mcp-developer-guide#_naming-conventions, changes McpServerTool.Create and McpServerPrompt.Create to use lower_snake_case for tools and camelCase for prompts when no name is explicitly specified and we derive a name from the method name.

@timheuer, @halter73, @eiriktsarpalis, @mikekistler, @AArnott, thoughts?

Copy link
Member

@eiriktsarpalis eiriktsarpalis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@stephentoub
Copy link
Contributor Author

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.

@AArnott
Copy link

AArnott commented Jun 30, 2025

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.

@stephentoub stephentoub marked this pull request as ready for review July 1, 2025 03:23
@stephentoub
Copy link
Contributor Author

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.

Copy link
Contributor

@halter73 halter73 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems reasonable for now given it follows VS Code guidance. I hope we can change this again in the future without us considering it too breaking.

Copy link
Contributor

@halter73 halter73 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems reasonable for now given it follows VS Code guidance. I hope we can change this again in the future without us considering it too breaking.

@stephentoub stephentoub merged commit 4411f1c into modelcontextprotocol:main Jul 1, 2025
7 checks passed
@stephentoub stephentoub deleted the namingcasing branch July 1, 2025 20:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants