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 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.

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 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 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. 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.
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 and keep the same MCP URL.

For an application serving other users, assign each user a separate actor ID and have them connect their own accounts. Your backend owns the Action Gateway resources. Each user grants access to their GitHub or Linear account.

A Toolbelt 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.

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 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.

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.
• Create an output view and select it 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 for evaluation behavior and Configure Approvals 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.

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.

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.