Skip to content

Conversation

@tanish111
Copy link
Contributor

@tanish111 tanish111 commented Nov 18, 2025

Motivation and Context

modelcontextprotocol/modelcontextprotocol/issues/986

How Has This Been Tested?

Manual testing in examples/servers: added name to existing #[tool] attributes in common/counter.rs with valid and invalid names. Rebuilding and running showed expected warnings. Unit tests (11) cover validation scenarios; integration tests are planned.

Breaking Changes

None, but console warnings may appear for SDK users who have names that do not satisfy the SEP.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

All design decisions, names, and other aspects follow the TypeScript implementation for consistency across SDKs.
Related issue #518

Adds validation for MCP tool naming conventions as specified in SEP-986.
Ensures Rust SDK enforces standardized tool name formats, provides clear
errors for invalid names, and improves consistency across implementations.

Signed-off-by: tanish111 <[email protected]>
Update doctest examples to use the correct module path
rmcp::handler::server::tool_name_validation instead of
rmcp::model::tool_name_validation.

Signed-off-by: tanish111 <[email protected]>
@github-actions github-actions bot added T-core Core library changes T-handler Handler implementation changes labels Nov 18, 2025
@tanish111 tanish111 changed the title Feature/sep 986 impl Implementation of SEP-986: Specify Format for Tool Names Nov 18, 2025
alexhancock
alexhancock previously approved these changes Nov 19, 2025
Copy link
Contributor

@alexhancock alexhancock left a comment

Choose a reason for hiding this comment

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

LGTM other than the one comment. I also prefer to remove most of the comments for code that is already clear.

let result = validate_tool_name(name);

// Always issue warnings for any validation issues (both invalid names and warnings)
issue_tool_name_warning(name, &result.warnings);
Copy link
Contributor

Choose a reason for hiding this comment

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

I would check if there are warnings here and only call the method if there are warnings as opposed to having that check internally

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@alexhancock I have updated the code with this suggestion.
(This would definitely save unnecessary stack calls)
Also I have remove most of comments just kept the one which are needed

Prevent empty warnings array from triggering warning output.

Signed-off-by: tanish111 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

T-core Core library changes T-handler Handler implementation changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants