Logging is the point here: research and deep_research write into dated threads, and search_research, list_research_threads and read_research_thread turn that archive into something you consult before spending another query. Both query tools take an approved_plan argument and their descriptions put a pre-flight in front of the call — check the existing research, present a plan, then run it. That workflow lives in the tool description, which means it holds for a client that reads and follows tool text, and nowhere else.
A Perplexity search server with a memory: every query is logged into a research thread, and the tools for finding and re-reading those threads sit alongside the ones that spend a query.
- Perplexity queries with the knobs exposed — model, domain_filter, recency, context and return_related_questions
- Multi-model synthesis through deep_research, with the pattern chosen per question
- Saved threads listed with their dates and summaries, and any one of them read back in full by topic
- Keyword search across the thread files in ~/Documents/Perplexity Research/, so prior findings surface before a new query goes out
- list_models, which reports the available Perplexity models and when each applies
A Perplexity API key in PERPLEXITY_API_KEY, and a ~/Documents/Perplexity Research/ directory the server can write to — search_research and read_research_thread only reach what has already been logged there.
One command plus a key — npx -y @familyitguy/perplexity-mcp, then supply credentials