[Server] Add tool name validation for SEP-986#140
Conversation
chr-hertel
requested review from
Copilot
and removed request for
CodeWithKyrian and
Nyholm
There was a problem hiding this comment.
Pull Request Overview
This PR implements tool name validation according to the SEP-986 specification. The validation ensures tool names contain only allowed characters (a-z, A-Z, 0-9, dots, hyphens, underscores, forward slashes) and do not exceed 64 characters in length.
Key changes:
- Added a
NameValidatorclass to validate tool names against the SEP-986 specification - Integrated validation into the
Registryto log warnings for invalid tool names - Standardized debug message formatting to use double quotes instead of single quotes
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Capability/Tool/NameValidator.php | New validator class implementing tool name validation with regex pattern |
| src/Capability/Registry.php | Integrated name validator and standardized logging message format |
| tests/Unit/Capability/Tool/NameValidatorTest.php | Comprehensive test coverage for valid and invalid tool name cases |
| tests/Unit/Capability/Registry/RegistryTest.php | Updated test expectations to match new quote format in log messages |
| tests/Inspector/InspectorSnapshotTestCase.php | Removed unnecessary type hint comment |
| phpstan.dist.neon | Added exception for missing iterable value types in tests |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
chr-hertel
force-pushed
the
feat-tool-name-validation
branch
from
beafd6d to
964d7a3
Compare
| - | ||
| identifier: missingType.iterableValue | ||
| path: tests/ | ||
|
|
There was a problem hiding this comment.
this is addressing array shapes for DataProvider methods in tests - i don't think there is any value in defining them since it is only PHPUnit consuming those arrays not user land code.
|
|
||
| namespace Mcp\Capability\Tool; | ||
|
|
||
| final class NameValidator |
There was a problem hiding this comment.
I’m not sure we need to extract name validation into a separate class here. Tool names must follow a hard rule according the spec and not a user-configurable validation. So having dedicated NameValidator feels a bit unnecessary, especially since we don’t expect custom implementations of that validation.
Also, if we introduce a standalone validator for tool names, then for consistency we’d have to do the same for resource name validation (RFC3986), and resource template URI validation (RFC6570). But in those cases, the validation currently lives in the DTO constructors themselves, and that has worked well so far.
Since Tool, Resource, and ResourceTemplate are all DTOs, it feels more natural for Tool to validate its own name in the constructor, just like the others do. That way each object ensures its own invariants and we avoid adding more moving parts unless there’s a real need for pluggability (is there?)
Wdyt?
There was a problem hiding this comment.
yea, basically it was easiest since i wanted to do it test driven with those specs. and generally i'm totally in favor of small dedicated classes. but i get the OOP thinking of having it in the constructor and i thought about that, but for now it's not a hard requirement (if i got the SEP item correctly) but should rather only emit a warning.
we could make it a hard requirement tho and go one step further and just throw an exception in controller.
Close #137