--- title: Action Gateway Overview (public) description: Action Gateway connects agents to external services through an MCP URL with the tools, accounts, and permissions you choose. product: Managed Agents url: https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/overview/ last_updated: "2026-10-22" --- > **For AI agents:** The documentation index is at [https://docs.digitalocean.com/llms.txt](https://docs.digitalocean.com/llms.txt). Markdown versions of pages use the same URL with `index.html.md` in place of the HTML page (for example, append `index.html.md` to the directory path instead of opening the HTML document). # Action Gateway Overview (public) Action Gateway connects applications and AI agents to tools through a managed MCP endpoint or SDK, with the accounts and permissions you choose. See [What You Can Build](https://docs.digitalocean.com/products/managed-agents/action-gateway/details/what-you-can-build/index.html.md) for standalone agent examples. Action Gateway lets your agent work with services such as GitHub and Linear through one Model Context Protocol (MCP) endpoint. Choose the operations the agent can perform, connect the accounts it needs, and add the endpoint URL to your coding agent or other MCP client. Action Gateway handles tool discovery, credentials, permissions, and execution without putting provider secrets in the model’s context. To connect your own coding agent and try a tool, start with the [Action Gateway Quickstart](https://docs.digitalocean.com/products/managed-agents/action-gateway/quickstart/index.html.md). ## Tool Providers and Tools A *tool provider* is a service that supplies tools, such as GitHub. A *tool* is one operation the agent can request, such as listing GitHub issues or adding a comment. Each tool has a name, a description, and an input schema that defines the arguments it accepts. Some tools, such as Exa web search, do not require your own provider credentials, though usage charges still apply. Tools that work with your GitHub repositories or Linear issues need access to those accounts. If you cannot find the provider you need, [add a custom provider](https://docs.digitalocean.com/products/managed-agents/action-gateway/how-to/add-custom-tool-provider/index.html.md) using its remote MCP server or one you host. Custom providers support servers with no authentication, an API key, or OAuth. ## Sessions, Actors, and Connections Suppose you want your coding agent to read GitHub issues and update Linear: 1. Create a [session](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/sessions/index.html.md) with the required tools. Allow reads and require approval for updates. The session saves these settings and gives you an MCP URL. It does not start an agent or store a conversation. 2. Under the same DigitalOcean user and team, connect your GitHub and Linear accounts by completing each service’s sign-in and consent flow. Each saved account authorization is a [connection](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/connections/index.html.md). Use the session’s **Actor ID** for both connections so the session can find them. For your own coding agent, you can keep the [Control Panel default](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/actors/index.html.md#default-actor-id). 3. Add the MCP URL to your client and sign in with the DigitalOcean account that created the session. When the agent calls a GitHub tool, Action Gateway checks the session’s permissions and uses the actor’s GitHub connection. A Linear call uses the Linear connection. You do not sign in again for each call. If an account later needs reauthorization, [restore its connection](https://docs.digitalocean.com/products/managed-agents/action-gateway/how-to/manage-connections/index.html.md#restore-provider-access) and keep the same MCP URL. For an application serving other users, assign each user a separate [actor ID](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/actors/index.html.md) and [have them connect their own accounts](https://docs.digitalocean.com/products/managed-agents/action-gateway/how-to/manage-connections/index.html.md#connect-an-application-users-account). Your backend owns the Action Gateway resources. Each user grants access to their GitHub or Linear account. A [Toolbelt](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/toolbelts/index.html.md) is optional: it groups tools so you can reuse the same selection across sessions. Two users can use the same issue-triage Toolbelt with different connected accounts. The Toolbelt defines the operations, not whose accounts they access. ## How Action Gateway Works Action Gateway’s catalog contains tens of thousands of tools. Loading every tool’s name, description, and input schema into a model would consume context and increase input-token costs before the agent begins a task. By default, Action Gateway exposes three meta tools through MCP instead: `action_search`, `action_invoke`, and `action_code`, subject to the session’s policy. When an agent needs a catalog tool, it describes the task to `action_search`. Search narrows the catalog to relevant tools the session can access and returns their definitions. The agent inspects the inputs, then uses `action_invoke` to run a tool or `action_code` to combine tool calls with Python. Pure computation can use `action_code` without a search. ## Meta Tools A session exposes three meta tools, subject to its permission policy: ### `action_search` `action_search` finds catalog tools for a task described in natural language. Results include the tool names and schemas the agent needs to prepare a call. Searching does not execute the discovered tools or grant permission to use them. See [Tool Search](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/tool-search/index.html.md). ### `action_invoke` `action_invoke` runs one or more named tools with their arguments. It can execute independent calls in parallel and returns an outcome for each call. Every call uses the session’s tool selection, policy, and actor connections. See [Invoke Tool](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/invoke-tool/index.html.md). ### `action_code` `action_code` runs Python in a temporary sandbox. For programmatic tool calling, Python can combine calls and filter intermediate results before returning what the model needs. This reduces model round trips and tool-result tokens without bypassing session permissions. See [Code Execution Tool](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/code-execution-tool/index.html.md). ## Session Controls for Model Context When you create a session, you can configure both the tool definitions available to the model and the amount of data returned by tools: - [Preload tools](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/preloading-tools/index.html.md) when you already know which operations the agent needs. Their definitions appear alongside the meta tools so the agent can use them without first searching. Each preloaded definition adds to model context, so preload a small set of frequently used tools and discover others as needed. - [Create an output view](https://docs.digitalocean.com/products/managed-agents/action-gateway/how-to/add-tool-output-view/index.html.md) and [select it for the session](https://docs.digitalocean.com/products/managed-agents/action-gateway/how-to/manage-sessions/index.html.md#override-tool-output-for-the-session) to replace a tool’s full result with selected fields. Smaller results reduce the tool-result data sent back to the model and can lower inference-token costs. Preloading affects tool definitions. Output views affect tool results. Neither changes which calls the session is allowed to make. Tool usage charges are separate from inference-token costs. ## Permission Policy Tool selection limits which catalog tools a session can reach. Permission rules then determine whether an eligible call runs (`allow`), requires approval (`ask`), or is blocked (`deny`). An allow rule cannot grant access to a tool outside the selection. You define and own this policy. Broad allow rules can permit writes, deletions, or other account changes without a gateway prompt. See [Tool Policies](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/tool-policies/index.html.md) for evaluation behavior and [Configure Approvals](https://docs.digitalocean.com/products/managed-agents/action-gateway/how-to/configure-server-side-approval/index.html.md) for client requirements. ## Execution and Deployment Execution uses each tool’s configured reliability policy. Eligible failures can receive bounded retries, with provider idempotency protection where supported. See [Reliable Execution](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/reliable-execution/index.html.md). With Harness Runtime, configure `do.actions` in the environment spec. The runtime creates the Action Gateway endpoint and connects the agent automatically. You do not need to copy a standalone MCP URL. See [Connect Action Gateway to Harness Runtime](https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/how-to/connect-action-gateway/index.html.md). For production agents with a defined workflow, see [Configure Action Gateway for Production Agents](https://docs.digitalocean.com/products/managed-agents/action-gateway/how-to/use-in-production/index.html.md) to restrict tools, preload known operations, call tools directly from Python, and reduce output data. See [What You Can Build with Action Gateway](https://docs.digitalocean.com/products/managed-agents/action-gateway/details/what-you-can-build/index.html.md) for standalone use cases and worked session configurations for web research and Jira triage.