Perplexity connectors: a new MCP growth channel
Perplexity connectors let Perplexity search, read and act in other products on a user’s behalf, and the remote ones run on the Model Context Protocol. For a team that ships an MCP server, that makes Perplexity more than one more client: it is an answer engine whose users ask questions all day, and a connector puts your product inside those answers. This article explains how connectors and plugins work in Perplexity, why I see them as an MCP distribution channel, how the comparison with search engine optimization plays out, and how MCP Tower helps you test your server before you propose it and measure what it brings once it is live.
Key takeaways
- Perplexity calls itself an answer engine. Connectors extend those answers, and the Perplexity Computer agent, to tools such as Gmail, Slack, GitHub and Snowflake, and to any remote MCP server.
- Users find connectors on the Plugins page: a Discover tab grouped by category, search by name or by the tool it works with, and an item page with Try asking prompts.
- Getting into Discover starts with a connector proposal, not a self-serve upload. Today that is a Google Form of 68 questions, as Claude used before its developer portal. Perplexity’s team reviews it and decides whether to build and list the connector.
- Users on Pro, Max and Enterprise plans can already add your server as a custom remote connector, so you can start building usage before you are listed.
- I think prompt injection is why directory review is strict everywhere. Test OAuth and validate your tool descriptions in MCP Tower before you propose.
- The Perplexity help center documents no usage dashboard for connector owners, so your own MCP analytics are the only way to see what the channel brings.
What are Perplexity connectors?
Perplexity’s plugins article says connectors “give Computer access to an external tool, such as Gmail, Slack, Snowflake, or GitHub.” Each user connects with their own account, and each connector keeps its own tools, permissions and settings. A plugin is a bundle of connectors and skills around one job, and a plugin with a single connector takes that connector’s name and icon.
Under the hood, Perplexity MCP support is what makes connectors open to any product. Perplexity’s
guide to
local and remote MCPs
presents MCP servers as connectors that let users search, take actions and edit files from inside
Perplexity. The
custom remote connectors
article covers the details: the server is reached over https:// with Streamable HTTP or SSE, and
signs users in with OAuth 2.0, an API key or no authentication at all.
Connectors work in searches and in Perplexity’s agent. Perplexity’s MCP guide shows a connector switched on under Sources for a search. In Perplexity Computer, they let an agent act. Perplexity sums up the difference itself: “Perplexity answers your questions. Computer does your work.”
Why Perplexity connectors are an MCP distribution channel
Until a server is listed, a Perplexity user who wants it has to find its URL, open Add custom and paste it in. Developers will do that; most users will not, and a listing reaches them.
Perplexity’s guide to finding plugins describes what a listed connector gets:
- The Discover tab lists the items Perplexity publishes, grouped by category, so a user browsing a category sees you next to names they already know.
- Users can search by plugin name or by the tool it works with, and search covers every tab.
- Each connector has its own page with a description, its tools, Try asking prompts and a shareable link you can put in your own docs and emails.
- A user’s connection applies wherever that connector is used, including inside the plugins that bundle it.
On Enterprise plans, admins manage connectors under Organization settings, and an organization connector starts off until an admin turns it on. When one admin does, a whole team can reach your server through the tool they already use for research.
Computer adds a second reason to care. It turns a connected server from a data source into something an agent works with: it researches, writes documents and runs scheduled tasks, and it can call your tools along the way. I expect that to drive more calls per connected user than a chat that asks one question.
Perplexity is an answer engine, so think like an SEO
Perplexity’s help center describes it as “a tool designed to give you direct, detailed answers to your questions,” working by “searching the web, identifying trusted sources, and synthesizing information.” That is the search engine model with the list of links replaced by an answer.
For web pages, that shift created a new kind of search engine optimization: getting cited in an AI answer instead of ranking in ten blue links. Connectors take it a step further. A cited page sends a reader who might click. A connected MCP server is called directly, inside the answer, and the user gets your data or your action without leaving Perplexity.
The parallels are close enough to plan with:
| Web SEO | Perplexity connectors |
|---|---|
| Get indexed by the search engine | Get listed in Discover through a connector proposal |
| Rank for the queries people type | Show up when users search by name or by the tool you work with |
| Title and meta description | Connector description and tool descriptions |
| Target keywords | The Try asking prompts on your item page |
| A visit to your site | A tool call to your server |
| Analytics on which pages convert | Analytics on which tools get called, by whom, and what failed |
AI search distribution is the larger version of this idea. I think people are moving part of their searching from typing addresses to asking questions. When the engine that answers can also call your MCP server, the server becomes a page in that engine’s index, and the way you describe it decides whether you show up.
Perplexity does not document how Computer picks a connector for a task, and in the help-center pages I read there is no in-answer card that suggests connectors the user has not installed, as Claude does. My reading is that your tool names and descriptions are what the model reads when it chooses among connected tools, so they work the way a page title works for a search engine. Write them for the questions your users ask.
How Perplexity compares with ChatGPT and Claude
Each assistant has its own way into its catalog:
| Perplexity | Claude | ChatGPT | |
|---|---|---|---|
| How you get in | A connector proposal, reviewed by the Plugins marketplace team | A developer portal submission, then you select Publish | A ZIP upload and review |
| What decides | Customer value, feasibility, security and product priorities | Anthropic’s review criteria | OpenAI’s review requirements |
| How the model picks | Not documented | Suggested Connectors cards, plus your tool descriptions | Your tool metadata |
| Owner analytics | None documented | Beta dashboard, Claude traffic only | None |
Perplexity’s process reads more like a partnership than an app store. The proposal page says the form is for companies that want “to explore building a connector for Perplexity,” and that a proposal “does not guarantee that Perplexity will build, approve, or make a connector available.” The proposal itself is a Google Form, as Claude’s was in summer 2026 before Anthropic opened its developer portal, and it reads like an enterprise vendor questionnaire: security and incident contacts, support commitments with response targets, a versioning and deprecation policy with notice periods, and optional answer-quality evaluation materials. In my view a portal may follow, as one did for Claude. I cover the steps in how to submit a connector to Perplexity. For the other two, see the ChatGPT plugin directory and the Claude Marketplace. The same question for Gemini is covered in Gemini connected apps as a growth channel, for Meta in Muse connectors as a growth channel, for xAI in the Grok Bot Marketplace, and for the official MCP Registry.
Why review is strict, and how to be ready for it
In my view, prompt injection is the main reason every directory reviews connectors carefully. A tool description goes straight into the model’s context. A description that tells the model to call other tools or fetch instructions from somewhere else can steer every session where the connector is active, and Perplexity lists security requirements among the factors it weighs.
That makes your MCP server’s metadata worth checking before anyone at Perplexity reads it, and the proposal form says Perplexity “will discover the complete inventory from the MCP server,” so reviewers see every tool, not only the ones you list. Inspect, MCP Tower’s module for your server’s tools, validates your tools and their descriptions and gives you recommendations: missing titles or annotations, catch-all tools, and descriptions that read like instructions to the model. You can also change tool titles and descriptions yourself in Inspect through overrides, so a fix does not wait for a developer or a deploy. After you submit, MCP Tower rescans your server once a day and emails your Admins and Editors when a tool or argument is added, changed or removed, down to a changed description, so a change to the inventory Perplexity reviewed does not go unnoticed.
Then check sign-in. Nobody can evaluate a connector they cannot authorize, so broken authentication delays review on every platform. Perplexity’s troubleshooting article lists the usual suspects: a callback URL missing from your allowed redirect URIs, a server that needs custom headers, a token in the wrong format, no tools after sign-in. MCP Tower signs in to your server the way AI agents do, runs each step of the OAuth flow as a check and reports where the flow broke and what to change.
Measure what Perplexity brings you
An SEO specialist does not publish a page and hope. They watch which queries bring visitors and which pages break, then rewrite and measure again. A connector deserves the same loop, and on Perplexity you have to build it yourself: the help-center pages I read describe nothing for connector owners beyond the listing.
MCP Tower is the first product built for this. It sits in front of your remote MCP server as a proxy. You point a hostname you own at it with a DNS change, so the URL you publish can stay the same, and every request passes through to your server while MCP Tower records it, with no SDK or code change. That gives you:
- The AI agent behind each call, with a trust tier for how far that label can be trusted, so you can compare agents on one chart. Calls from clients that do not identify themselves are still counted. MCP Tower does not yet identify Perplexity as a named agent, but its calls are recorded and measured like any other.
- Which tools get called, how often, how fast and with which errors, filtered by agent, country and date.
- Users and sessions, widget interactions, and clicks on the links your tools return.
- Uptime checks that list your tools and record latency and errors, even when nobody is using the server.
- A way to test a new description: override it, then watch whether calls change, the way you would rewrite a title tag and watch clicks.
Set it up before you propose. Users who add your server, as a custom connector today or from a listing later, should get the URL you will keep, and with MCP Tower in front of it the first call is already measured. See pricing for plans.
Conclusion
Perplexity connectors bring MCP servers into an answer engine and an agent that does work, used by people who are already asking questions your product can answer. The way in is a proposal rather than an upload, and the review weighs security alongside customer value. You can start today: make your server work as a custom remote connector, test its sign-in and tool descriptions, propose it, and measure every call from the start.
Open MCP Tower to test your MCP server before you propose it to Perplexity, then see which AI agents use it from the first call.
