Skip to main content
Open Managed Agents provides a set of built-in tools that agents can use autonomously within a session. You control which tools are available by specifying them in the agent configuration. Open Managed Agents also supports custom, user-defined tools. Your application executes these tools separately and returns the results to the agent, which uses them to continue the task. To give the agent tools from an MCP server, use the MCP connector instead.
Managed Agents API requests require the managed-agents-2026-04-01 beta header, except memory store endpoints, which use agent-memory-2026-07-22 instead. The SDK sets the correct beta header automatically. See Beta headers.

Available tools

The agent toolset includes the following tools. All are enabled by default when you include the toolset in your agent configuration. Use the values in the Name column to reference tools in the configs array. When a tool output exceeds 100,000 characters (about 25,000 tokens), it is automatically written to a file in the sandbox. The model receives a truncated preview with the file path and can read the full content from there.

Configuring the toolset

Enable the full toolset with agent_toolset_20260401 when creating an agent. Use the configs array to disable specific tools or override their settings. Each config entry can also set a permission_policy that controls whether the tool’s calls are auto-approved or require confirmation. See Permission policies for the available policy types.

Disabling specific tools

To disable a tool, set enabled: false in its config entry in the toolset object of your agent’s tools array:

Enabling only specific tools

The default_config object sets the baseline for every tool in the set, and per-tool configs entries override it. To start with everything off and enable only what you need, set default_config.enabled to false:

Custom tools

In addition to built-in tools, you can define custom tools. Custom tools are analogous to user-defined client tools in the Messages API. Each custom tool defines a contract: you specify what operations are available and what they return, and the agent determines when and how to call them. The model never executes anything on its own. It emits a structured request, your code runs the operation, and the result flows back into the conversation. See Session event stream for how to receive custom tool calls and return results during a session. If your sessions run in a self-hosted sandbox, the environment worker can serve custom tools from your sandbox, including tools that wrap an MCP server inside your network.
Once you’ve defined custom tools on the agent, the agent invokes them during a session.

Best practices for custom tool definitions

  • Provide extremely detailed descriptions. This is by far the most important factor in tool performance. Your descriptions should explain what the tool does and when to use it (and when not to). Explain what each parameter means and how it affects the tool’s behavior. Call out any important caveats or limitations. The more context you give the agent about your tools, the better it can determine when and how to use them. Aim for three to four sentences for each tool description, more if the tool is complex.
  • Consolidate related operations into fewer tools. Rather than creating a separate tool for every action (create_pr, review_pr, merge_pr), group them into a single tool with an action parameter. Fewer, more capable tools reduce selection ambiguity and make your tool surface easier for the agent to navigate.
  • Use meaningful namespacing in tool names. When your tools span multiple services or resources, prefix names with the resource (for example, db_query or storage_read). This makes tool selection unambiguous as your library grows.
  • Design tool responses to return only high-signal information. Return semantic, stable identifiers (for example, slugs or UUIDs) rather than opaque internal references, and include only the fields the agent needs to determine its next step. Bloated responses waste context and make it harder for the agent to extract what matters.

Next steps

MCP connector

Connect MCP servers to your agents for access to external tools and data sources.

Permission policies

Control when agent and MCP tools execute.

Session event stream

Send events, stream responses, and interrupt or redirect your session mid-execution.