Summary

Two follow-ups to the MCP connection pool (#5760) flagged in review:

• Bound the pool's create-invalidation state. Replaces the per-server serverGenerations counter Map (grew one entry per distinct evicted server, forever) with a per-in-flight-create invalidation flag that lives in pending and is cleared in finally — naturally bounded, no unbounded growth, and no serverGenerations.clear() needed on dispose. evictServer now flags matching in-flight creates directly instead of bumping a counter they re-read.
  • Note: Greptile's suggested fix (serverGenerations.delete() after retirement) was unsafe — it reintroduced the evict-mid-create race the counter guarded (get() ?? 0 returns 0 after delete, colliding with a fresh create's captured 0). The flag design removes that bug class entirely.
• Document the DCR string-match. The MCP SDK throws a plain Error (no typed class/code) when an auth server lacks a registration_endpoint, so string-matching is the only available signal. Added a comment pinning it to @modelcontextprotocol/sdk v1.29.0 registerClient so a version bump that rephrases the message is easy to spot.

Type of Change

• Improvement (code quality / robustness; no behavior change)

Testing

• Full MCP suite green (426 tests, incl. the evict-mid-create one-shot and recreate-race guards)
• Adversarial concurrency audit of the redesign: confirmed the invalidation flag is at least as safe as the generation counter — pending.set runs synchronously before the create's post-await check, and both evictServer and the create's post-await section are await-free, so an eviction racing a create always sees the record
• tsc clean, boundary audit at baseline

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)