This server presents a single tool 'search' with significant quality gaps. The tool name lacks a verb prefix and the schema is partially inferred from the source code rather than explicitly registered via MCP protocol. The description exists but is minimal (73 chars). Parameter descriptions are present but generic. No output schema is documented in the code. The implementation appears to be a mock/stub client with hardcoded responses rather than a production-ready MCP server. No evidence of MCP server registration, capability negotiation, or proper transport implementation.
Tools (1)
searchread onlysource verified35/100
Performs a Perplexity Pro search with model council consensus analysis
Tool name 'search' lacks action verb prefix. Follows pattern 'search' which is acceptable, but no context given that this is a Perplexity Pro-specific search, name should be 'search_perplexity' or 'perplexity_pro_search' to disambiguate from generic search tools.
Tool definition not explicitly registered in source code via MCP protocol. The tool exists only as a Python method in a class; no MCP server framework, no tool registration with capabilities, no transport visible. This violates the foundational requirement that tools be declared via MCP's CallTool mechanism.
Output schema is not documented. The code returns a dict with keys 'answer', 'citations', 'model_council' but no formal schema declaration is visible. LLMs cannot plan downstream operations without knowing the response structure.
search
Recommendations
Rename tool from 'search' to 'search_perplexity_pro' or 'perplexity_pro_search' to clearly distinguish it from generic search tools and avoid name collisions in multi-tool environments.
Implement a proper MCP server using the official Python MCP SDK. Register the tool via the tools capability with explicit CallTool handler. Add transport support (HTTP/SSE or Streamable HTTP).
Implement actual Perplexity Pro API integration instead of mock responses. Verify API credentials via environment variables (never as parameters). Return real citations and model opinions from the actual API.
Add input validation: check query length (e.g. 1-1000 chars), validate model names against a whitelist of supported models, return actionable errors for invalid inputs. Example: 'Invalid model: got "gpt-5.2", supported models: [real-list]'.
Update parameter 'mode' description to enumerate valid modes and remove example from description. Use JSON Schema enum constraint instead: { 'mode': { 'type': 'string', 'enum': ['pro', 'deep_research', ...], 'description': '...' } }.
Fix parameter 'models' schema: remove conflicting null default. Set proper JSON Schema default matching the description: { 'models': { 'type': 'array', 'items': { 'type': 'string' }, 'default': ['gpt-5.2', 'claude-4.6', 'gemini-3.1-pro'] } }, OR better yet, use realistic current model names.
Parameter 'mode' has a default value ('pro') but the description says 'default: pro' in free text rather than as a formal JSON Schema default. Parameter 'models' has a confusing null default in the schema which contradicts the description stating 'default: [gpt-5.2, claude-4.6, gemini-3.1-pro]'.
Implementation is a mock stub returning hardcoded responses. There is no actual Perplexity API integration, MOCK_SOURCES and MODEL_OPINIONS are static. The tool cannot perform real searches and will always return fabricated data with mock citations dated 2026.
No error handling. The search() method has no try/catch, no input validation, no error guidance for invalid queries or models. If passed a malformed input or external service fails, there is no recovery path for the LLM.
Parameter descriptions are generic and lack context. 'The search query' does not explain what constitutes a valid query, expected length, or what topics are supported. 'List of AI models to include in consensus council' does not document which models are supported or what happens if an invalid model is passed.
Model names in the parameter default ('gpt-5.2', 'claude-4.6', 'gemini-3.1-pro') appear to be fictional or outdated as of 2026 spec baseline. These are not real model identifiers and will confuse users and LLMs about what models are actually available.
search
Expand tool description from 73 chars to 150-200 chars to explain WHEN to use this tool (e.g. 'Use for multi-model consensus research requiring high-confidence synthesis of recent sources') and WHAT it returns.
Add error handling: wrap API calls in try/catch, return structured error with recovery hints. Example: { 'error': 'Perplexity API rate limit exceeded. Please try again in 60 seconds.' }.
Document the citation object structure: each citation should have 'title', 'url', 'date', and optionally 'snippet'. Ensure citations are real URLs and verifiable dates, not mocks.
Add pagination support if the tool can return many citations: accept 'limit' (default 3) and 'offset' parameters, return 'total_citations' count in response.
Declare tool risk as READ_ONLY (already marked) but also verify no state mutation occurs. Document idempotency: repeated calls with same query return the same result.