fix(resources): escape literal regex metacharacters in ResourceTemplate.matches

[vidigoat]

Problem

ResourceTemplate.matches() (src/mcp/server/mcpserver/resources/templates.py) builds its matching regex by naive string substitution:

pattern = self.uri_template.replace("{", "(?P<").replace("}", ">[^/]+)")
match = re.match(f"^{pattern}$", uri)

The literal portions of the template are never re.escape-d, so any regex metacharacter in the template text is interpreted as a regex operator. This causes both:

• False positives — api://v1.0/{version} treats . as "any character" and wrongly matches api://v1X0/abc, routing a URI to a template it shouldn't match (returning {'version': 'abc'} instead of None).
• False negatives — a template with +, (, [, etc. in a literal segment (e.g. res://a+b/{x}) fails to match its own valid URI.

Fix

Tokenize the template into literal/placeholder parts, re.escape the literal text, and turn each {param} into a named capture group:

parts: list[str] = []
for literal, param in re.findall(r"([^{]*)(?:\{(\w+)\})?", self.uri_template):
    parts.append(re.escape(literal))
    if param:
        parts.append(f"(?P<{param}>[^/]+)")
pattern = "".join(parts)

Verification

before:  pytest tests/server/mcpserver/resources/test_resource_template.py -k escapes_literal_regex
         1 failed   (matches('api://v1X0/abc') returned {'version': 'abc'}, expected None)
after :  16 passed  (full test_resource_template.py)
no regressions: tests/server/mcpserver/resources/ -> 60 passed;
                tests/issues/test_129/test_141 resource templates -> green

ruff check and ruff format --check pass on both changed files. Adds a regression test asserting metacharacters in literal segments are matched literally.

[StantonMatt]

I checked this against the resource-manager routing surface, since the bad . behavior can let an earlier template catch a URI intended for a later one. With api://v1.0/{version} registered before api://v1X0/{version}, ResourceManager.get_resource(api://v1X0/abc) now returns the v1X0 template result (x:abc), while api://v1.0/abc still returns the dotted template result (dot:abc).

Local checks:

• uv run --frozen pytest tests/server/mcpserver/resources/test_resource_template.py tests/issues/test_973_url_decoding.py -q
• uv run --frozen ruff check src/mcp/server/mcpserver/resources/templates.py tests/server/mcpserver/resources/test_resource_template.py
• git diff --check origin/main...HEAD

[vidigoat]

Gentle nudge on this one whenever a maintainer has a moment. CI is green, and @StantonMatt independently reproduced the template-routing issue and verified the fix against the resource-manager surface. It's a small, self-contained change (escaping literal regex metacharacters in ResourceTemplate.matches) with a regression test. Happy to adjust anything — thanks for your time!

[Robin1987China]

Fix logic is correct: re.findall splits the template into literal/param pairs, re.escape() on literals avoids metacharacter interpretation. The (\w+) for parameter names properly constrains to valid Python identifiers (matching MCPServer's function parameter constraint).

The test covers . and + — good minimal coverage. Suggestion: consider adding a few more boundary cases for completeness, since the fix changes regex behavior for ALL special characters:

• * (asterisk) — could match zero-or-more incorrectly
• ? (question mark) — could act as optional quantifier
• ( ) (parentheses) — could create false capture groups
• A full-special-char regression test (e.g., data:.+*?^$|()[]{name}) to validate all metacharacters are escaped

These would prevent regressions if the regex construction is refactored later. Happy to share test cases if helpful.

AI assistance disclosure: Reviewed with AI assistance (opencode). I have verified the fix logic against the original bug report (#2961).