stacklok / toolhive / 37928562847

71%

Build Type

push

github

Committed by web-flow

Commit Message

Preserve list result members in authz filters (#6709)

* Preserve list result members in authz filters

The authz list filters decoded list results into types that model only some of their members, so every other result member was dropped before the response reached the client.
Under MCP 2026-07-28 that includes the required resultType, cacheScope, and ttlMs members, so clients that enforce resultType reject the filtered tools/list.
The filters now rewrite only the list member, write the rest of the result back unchanged, and keep the backend's raw descriptors for the items they permit.
An authz-filtered list depends on the caller, so its result is marked private with a zero TTL and the response carries Cache-Control: private, no-store, as resource template lists already do.

Signed-off-by: Aleksandr Filippov <71711753+alex-feel@users.noreply.github.com>

* Reject ambiguous tool annotations in authz

The authz tools/list filter forwards the backend's raw descriptors, while policies and the annotation cache use annotations decoded by encoding/json.
encoding/json matches member names case-insensitively, keeps the last of duplicate members, and merges a repeated annotations object.
A descriptor that repeats an annotation hint or spells it with a case-insensitive alias could therefore be authorized on a hint value the client does not see.
The filter now fails closed, as it already does for an ambiguous tool name, when a tool repeats its annotations member or any member of the typed annotations, or spells one with a case-insensitive alias.
The tools carried in find_tool output are validated the same way before authorization.

Signed-off-by: Aleksandr Filippov <71711753+alex-feel@users.noreply.github.com>

* Set list caching hints only when sent

The authz filters for tools, prompts, and resources lists added cacheScope and ttlMs to every filtered result.
A list from a backend on an MCP revision that predates these members therefore reached the client with ... (continued)

Coverage Stats

104 of 119 new or added lines in 2 files covered. (87.39%)

23 existing lines in 7 files now uncovered.

85598 of 120461 relevant lines covered (71.06%)

126.5 hits per line