MCP server for Perplexity API with intelligent model selection
The server provides 12 tools with varying quality. Naming is verb-forward and generally clear (ask_, research_, chat_, async_, check_, list_, read_, delete_, model_info_). Descriptions exist for all tools but are inconsistent in depth. Input schemas are present for all tools with proper JSON Schema structure, types, and parameter descriptions. However, there are critical gaps: (1) No output schemas are documented, LLMs cannot predict what these tools return, breaking the tool-chaining principle; (2) error handling guidance is absent, LLMs don't know how to recover from failures; (3) some descriptions are generic and lack WHEN/WHY context required by the pattern:tool-description baseline; (4) tool composition issues: ask_perplexity, research_perplexity, and chat_perplexity overlap significantly in responsibility without clear differentiation; (5) async_perplexity and check_async_perplexity create a manual polling interface instead of blocking or callback patterns; (6) several tools accept project_name with confusing auto-detection behavior not documented. Schemas average 6-8 properties per tool, within the baseline (p10=1, p90=8). Parameter descriptions exist but are terse. This is solidly a C-grade server, it has the bones of quality definitions but lacks the polish and completeness needed for confident production use.
Query Perplexity with automatic model selection based on complexity.
Create async jobs for complex queries that may take longer to process.
Maintain conversations with Perplexity stored in project directory.
Check status and retrieve results of async Perplexity jobs.
Safely delete a project and all its data.
List all async Perplexity jobs with status and timing information.
No output schemas documented for any tool. LLMs cannot predict return types, breaking tool-chaining (pattern:tool-chain). Agents cannot extract IDs for downstream calls.
Three query tools (ask_perplexity, research_perplexity, chat_perplexity) have overlapping responsibility without clear differentiation. Descriptions do not explain WHEN to use one vs. another, forcing LLMs to guess.
No error recovery guidance. Tools lack descriptions of failure modes, retryability, or next steps when calls fail. LLMs cannot self-correct.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
List all conversations stored in the current project.
List all existing projects with optional detailed statistics.
Get detailed information about available Perplexity models.
Retrieve complete conversation history from project storage.
Conduct comprehensive research using sonar-deep-research model.
Get storage statistics for the current project's Perplexity data.
Async polling pattern (async_perplexity + check_async_perplexity) creates manual state management. No documented expected latency, max polling retries, or timeout guidance. Agents may enter infinite loops.
Multiple tools reference 'project_name' with 'auto-detected if not provided' behavior but this detection logic is not documented. Unclear how auto-detection works or what happens if ambiguous.
Parameters like search_domain_filter describe format as 'array' but omit item constraints. What domains are valid? Are wildcards allowed? No enum or pattern provided.
List tools (list_async_jobs, list_projects_perplexity) support pagination but others (list_chats_perplexity, list_async_jobs implicit limit=20) lack pagination support. Inconsistent and risks context overflow for agents.
chat_perplexity requires 'title' for new chats but makes it optional in schema. Parameter description does not state this is required when chat_id is absent.