Skip to main content

Overview

Beyond the function tools you define yourself, you can give a model new capabilities by connecting it to a remote Model Context Protocol (MCP) server. The model calls that server’s tools to reach and control external services when it needs them to answer a prompt. The mcp tool connects a user-supplied remote MCP server to an Agent API request. Agent API discovers the server’s tools when the request starts and calls them like native tools during the run, so you don’t have to write a custom function tool for each one. The example below connects to the public DeepWiki MCP server, which needs no authentication, and asks the model to answer a question about a GitHub repository using the server’s tools.
For a fuller, runnable example that combines an MCP server with the model’s own web search, see the Model Picker cookbook recipe.

Authentication

Unlike the DeepWiki server above, most MCP servers require authentication. The most common scheme is an OAuth access token, which you pass in the authorization field of the mcp tool:
This example uses the GitHub MCP Server. Create a GitHub personal access token with access to the repositories you want the model to inspect, and export it as GITHUB_MCP_TOKEN.

Parameters

ParameterTypeRequiredDescription
typestringYesMust be "mcp".
server_labelstringYesUnique per request, matching ^[a-zA-Z0-9_-]{1,64}$. Namespaces the server’s tools.
server_urlstringYesHTTPS URL of the remote MCP server. Must be a Streamable HTTP MCP endpoint; the legacy SSE transport is not supported.
authorizationstringNoAn access token passed to the remote MCP server for authentication. Provide the raw token value. Never logged or echoed.
headersobjectNoExtra request headers (string values) sent to the MCP server.
allowed_toolsarrayNoAllowlist of tool names to expose to the model. Omit or leave empty to expose all discovered tools.

Response shape

When an mcp tool is used, the response output array can include two MCP-specific item types alongside the final message item:
  • mcp_list_tools — emitted once per server, listing the tools discovered when the request starts.
  • mcp_call — emitted for each tool the model invokes on the server.

mcp_list_tools

FieldTypeDescription
typestringAlways mcp_list_tools.
idstringIdentifier for this output item.
server_labelstringThe server_label you supplied for this server.
toolsarrayThe tools discovered on the server.
errorstring | nullnull when the server’s tools were listed successfully.
Each entry in tools has the following fields:
FieldTypeDescription
namestringTool name as exposed by the server.
descriptionstringTool description from the server.
input_schemaobjectThe server’s JSON Schema for the tool’s input, passed through unmodified.

mcp_call

FieldTypeDescription
typestringAlways mcp_call.
idstringIdentifier for this output item.
server_labelstringThe server_label of the server that ran the tool.
namestringName of the tool that was called.
argumentsstringJSON-encoded arguments the model passed.
outputstringTool output text. Empty when the call fails.
errorstring | nullnull on success. When the call fails, holds the failure string, which is also returned to the model in-band.
Example response output array:

Error handling

CaseWhat you see
Discovery failureThe request fails with external_connector_error (HTTP 424 Failed Dependency) — the server’s tools could not be listed, so the run never starts and no output array is returned. The error body’s message names the server, for example MCP server "github" could not be initialized.
Tool-call failureThe matching mcp_call item has its output empty and an error string set. The failure is also returned to the model in-band, so it can recover or explain in its final answer.
A discovery failure happens when a server cannot be reached or returns an unusable response as its tools are listed at the start of the run. Because discovery runs before the model, the whole request fails with external_connector_error and returns no output array. Tool-call failures during the run do not fail the request. The error is returned to the model in-band on the mcp_call item (as above), so the model can recover or explain it in its final answer.

Risks and safety

The mcp tool lets you connect models to external services — a powerful capability that carries risk. Remote MCP servers are third-party services that have not been verified by Perplexity. They can let a model read, send, and receive data, and take actions in the connected service, and each server is subject to its own terms and conditions. Connect only servers you trust.
Agent API does not support MCP approvals yet. Every MCP tool call auto-runs, so only connect MCP servers and expose tools that you trust to run without an approval step.
Use allowed_tools to limit which server tools the model can call. For servers with write or admin actions, prefer read-only server modes, read-only tokens, or a small allowlist of read-only tools.

Limitations

The mcp tool is backward-compatible with OpenAI’s Responses MCP API. The following OpenAI MCP features are temporarily not supported:
Feature or fieldBehavior
require_approvalIgnored. Every MCP tool call auto-runs.
mcp_approval_request / mcp_approval_responseNot emitted or accepted. Approval pause/continue flows are not available yet.
connector_id and hosted connector catalogsIgnored. Only bring-your-own server_url is honored.
Connector OAuth flowsNot supported. Pass credentials to your own remote server with authorization.
defer_loadingIgnored. Tools are discovered when the request starts.
MCP resources, prompts, and samplingNot supported yet; tools are the only supported MCP capability.
approval_request_id and status on MCP output itemsNot present in the MCP output item shapes.

Pricing

MCP tool calls are free — Agent API does not charge a per-invocation fee for calling a remote MCP server. Model token usage is still billed separately according to Agent API token pricing (see Models for per-model rates), and you operate the remote MCP server, so any cost it incurs is outside Agent API billing.