Skip to main content
Glama
cfdude

MCP Perplexity Pro

by cfdude
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Perplexity Chat

perplexity_chat
Destructive

Hold multi-turn web-search-grounded conversations: start or continue a chat, then list, read or delete stored chats.

Instructions

Hold a multi-turn conversation grounded in web search. A send continues the chat from its last stored response; the messages are kept in this server's local database. Actions: send (starts a chat when chat_id is omitted), list, read and delete.

Approximate cost per send by depth (observed ranges; the upper figures are estimates): fast $0.001 to $0.002, low $0.0005 to $0.004 (up to about $0.02 estimated), medium $0.016 to $0.025 as a research run (up to about $0.05 estimated; a synchronous medium send was not measured); high and xhigh are not available here (use perplexity_research). Every send is recorded as spend (see perplexity_usage). list, read and delete make no upstream call and cost nothing; they read or change only the local database and never create a project.

Chat text is stored in the local database. A send sets store to false, which only hides the response from retrieval at the provider; the provider's documentation says it still persists state, so this is not a retention control. If the provider cannot continue from the previous response, send again with replay true to resend the stored history.

Routing mode: standard. With no depth, tier or model perplexity/sonar answers with web search; tier is for custom mode only. A model is always used as given. The per-depth costs above apply to depth; the default model's cost differs (see perplexity_usage). Details: call perplexity_help.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNosend: light, standard or complex (custom mode); may change per turn
afterNosend: only results after this date (YYYY-MM-DD)
depthNosend: fast, low or medium; may change on every turn
limitNolist: chats to return, 1 to 100 (default 20), newest first. read: the last N messages, 1 to 200 (default 50)
modelNosend: an explicit model id instead of a depth (see perplexity_ask)
titleNosend, new chat only: its title, 1 to 120 characters (required)
actionYessend, list, read or delete
beforeNosend: only results before this date (YYYY-MM-DD)
replayNosend: resend the stored history instead of continuing from the previous response id (use it when the provider cannot continue)
searchNosend: false answers from the model alone (not with depth)
chat_idNosend: continue this chat; omit to start a new one
confirmNodelete: must be true; removing a chat cannot be undone
countryNosend: two-letter country code to localize the search
domainsNosend: at most 20 domains, all allowed or all denied with '-'
messageNosend: the message (at most 20000 characters, not blank)
projectNoProject the chat belongs to (default: default)
recencyNosend: hour, day, week, month or year
max_resultsNosend: search results to retrieve, 1 to 50
instructionsNosend: system-style instructions, at most 10000 chars
max_output_tokensNosend: cap on answer tokens, 1 to 64000

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
chatNoThat chat's record
chatsNoChats found (list only)
depthNosend: the preset used
modelNosend: the model that answered
usageNosend: tokens and cost
actionYesThe action that ran
answerNosend: the answer text
statusNosend: completed or incomplete
chat_idNoThe chat the action concerns (the new chat for a first send); null for list and for an incomplete or unsaved first send
projectYesThe project the action ran in
routingNosend: how the model was picked
sourcesNosend: pages the run found or fetched, by first use
messagesNoMessages in order (read only)
warningsNoThings worth knowing about this result
truncatedNoWhether limit cut the list or the messages
latency_msNosend: upstream call wall time
answer_jsonNoAlways null: send takes no json_schema
chats_totalNoAll chats in the project (list)
response_idNosend: the API's response id
continuationNosend only: new, chained (from the last response id) or replay
messages_totalNoAll messages in the chat (read)
messages_removedNoMessages removed with the chat (delete)
incomplete_reasonNosend: why it stopped

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare this as write-capable, open-world, and destructive, and the description adds substantial context beyond them: per-send cost ranges by depth, that list/read/delete cost nothing and stay local, that store=false is not a retention control, and that replay exists when provider continuation fails. This is rich behavioral disclosure for a complex mutation-capable tool.

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?

The purpose and actions are front-loaded, and most sentences carry routing or cost information needed for correct invocation. It is long and repeats the local-database storage point, but that repetition supports the retention caveat rather than pure filler, keeping it reasonably efficient.

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?

Given 20 parameters, an output schema, and annotations that already cover safety, the description supplies the missing decision context: action semantics, cost tiers, retention caveat, routing mode, and alternatives. Nothing essential for correct invocation appears absent.

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, but the description adds real meaning for depth (cost per tier), tier (custom mode only), model (always used as given; default cost differs), replay (when to resend history), and search (mutually exclusive with depth). Many other parameters are left to the schema, so it is above baseline but not exhaustive.

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?

The description opens with a specific verb and resource: 'Hold a multi-turn conversation grounded in web search.' It enumerates the four actions and clarifies that send starts a chat when chat_id is omitted, and it distinguishes scope from siblings such as perplexity_research and perplexity_ask.

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 gives explicit routing for high/xhigh (use perplexity_research) and points to perplexity_usage, perplexity_help, and perplexity_ask for model-related details. It does not, however, explicitly contrast this tool with perplexity_ask or perplexity_search for single-turn versus multi-turn use, so the guidance is clear but not fully exhaustive.

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

Deploy Server

Other Tools