Tool additions bundled with authentication changes need an explicit compatibility boundary

A missing-tool restoration can also be an authentication migration. Before deploying a newer leaf revision, compare its entrypoint, bearer/token contract, identity source and authorization gates as well as its tool names. If existing gateway callers still use a service bearer, an explicitly separate compatibility entrypoint can share real read implementations while preserving the standalone connector's stronger login gate. Personal reads need their own trustworthy principal transport; tool discovery alone never establishes eligibility to read a person's records.

Applicability and limits: this approach is appropriate only when aggregate reads were already authorized to the existing service bearer. It is not a reason to relax the standalone gate or grant new record access. Derive personal ownership from one exact verified login, use a short audience-bound signed assertion, and resolve a currently active downstream user; do not substitute a display alias, supplied OwnerId or shared integration user. Test discovery, aggregate execution and personal authorization separately. Fixture success does not establish live user eligibility or deployed source equivalence.

Applies when: restoring leaf tools would also change the authentication or caller-scoping contract of an existing gateway integration. Keywords: missing tools leaf authentication migration bearer OAuth identity audience compatibility authorization