Preview: Connectors are in preview. Supported services and behavior may change.
Overview
Connectors are managed integrations for services that your API Group has connected in the API Portal. They use the same tool-calling model as MCP, but you do not provide a server URL or an access token in every request. Instead, select a connected integration by its connector ID. Some connectors also make their credentials available to Sandbox commands. This lets an agent combine service access with code changes and other local work in one run.Available connectors
The current set of connectors includes:Don’t see the connector you need? Email api@perplexity.ai to request it. In the meantime, you can connect any remote MCP server to an Agent API request.
Add a connector
- Open Connectors in the API Portal.
- Only an API Group administrator can connect a supported service to the API Group.
- Copy the connector ID from the service card.
- Add a
connectorentry to the Agent API request.
Connector tools use deferred discovery by default.
Set
max_steps high enough to discover and use them.connector_slack with the connector ID that you copied from the API Portal.
output array lists the connector’s tools, the model’s search of that catalog, each tool call, and the final message.
Connectors are deferred by default, so the model searches the catalog (tool_search_output) before it calls a tool.
Response output (truncated)
Response output (truncated)
Deferred tool discovery
A connector can expose many tools, and loading every schema up front would waste tokens. Connector tools are discovered lazily instead: the model receives the connector namespace, searches it, loads only the schemas it needs, and calls them — all automatically. You only add the connector totools.
The mcp_list_tools item still records the full catalog; deferred discovery controls what enters the model’s context, not what the response reports.
Connector parameters
Use connectors in the sandbox
Some connectors make their credentials available to sandbox commands. GitHub is a key example.GitHub connector
The GitHub connector lets the model use the GitHub tools that belong to your connected GitHub account. Pair it with Sandbox when the task needs thegit or gh CLI.
With both tools enabled, the agent can clone private repositories, inspect and change code, commit changes, push a branch, and create or update a pull request.
It uses the git and gh CLIs in the sandbox with the GitHub credentials from the connector.
The agent can access only repositories and perform only actions that your connected GitHub account permits.
With the sandbox enabled and no
allowed_tools, GitHub runs through the CLIs: the response has no mcp_list_tools or mcp_call items, and failures appear as git or gh output. Set allowed_tools or omit the sandbox to use it as a regular connector with mcp_call items.Connectors and MCP
Both connectors and MCP servers let the Agent API call external tools. Use a connector when the integration is already managed for your API Group. Use MCP when you need to connect your own remote server and provide its URL and authentication in the request.Error handling
A connector tool call can fail as anmcp_call item with an error field.
This does not fail the request: the run continues and the error is passed to the model in-band, so the model still answers — it just cannot use that connector.
The main case to handle is AUTH_REQUIRED: the connector’s authorization went stale or an administrator revoked it.
Your requests keep working — the connector is just unavailable to the model until it is reconnected, which you can do later.
For example:
error value:
The
error field is a free-form string, so treat any other value as a tool failure.
A connector that is not connected lists no tools ("tools": []) and produces no error, so also watch for an empty tool list.
Next steps
MCP
Connect a remote MCP server that you manage.
Sandbox
Run code and use the GitHub connector with
git and gh.