For AI agents: The documentation index is at 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 is a managed tool service in Managed Agents. It gives AI agents access to tools, APIs, and SaaS systems through a single MCP endpoint. Action Gateway handles tool discovery, credentials, permissions, and execution so you do not wire integrations into each agent.

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.

This discovery flow brings relevant tool definitions into context as needed instead of loading the full catalog. It leaves more context for the task and can reduce model input tokens and inference costs.

Meta Tools

Meta tools let an agent find and use catalog tools without loading every tool’s definition into its context. An Action Gateway 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.

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.

action_code

action_code runs Python in a temporary sandbox for computation, data processing, or workflows that combine tool calls. Code can call catalog tools through a provided helper, with the same session permissions. This enables programmatic tool calling: Python processes intermediate results and returns only the output the model needs, reducing model round trips and unnecessary tool-result tokens. It can lower latency and inference costs compared with having the model read and coordinate every tool response. Each execution starts with a fresh sandbox. See Code Execution Tool.

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 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.
• Choose output views to replace a tool’s full result with selected fields for that session. 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.

Tool Providers and Tools

A tool is an individual operation an agent can request, such as listing GitHub issues or searching the web. Each tool has a name, a description, and an input schema that defines the arguments it accepts. Calling the tool runs that operation and returns its result.

A tool provider supplies a group of related tools. For example, the GitHub provider supplies tools for working with GitHub resources.

If you cannot find the provider you need in the Action Gateway catalog, add a custom provider using its remote MCP server or one you host. Custom providers support servers with no authentication, an API key, or an OAuth connection.

A provider defines the available integration; a connection authorizes access to a particular account for that provider. For example, two GitHub connections can authorize different GitHub accounts without creating a second tool provider. Actors determine which connection a session uses.

Sessions, Actors, and Connections

A session defines the environment for tool access: who the agent acts for, which tools it can reach, and how calls are authorized. It also carries optional instructions, preloaded tools, output views, and a VPC attachment.

An actor is a user-defined identity for an application user. Its ID associates that user’s provider accounts with a session. A connection authorizes a provider account for that actor. Sessions and new connections belong to the DigitalOcean user who creates them, within a team. Sessions with the same owner and actor ID can reuse connections in that team. Use different actor IDs for separate accounts with the same provider, such as work and personal GitHub accounts.

Provider credentials are resolved at execution time rather than passed to the model. You grant their scopes in the provider’s system and remain responsible for limiting those scopes.

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 for evaluation behavior and Configure Approvals for client requirements.

Catalog Configuration and Execution

Group tools into versioned Toolbelts for selection and group permissions, register a custom tool provider, or bind an output view to reduce the fields returned to the agent.

Execution uses each tool’s configured reliability policy. Eligible failures can receive bounded retries, with provider idempotency protection where supported. See Reliable Execution.

Start with the Action Gateway Quickstart or connect your own application. For managed-agent integration, see Connect Action Gateway to Harness Runtime.

For production agents with a defined workflow, see Configure Action Gateway for Production Agents to restrict tools, preload known operations, call tools directly from Python, and reduce output data.

See What You Can Build with Action Gateway for standalone use cases and worked session configurations for web research and Jira triage.