先区分两种令牌：旧刷新令牌不能直接调用工具，能调用工具的是访问令牌。RFC 6749 将刷新令牌定义为获取访问令牌的凭证；RFC 9700 要求公共客户端的刷新令牌使用发送方约束，或采用 Section 4.14 的刷新令牌轮换。轮换约束的是刷新环节。按 RFC 6749 的描述，访问令牌在过期前会被重复用于资源请求，过期或无效后资源服务器才返回 invalid token error。因此，轮换后工具仍可调用，通常不是旧刷新令牌在起作用，而是请求携带的旧访问令牌尚未过期，且资源服务器接受了它。
刷新令牌只走授权服务器
在 MCP 远程部署里，客户端、授权服务器、MCP 资源服务器分工不同：客户端先拿访问令牌，再用访问令牌调用工具；访问令牌过期或无效时，才用刷新令牌到授权服务器换新。RFC 6749 的刷新流程是授权服务器验证刷新令牌，签发新访问令牌，并可选签发新刷新令牌。
轮换要求落在这个换取动作上：公共客户端应让刷新令牌可轮换或受发送方约束。发送方约束是把刷新令牌与特定客户端绑定，轮换则是在刷新时换发新刷新令牌，降低旧刷新令牌被重放的价值。资料只支持到这里，没有给出轮换后旧刷新令牌在所有实现中立即失效的统一行为。
旧访问令牌为何还能通过
RFC 6749 描述客户端在访问令牌有效时重复用它请求资源，直到过期；知道过期后才跳到刷新步骤。资源服务器只在访问令牌无效时返回 invalid token error。轮换刷新令牌不会改变一个已经签发、尚未过期的访问令牌的过期时间；资料也没有把刷新令牌轮换与访问令牌撤销描述为同一个事件。
工程上通常有两种校验路径：资源服务器本地验证令牌，或每次向授权服务器查询状态。如果访问令牌是自包含的，资源服务器可能只验证签名和 exp；这种情况下，刷新端点发生轮换不会出现在它的判断里，旧访问令牌在过期前仍可能通过。若资源服务器每次都查询授权服务器状态，才可能更早发现撤销。
| 凭证 | 发送给谁 | 轮换后的影响 |
|---|---|---|
| 刷新令牌 | 授权服务器 | 轮换要求针对它；旧刷新令牌能否继续换新令牌取决于授权服务器实现 |
| 访问令牌 | MCP 资源服务器 | 在过期前仍可能通过；是否提前失效取决于资源服务器校验方式 |
MCP 资源服务器该查什么
一篇介绍 MCP 与 OAuth 2.1 的博客转述，MCP 资源服务器在处理请求前必须验证访问令牌，并验证受众，确保令牌专门为该服务器颁发；同一文章还建议认证服务器对公共客户端轮换刷新令牌、颁发短期访问令牌。这些是二手转述，不是 MCP 官方原文。
落到排查上：先看工具请求的 Authorization 头里是不是访问令牌；再看资源服务器是否校验过期时间、签名（若为自包含令牌）和受众；最后看访问令牌寿命是否足够短，以及资源服务器是否具备撤销或状态查询能力。若只做本地验签和 exp 检查，刷新令牌轮换不会缩短旧访问令牌的可用窗口。
RFC 9700 的 Section 4.14 正文未在本次资料中展开，不能据此推断某个授权服务器在轮换后会不会立即拒绝旧刷新令牌；资料也没有提供任何 MCP 厂商的实现或日志。能确定的判断是：工具调用成功时，先检查未过期的访问令牌，不要把旧刷新令牌当成工具调用凭证。