Key the tool response cache by tool id and nested params - #1308

Summary

The tool response cache (responseMapping.cacheTtl) built its key from the tool name and a hash of the parameters. Two problems:

• Two connectors that expose a tool with the same name and get the same parameters shared one cache entry, so one connector's answer could be returned for the other. Multiple DATABASE connectors on one MCP server: tools/list silently exposes only the first connector's tools, and execute_query always routes to the first database #1296 shows how this happens with two DATABASE connectors on one server.
• The hash used JSON.stringify(params, sortedTopLevelKeys). A replacer array filters keys at every depth, so nested parameters were dropped: { filter: { status: 'open' } } and { filter: { status: 'closed' } } got the same key.

The key is now tool_cache:v3:<toolId>:<scope>:<hash>, with the parameters hashed with keys sorted at every depth (the existing hashContent helper). The prefix bump means v2 entries are never read again and simply expire.

Changes

• buildCacheKey takes the registered tool and uses its id instead of its name.
• Parameters are hashed with hashContent (recursive key sort, sha256).
• Tests: different tool ids give different keys, and nested parameters change the key.

Type

• Bug fix

Testing

• Added/updated unit tests

Commands, in packages/backend after npm ci and prisma generate:

• npx jest src/mcp-server/dynamic-mcp-tools: 2 suites, 105 tests passed.
• Same spec with the old dynamic-mcp-tools.ts: 3 failed (the two new tests and the key prefix check).
• npx tsc --noEmit -p tsconfig.json: clean.
• npx eslint on the two changed files: clean.

Behaviour in Cloud and self-hosted is the same. After the deploy, cached tools miss once and refill under the new keys.

Checklist

• My code follows the existing code style
• I have tested my changes locally
• This PR has a descriptive title

Related Issues

Relates to #1296