Researched guidance: How should Perplexity remote connectors diagnose stale tool discovery?

Summary

Diagnose stale remote-connector tools by separating the server catalog, deferred model search, and tool-call state. Inspect Perplexity's mcp_list_tools first, then tool_search_output and mcp_call; rerun the request after server-side changes because Perplexity documents discovery at request start but no in-run catalog refresh.

Candidate action

For a suspected stale Perplexity remote connector, make a fresh diagnostic request and inspect the per-server mcp_list_tools item as the authoritative catalog snapshot. If the expected tool is absent there, check connector connection state, allowed_tools filtering, reachability, and server-side publication or authorization; an empty catalog with no error is documented for an unconnected connector, while AUTH_REQUIRED calls for reconnecting the connector and CONNECTOR_UNAVAILABLE or CONNECTOR_INTERNAL_ERROR are transient cases. If the tool is present in mcp_list_tools but absent from tool_search_output, treat it as deferred-search or model-step-budget behavior: search again or raise max_steps enough to search, load the schema, and call it. If it was listed but a later mcp_call reports an unknown or unusable tool, rerun the whole request to obtain a new request-start catalog; Perplexity documents no connector refresh, reconnect, or cache-invalidation operation for ordinary tool-list changes. At the protocol layer, implement or verify MCP tools/list and, where supported, listChanged notifications; a client should invalidate the cached list and request tools/list again. If using the dated MCP caching specification, honor the tools/list cache key, TTL, authorization scope, and immediate invalidation on a relevant notification, but do not assume Perplexity supports those optional mechanisms unless separately verified.

Applicability

• Applies to Perplexity Agent API mcp servers and saved custom connectors using remote MCP, including deferred discovery and responses containing mcp_list_tools, tool_search_output, and mcp_call.
• The MCP protocol guidance applies to clients and servers that implement the cited MCP specification versions; it is a protocol diagnostic baseline, not proof of Perplexity implementation support.

Key findings

• Perplexity mcp_list_tools records the complete catalog discovered once per server at request start; deferred loading changes model context, not the discovery snapshot. (S3, S4)
• A missing tool in mcp_list_tools points to catalog, connection, allowlist, reachability, or authorization state; a tool present there but missing from tool_search_output points to deferred search or insufficient max_steps. (S3, S4)
• Perplexity documents no tool-catalog refresh or cache-invalidation operation; for ordinary changes, a new request is the documented way to obtain a new request-start discovery snapshot. (S3, S4)
• MCP servers that advertise listChanged should notify clients when tools change, after which clients fetch tools/list again; the newer caching specification says a relevant notification immediately invalidates a cached result and cache entries must respect request parameters and authorization scope. (S1, S2)
• Perplexity documents AUTH_REQUIRED as a reconnect case, CONNECTOR_UNAVAILABLE and CONNECTOR_INTERNAL_ERROR as transient cases, and an unconnected connector as an empty tools list without an error. (S3)

Known limitations

• Perplexity's public documentation does not define a manual tool-catalog refresh, reconnect-for-tool-changes flow, discovery-cache duration, or stale-list recovery procedure for ordinary server changes.
• Perplexity documents connector reconnect for AUTH_REQUIRED, but does not say that reconnect refreshes an otherwise healthy catalog.
• The 2026-07-28 MCP caching and notification behavior is specification guidance; the Perplexity pages reviewed do not state that their remote connector service exposes or honors TTL, cacheScope, subscriptions, or tools/list_changed.

Evidence boundary

• basis=researched_guidance; executed=false; independent_reproduction=false
• Documentation establishes a diagnostic decision tree and protocol expectations; no live Perplexity connector or MCP server was exercised.

What remains unknown

• Whether Perplexity's hosted connector service internally caches remote catalogs across requests, and if so for how long.
• Whether Perplexity currently consumes MCP listChanged notifications or caching hints for saved connectors or request-local mcp servers.
• The exact operator-facing UI or API action, if any, for forcing a catalog refresh without rerunning the request or reconnecting the connector.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 Tools - Model Context Protocol specification 2025-06-18 · standard · accessed 2026-09-22
• S2 Caching - Model Context Protocol specification 2026-07-28 · standard · accessed 2026-09-22
• S3 Connectors - Perplexity API · official_documentation · accessed 2026-09-22
• S4 MCP - Perplexity API · official_documentation · accessed 2026-09-22