MCP Perplexity Pro

Overview Schema Source Related Servers Discussions Admin

Perplexity Jobs

perplexity_jobs

Destructive

Manage research runs started by perplexity_research: list jobs, check status, retrieve results, or cancel. Poll periodically; does not wait for completion.

Instructions

Manage research runs started by perplexity_research. Actions: list (newest first), status (one fetch of a running job, with progress), result (the stored answer, sources and cost of a finished job) and cancel (stops a running job for good). Nothing here waits for a run to progress: call again later.

status, result and cancel fetch a job that is not finished at most once and then store what it shows; a finished job is served from the local database with no request. The first call that sees a run finished attempts to record its cost as spend, once: list with refresh true settles up to 10 running jobs, and a run nobody observes is never recorded. A run the provider no longer knows becomes lost after a second not-found at least 10 minutes after submit, and its spend cannot be recorded. Actions never create a project: list in an absent project is empty, the others fail with not_found. Details: call perplexity_help.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	list: jobs to return, 1 to 100 (default 20)
`action`	Yes	list, status, result or cancel
`job_id`	No	status, result, cancel: the job from perplexity_research
`project`	No	Project the job belongs to (default: default)
`refresh`	No	list: first observe the project's running jobs (up to 10, the least recently checked first) so finished runs are recorded as spend

Output Schema

TableJSON Schema

Name	Required	Description
`job`	No	The job's stored record
`jobs`	No	Jobs found (list only)
`usage`	No	result: tokens and cost of a finished run
`action`	Yes	The action that ran
`answer`	No	result: the stored answer text
`job_id`	No	The job the action concerns; null for list
`status`	No	The state the action reports (null for list): queued, in_progress, completed, failed, incomplete, cancelled, lost, cancelling (cancel only, never stored) or an unknown API status verbatim
`message`	No	What the result means or to do next
`project`	Yes	The project the action ran in
`sources`	No	result: pages the run touched
`progress`	No	Steps shown by the snapshot this call fetched
`warnings`	No	Things worth knowing about this result
`truncated`	No	Whether limit cut the list
`jobs_total`	No	All jobs in the project (list)
`not_refreshed`	No	list with refresh: running jobs not refreshed (beyond 10, or failed)

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?

With annotations already declaring destructive/openWorld, the description goes well beyond them: caching (finished jobs served locally with no request), one-shot observation, spend recording semantics, the 10-minute lost-job rule, and the fact that actions never create a project. This is unusually rich behavioral disclosure.

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-loaded with purpose and the action list, then the behavioral details. Dense but every paragraph carries non-redundant information; the second paragraph is somewhat long-winded but earns most of its length.

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?

For a multi-action, open-world tool with an output schema already covering return values, the description supplies the operational context an agent needs: caching, spend settlement, lost-job timing, and project failure modes. Nothing material 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 coverage is 100%, so the baseline is 3; the description adds genuine meaning on top, e.g. that refresh settles up to 10 running jobs, that job_id comes from perplexity_research, and the project default/not_found behavior. It stops short of 5 because the limit and project parameters are left largely to the schema.

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?

Opening line names the resource (research runs) and scopes it as management of runs started by perplexity_research, then enumerates the four actions with their return semantics. An agent can distinguish this from the sibling perplexity_research (which starts runs) without opening either schema.

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?

It clearly explains that each action is a single non-blocking fetch ('Nothing here waits for a run to progress: call again later') and what each action returns, which tells the agent when to pick list/status/result/cancel. It does not explicitly state when to prefer perplexity_search or perplexity_ask instead, so it stops short of full alternative routing.

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

Deploy Server