MCP Perplexity Pro

Overview Schema Source Related Servers Discussions Admin

Perplexity Projects

perplexity_projects

Destructive

List all Perplexity projects or permanently delete a selected project and its stored records; spend history stays reportable under the project name. Deletion requires confirmation.

Instructions

List the server's projects, or permanently delete one with its stored records.

Spend history (usage events) is not deleted: it is kept, detached from the project, and stays reportable by the project's name. Neither action creates a project.

Input Schema

TableJSON Schema

Name	Required	Description
`action`	Yes	list: show all projects; delete: remove one project and its stored records (spend history is kept)
`confirm`	No	Must be true for delete; deletion cannot be undone
`project`	No	Project name (delete only)

Output Schema

TableJSON Schema

Name	Required	Description
`action`	Yes	The action that ran
`project`	No	The deleted project's name (delete only)
`projects`	No	All projects (list only; null for delete)
`rows_removed`	No	Rows removed from tables that reference the project directly; deeper rows go by cascade and are not counted (delete only)
`running_jobs`	No	Research jobs of the project that had not finished when it was deleted (delete only): their spend is never recorded and the provider keeps billing them until they end
`rows_retained`	No	Retained records (spend history) detached from the project and kept (delete only; null for list)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Oct 15, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true, but the description adds the crucial detail the annotations cannot: deletion is permanent, stored records go with it, and spend history survives detached and still reportable by name. That is exactly the consequence detail an agent needs before confirming a destructive call.

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

Conciseness5/5

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

Three short sentences, front-loaded with the two actions, followed by the retention consequence and the scope negation. Every clause carries information; nothing is padding.

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 two-mode tool with a full schema and an output schema handling return values, the description covers everything an agent needs: the actions, the irreversibility, the data-retention behavior, and the boundary against creation.

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

Parameters3/5

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

Schema description coverage is 100%, so action, confirm, and project are all already documented in the schema, including the 'spend history is kept' note. The description restates rather than extends that, so baseline 3 applies.

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?

Names the specific verbs (list, delete) and resource (projects), and explicitly bounds the tool by stating 'Neither action creates a project.' An agent can tell immediately this is the project-management surface, distinct from the query/research siblings.

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?

The two modes are clearly delineated and the negative constraint (no creation) tells the agent when NOT to reach for this tool. It stops short of naming an alternative for project creation, so routing for that case is left implicit.

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

Deploy Server