Perplexity’s Agent API Adds Managed Connectors for GitHub Code and PR Workflows

Perplexity’s Agent API now offers preview managed connectors for GitHub, Slack, Google Drive and Datadog. The feature lets an API Group administrator connect a service once, then lets agents use its tools by connector ID rather than sending a server URL and access token with every request.

GitHub is the consequential connector

GitHub is the differentiator because its connector can work with Perplexity’s Sandbox environment. An agent with both tools enabled can use the git and gh command-line interfaces to clone private repositories, inspect and modify code, commit changes, push a branch, and create or update a pull request.

That does not grant an agent new repository rights. Its access and permitted actions remain bounded by the permissions of the GitHub account connected to the API Group.

What changes for an Agent API request

• An API Group administrator connects a supported service in the API Portal and obtains its connector ID.
• The application adds that ID and a request-local server label to its tools configuration; the connection’s authentication is reused from the API Group.
• GitHub can supply credentials to Sandbox commands, while credentials supplied to a remote MCP server are not available inside Sandbox.

A managed alternative to remote MCP

Connectors and Model Context Protocol, or MCP, servers both give an agent external tools. Perplexity positions connectors for integrations already managed by an API Group; remote MCP servers remain the route for a developer’s own or third-party server, with its URL and request-specific authentication provided in each request.

Centralizing setup changes the control point as well as the request format. Only an API Group administrator can connect a supported service, so service authorization is administered at the group level before an agent run selects the connector by ID.

Tool schemas arrive only when needed

Connector tools use deferred discovery by default. Rather than loading every available tool schema into the model’s context, the model receives a connector namespace, searches its catalog, loads the schemas it needs, and then calls them.

The approach is designed for integrations that may expose many tools. Developers add the connector to the request, but must set a sufficiently high maximum step count for the agent to discover and use those tools.

A successful request can still lose its connection

Connector failures are returned inside the response rather than failing the overall request. Documented errors include AUTH_REQUIRED when authorization has lapsed or been revoked, INVALID_ARGUMENTS, POLICY_DENIED, service-unavailable conditions, internal connector errors and other tool errors.

That behavior makes observability part of the integration work. Perplexity advises developers to detect connector errors in their application harness and alert an operator to reconnect a stale authorization. A connector that is not connected can also return an empty tool list without an error, creating a second condition to monitor.

The connectors remain in preview, and Perplexity says supported services and behavior may change. For teams considering code-changing agents, the practical tradeoff is clear: centralized access can simplify workflows, but authorization health and tool availability need to be treated as runtime controls.