MCP Perplexity Pro

Overview Schema Source Related Servers Discussions Admin

Perplexity Research

perplexity_research

Launch a deep research run in the background on any question and get a job id at once, then track progress and fetch the result later.

Instructions

Start a deep research run in the background and return at once with a job id. The call never waits for the run: read progress and the result with perplexity_jobs (status, result, list, cancel).

Approximate cost per run by depth: medium $0.016 to $0.025 and 39 to about 90 seconds over four runs (query-dependent; up to about $0.05 estimated); high can cost up to about $0.4 to $0.9 and take minutes, and xhigh more (both unmeasured estimates, from the provider's positioning). There is no spending cap. A run is recorded as spend only once a perplexity_jobs call observes it finished, so call status or list with refresh true; a run nobody checks is never recorded.

Research runs are stored by the provider (store is true, because a background run that is not stored cannot be retrieved), so the query and result stay retrievable there. The query and the result are also kept in this server's local database. Details: call perplexity_help.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`depth`	No	medium (default), high or xhigh; deeper runs take longer and cost more. fast and low answers belong to perplexity_ask	medium
`query`	Yes	The research question (at most 20000 characters)
`project`	No	Project the job belongs to (default: default)
`instructions`	No	System-style instructions, at most 10000 characters

Output Schema

TableJSON Schema

Name	Required	Description
`depth`	Yes	The preset the run uses: medium, high or xhigh
`job_id`	Yes	Local job id: pass it to perplexity_jobs
`status`	Yes	The status the provider reported: usually queued or in_progress
`message`	Yes	What to do next
`project`	Yes	The project the job belongs to
`started_at`	Yes	When this server submitted the run (UTC)
`response_id`	Yes	The provider's response id for the run

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond annotations: per-depth cost and duration ranges, the absence of a spending cap, the unusual spend-accounting rule (a run is only recorded when a jobs call observes it finished, so refresh true is needed), and storage behavior on both the provider (store=true) and the local DB. These are behaviorally decisive facts an agent cannot infer from readOnlyHint=false/destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core async behavior and job-id return, then layers cost, spend-accounting, and storage notes. It is dense but every block carries load-bearing information for a tool that spends money; the cost prose is slightly parenthetical-heavy but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no prose, and the description correctly focuses on the async lifecycle, retrieval path, cost exposure, and storage implications. For a money-spending background job, nothing an agent needs to invoke it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters (baseline 3). The description earns extra credit by quantifying the cost/latency curve across medium/high/xhigh depths, which the schema only gestures at qualitatively ('deeper runs take longer and cost more').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Start a deep research run in the background and return at once with a job id.' It also differentiates itself from the sibling perplexity_ask by scope (deep/background job vs. fast/low answers), so an agent can tell them apart without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly routes the agent: retrieval goes through perplexity_jobs (status, result, list, cancel), quick answers belong to perplexity_ask, and further detail is in perplexity_help. It stops short of explicit when-not-to-use conditions versus peers like perplexity_search or perplexity_chat, so it's not a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server