Perplexity MCP Server

The server holds one credential, the operator's Perplexity API key, read from the environment and attached to every outbound call to the Perplexity API. It forwards no client tokens in the scored local mode and runs no subprocesses, so the key never reaches anything else. There is no narrower or per-tool credential and no authorization check of its own: every call, including deep research runs, bills the same long-lived account key. In the optional HTTP mode nothing authenticates inbound callers, so anyone who can reach the port spends the operator's key; the defaults keep that port on loopback.

The server's four tools only search the web or ask Perplexity's hosted agent; none writes files, sends messages or changes state. Every tool is marked read-only and non-destructive with an open-world flag, and those hints are accurate for local state. The one consequential effect is spending money on the operator's Perplexity account, which the annotations don't signal, and there is no dry-run, confirmation step or rate limit the host could use to slow repeated calls.

Each tool is a narrow wrapper around one fixed Perplexity endpoint; the model cannot choose the host, path or method, which come from code and operator environment. Arguments are typed with enums for filters and numeric bounds on result counts and page size, and message arrays are re-checked in code. Free-text fields (the question, domain filters, country) are passed through as data to Perplexity. The tool set is read-only and fixed, but all four tools are always exposed.

Nothing in the server interprets model text as code: there is no shell, eval, dynamic code loading or file access in the shipped source. All work is an HTTPS POST to the Perplexity API. Code execution is therefore structurally absent.

Everything the tools return is untrusted web content: search snippets and Perplexity's synthesized answers, merged into plain text with URLs inline. The structured output repeats the same string rather than separating source content from metadata, and nothing flags it as untrusted beyond the open-world annotation. The outbound side matters too: whatever the host model puts in a question goes to Perplexity's hosted agent, which searches and fetches web pages, so a hijacked host can use these tools as a channel to send data out. The server itself cannot change local state.

The server keeps no memory between calls, writes nothing to disk and loads no files from the working directory (no .env loading, no project config). Its settings come only from environment variables the host sets when launching it. The memory and configuration surface is structurally absent.

The server loads no plugins, MCP servers, models or packages at runtime; its tool set is fixed in code. How the host installs this package (the README uses unpinned npx -y) is the project's own supply chain and outside this criterion. Third-party extension loading is structurally absent.

The API key comes from the environment and is only placed in the Authorization header of requests to the configured Perplexity base URL; it is never put in tool output, logged, or passed to a subprocess. There is no telemetry and logging defaults to errors only. That safety is by construction rather than by a redaction layer: nothing masks secrets if they ever appear in an error, and upstream error bodies are relayed to the model verbatim. The key itself is a long-lived account key.

The server keeps no record of what it did. The tool handlers and the API client contain no logging at all, and the logger used elsewhere only covers HTTP-transport rejections and errors at its default level. After an incident there is no server-side trace of which queries were sent, by which caller, or what came back; only the host's logs and Perplexity's own account usage would show it.

Every API call is bounded by a deadline (5 minutes by default) that covers the whole streamed response, and if the host cancels or the deadline fires mid-stream the server asks Perplexity to cancel the run so it stops billing. Search size is bounded by schema. There are no rate or concurrency limits, no spend cap, and no ceiling on how high the operator can set the timeout; research cost is set by Perplexity's preset rather than by the server.