Closes #2018 - follow-up from #1915

Root Cause

Cache invalidation code existed and published messages to Redis pubsub channel mcpgw:cache:invalidate, but no subscriber existed to listen for these messages. In multi-worker deployments (e.g., 3 gunicorn workers behind nginx), when Worker A updated a tool's visibility and invalidated its local cache, Workers B and C continued serving stale cached data.

Solution

Added CacheInvalidationSubscriber class that:

• Subscribes to Redis pubsub channel mcpgw:cache:invalidate on application startup
• Listens for invalidation messages in a background asyncio task
• Clears local in-memory caches when messages are received
• Handles graceful shutdown and Redis unavailability

Message Formats Supported

Changes

• mcpgateway/cache/registry_cache.py: Added CacheInvalidationSubscriber class (~220 lines)
• mcpgateway/main.py: Start/stop subscriber in application lifespan
• tests/unit/mcpgateway/cache/test_cache_invalidation_subscriber.py: Added 14 regression tests
• scripts/test_mcp_token_scoping.py: Manual MCP client test for token scoping verification

Testing

Automated Tests (14 tests)

pytest tests/unit/mcpgateway/cache/test_cache_invalidation_subscriber.py -v

Tests cover:

• Registry cache invalidation (tools, prompts, resources)
• Tool lookup cache invalidation (by name, by gateway)
• Admin stats cache invalidation
• Graceful Redis unavailability handling
• Concurrent invalidation message processing
• Main regression test: Tool visibility update clears caches across workers

Manual Verification

python scripts/test_mcp_token_scoping.py

Results (all passing):

Deployment Notes

• Requires Redis for cross-worker cache synchronization
• Subscriber starts automatically on application boot
• Gracefully handles Redis unavailability (logs warning, continues without cross-worker sync)
• No configuration changes required

Checklist

• Linting passes (make flake8 pylint bandit)
• Type checking passes (make mypy pyright)
• Unit tests pass (14 new tests)
• Manual MCP client tests pass (8/8 RPC + 4/4 transport)
• No breaking changes to existing APIs