Skip to main content
Glama
cfdude

MCP Perplexity Pro

by cfdude

Perplexity Ask

perplexity_ask

Ask one web-grounded question and get an answer with sources in a synchronous call. Use depth, model, and search filters for one-off queries, not background research.

Instructions

Ask one web-grounded question and get the answer with its sources. Synchronous and stateless; it never waits for a background run (use perplexity_research for those).

Approximate cost per call 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 call was not measured). high and xhigh can cost dollars and take minutes (unmeasured estimates), so they exist only behind perplexity_research. Giving a search filter (domains, recency, after, before, country, max_results) makes the run use the web search tool alone, so a filtered medium run loses the preset's page fetching.

The request sets store to false, which only hides the response from retrieval; the provider's documentation says it still persists state, so this is not a retention control. Sources are what the run touched, not a citation of each claim. Every call that reaches the API is recorded as spend (see perplexity_usage).

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
tierNolight, standard or complex: custom routing mode only. Cannot be combined with depth or model
afterNoOnly results published after this date (YYYY-MM-DD)
depthNofast, low or medium; selects a search preset. high and xhigh are refused: use perplexity_research. Cannot be combined with tier or model
modelNoAn explicit model id, e.g. openai/gpt-6-luna, instead of a depth. It searches with the web search tool and 3 steps unless search is false
queryYesThe question (at most 20000 characters)
beforeNoOnly results published before this date (YYYY-MM-DD)
searchNofalse answers from the model alone (not with depth: a depth always searches). true is accepted and changes nothing
countryNoTwo-letter country code to localize the search, e.g. US
domainsNoAt most 20 domains to search: all allowed (python.org) or all denied with a '-' prefix (-reddit.com); not mixed
projectNoProject to record the call under (default: default)
recencyNohour, day, week, month or year
json_schemaNoA JSON Schema (root type object) for a structured answer
max_resultsNoSearch results to retrieve, 1 to 50
instructionsNoSystem-style instructions, at most 10000 characters
max_output_tokensNoCap on answer tokens, 1 to 64000

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthYesThe preset used; null with an explicit model
modelNoThe model that answered
usageYesTokens and cost of this call
answerYesThe answer text; markers such as [1] are unchanged
statusYescompleted or incomplete
projectYesThe project the call was recorded under
routingNoHow the model was picked
sourcesYesPages the run found or fetched (not necessarily cited), by first use
warningsYesThings worth knowing about this result
latency_msYesMeasured wall time of the upstream call
answer_jsonNoThe parsed answer when json_schema was given and it parsed, else null
response_idNoThe API's response id
incomplete_reasonNoWhy an incomplete run stopped, e.g. max_output_tokens

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations give safety profile, and the description adds far more: synchrony/statelessness, per-depth cost ranges, the caveat that store=false 'is not a retention control,' that every API-reaching call is recorded as spend, and that sources are what was touched rather than citations. This is unusually rich behavioral context beyond the annotations.

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 routing, and most sentences carry routing or cost information an agent needs. The cost paragraph is dense and hedged with nested parenthetical estimates, making it slightly sprawling rather than wasteful.

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 not be described, and the description still covers routing, cost, filtering behavior, and retention caveats. Nothing an agent needs to invoke this 15-parameter tool correctly 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 earns above that by explaining cross-parameter behavior the schema does not, e.g. that supplying a search filter forces the run to use the web search tool alone and drops preset page fetching, and that a model 'is always used as given.' It adds real semantic value over the field descriptions.

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 ('Ask one web-grounded question and get the answer with its sources') and immediately distinguishes itself from the sibling that does the other thing ('use perplexity_research for those'). An agent can tell this apart from perplexity_search/research without opening any schema.

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

Usage Guidelines5/5

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

Explicitly scopes usage: synchronous single-question calls here, background runs go to perplexity_research, and it states that high/xhigh depths are 'only behind perplexity_research.' It also documents routing modes and the search-filter tradeoff, leaving little to inference.

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