fix: reject trailing newline in tool-name validation

[Otis0408]

Summary

TOOL_NAME_REGEX in src/mcp/shared/tool_name_validation.py is end-anchored with $:

TOOL_NAME_REGEX = re.compile(r"^[A-Za-z0-9._-]{1,128}$")

In Python's default (non-MULTILINE) mode, $ matches at end-of-string or immediately before a single trailing \n. So a tool name ending in exactly one newline passes validation:

>>> validate_tool_name("evil_tool\n").is_valid
True          # expected: False (newline is not an allowed SEP-986 character)
>>> validate_and_warn_tool_name("evil_tool\n")
True          # no warning logged

The length guard uses len() (which counts the \n), so "a" * 127 + "\n" (length 128) also slips past both the length and the character check. Embedded and non-\n trailing control chars are already rejected correctly — only the single-trailing-newline case leaks.

Fix

Anchor the end with \Z (strict end-of-string) instead of $. No valid name is affected — re.match(r"^[A-Za-z0-9._-]{1,128}\Z", "abc") still matches; only "abc\n" now correctly fails.

Tests

Adds test_validate_tool_name_rejects_trailing_newline (parametrized over a trailing-newline name and a 128-char name whose last char is \n). Verified it fails on main (is_valid=True) and passes with the fix; the file's existing 29 tests are unchanged (no valid-name fixture ends in a newline).

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}