fix: do not percent-decode query parameter names in match

RFC 6570 expansion never percent-encodes variable names, so a
legitimate match will always have the parameter name in literal form.
Decoding names before the duplicate-key check let an attacker shadow a
real parameter by prepending a percent-encoded duplicate:

    api://x?%74oken=evil&token=real  -> {token: evil}

With this change the encoded form is treated as an unrecognized
parameter and ignored, so the literal form wins.

Author: maxisbey

src/mcp/shared/uri_template.py

@@ -560,13 +560,18 @@ def _parse_query(query: str) -> dict[str, str]:
     ``+`` as space for HTML form submissions, but RFC 6570 and MCP
     resource URIs follow RFC 3986 where only ``%20`` encodes a space.
 
+    Parameter names are **not** percent-decoded. RFC 6570 expansion
+    never encodes variable names, so a legitimate match will always
+    have the name in literal form. Decoding names would let
+    ``%74oken=evil&token=real`` shadow the real ``token`` parameter
+    via first-wins.
+
     Duplicate keys keep the first value. Pairs without ``=`` are
     treated as empty-valued.
     """
     result: dict[str, str] = {}
     for pair in query.split("&"):
         name, _, value = pair.partition("=")
-        name = unquote(name)
         if name and name not in result:
             result[name] = unquote(value)
     return result

tests/shared/test_uri_template.py

@@ -450,6 +450,11 @@ def test_expand_rejects_invalid_value_types(value: object):
         ("search{?q}", "search?&q=hello&", {"q": "hello"}),
         # Duplicate query keys keep first value
         ("search{?q}", "search?q=first&q=second", {"q": "first"}),
+        # Percent-encoded parameter names are NOT decoded: RFC 6570
+        # expansion never encodes names, so an encoded name cannot be
+        # a legitimate match. Prevents HTTP parameter pollution.
+        ("api://x{?token}", "api://x?%74oken=evil&token=real", {"token": "real"}),
+        ("api://x{?token}", "api://x?%74oken=evil", {}),
         # Level 3: query continuation with literal ? falls back to
         # strict regex (template-order, all-present required)
         ("?a=1{&b}", "?a=1&b=2", {"b": "2"}),