HTTP, MCP, and container custom tools

Use Tools Studio → Custom Tools Manager when an integration package does not provide the action you need. A custom tool defines what the model can request and how the runtime executes it.

Define the basics

Create a tool with a stable ID, clear name, and description. The description should state the outcome, when the tool is appropriate, and important limits. Avoid vague descriptions that overlap several tools.

Add input fields with snake-case names, types, descriptions, required state, and choices where appropriate. These fields are the structured arguments users and the model can pass.

HTTP tools

Configure the HTTPS URL, method, timeout, maximum response bytes, and required headers. Put secrets in dedicated secret or header configuration, not in descriptions or default arguments.

Private and loopback targets are blocked unless the runtime explicitly allows private-network custom tools. On a Cloud agent, use Tailscale for intentional private reachability.

Restrict response size and timeout so a slow or unbounded endpoint cannot occupy the tool worker indefinitely.

MCP tools

Enter the MCP server URL, exact MCP tool name, timeout, response limit, and headers. Confirm the server’s transport and authentication expectations. A successful server connection does not prove the named remote tool is safe for arbitrary arguments.

Container tools

Container tools run a command template in a configured Docker or Podman environment. Set an image, timeout, memory, CPU, output-byte, and process limit. Leave network disabled unless the task requires it and the approval policy accounts for the added reachability.

Image builds can be disabled or restricted to approved base images by the runtime. Do not weaken those controls merely to make an unreviewed Dockerfile build.

Test before enabling

Use Run Test with harmless representative values. Inspect the result, error handling, timeout, and output truncation. Advanced JSON shows the raw input schema, headers, or command template when you need to verify generated configuration.

Testing exercises the runtime, so it can still cause effects. Use a sandbox endpoint or read-only arguments.

Apply policy

Enable the tool only after the test passes. Add it to the smallest appropriate tool profile and choose an approval mode based on risk. External writes, command execution, and destinations supplied by users should normally ask for review.