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. You can use it in two ways.Connector only
Without the sandbox, GitHub works like any other connector: the model discovers tools from the GitHub catalog and calls them asmcp_call items.
The catalog covers repositories, files, commits, issues, and pull requests.
For example, get_file_contents reads the current contents of a file by owner, repo, and path, or lists a directory when path points to a folder.
Pass ref to read from a specific branch, tag, or commit; without it, the tool reads the default branch.
Use this mode for targeted lookups, such as reading a file, checking a commit, or listing pull requests, when you want each call recorded in the response.
To see the full tool set, send a request with only the connector and read the mcp_list_tools item in the output.
Connector with the sandbox
Pair the connector with Sandbox when the task needs thegit or gh CLI.
With both tools enabled, the agent can clone private repositories, read and search files, diff branches, change code, commit, 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 sandbox_results items instead of mcp_list_tools or mcp_call items, and failures appear as git or gh output.
Set allowed_tools or omit the sandbox to use GitHub as a regular connector with mcp_call items.
What to expect
The sandbox is a general-purpose execution environment, not a dedicated coding agent. It is a good fit for scoped repository tasks that complete in one run: read or review a set of files, explain a diff, make a focused change, or open a pull request. Repository-wide code review and multi-stage development work that depends on a persistent development environment, project-specific test setup, or long iteration loops are outside what a single sandbox run is designed for. For that kind of work, split it into scoped requests and give each one a clear, verifiable outcome.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.