perplexity_searchSearch Perplexity AI to get answer text for a query, with optional session ID for follow-up questions. Combine related subquestions into one call.
对齐官方 Perplexity MCP：搜索（当前实现返回回答文本，结构化字段尽量附带）。请避免频繁调用；尽量将多个子问题合并到一次 query / 一次 perplexity_search 中查清楚。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| backend_uuid | No | 续问用的会话标识。通常应直接使用上一轮工具返回的 structuredContent.backend_uuid；若不提供则视为新对话。 |
Changes observed during successful MCP inspections.
v0.1.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely new behavior: it discloses that the current implementation returns answer text with structured fields 'attached where possible', and warns about call frequency. The rate-limit warning and return-format caveat go beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and the batching advice is actionable, but the first clause ('align with official Perplexity MCP') is meta-noise that does not help an agent call the tool. That padding dilutes an otherwise compact definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema the description does helpfully sketch the return shape (answer text + optional structured fields), which compensates somewhat. However, with three sibling tools and no differentiation, and query undocumented in the schema, the definition is only minimally complete for an agent choosing among the perplexity_* family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: backend_uuid is well documented in the schema (session continuation via structuredContent.backend_uuid), but query has no schema description. The description only implicitly covers query by advising sub-questions be merged into 'one query', which is mild but useful guidance rather than full parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the verb/resource (web search) and notes it returns answer text, but it opens with meta-commentary about aligning with the official Perplexity MCP rather than stating scope. It never distinguishes itself from the three siblings (perplexity_ask, perplexity_research, perplexity_reason), which leaves the agent guessing what makes 'search' the right pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives efficiency advice ('avoid frequent calls', batch sub-questions into one query) but no when-to-use guidance relative to the sibling tools that exist. No exclusions or alternatives are named, so the agent has no basis for choosing this over perplexity_ask or perplexity_research.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.