ToolsCopy Anchor Link

The Tools panel in Action Agent Studio enables the registered builtin httpRequest and named HTTP tools. Attached Knowledge collections and MCP servers add their own tools to the same turn.

The model decides whether and when to call an available tool. Attaching a tool does not force a call, and the selected model must support function calling.

Registered builtinCopy Anchor Link

httpRequest is the only currently registered Agent builtin tool. Email, Slack, and SMS are not Agent builtins:

• Email, Slack, Discord, and Teams delivery belongs to triggers.
• Use an outbound MCP server or a named HTTP tool for other communication APIs.

The builtin does not require an organization credential. Its model-visible input is:

Unlike a named tool, httpRequest lets the model choose the complete URL and headers on every call. Do not attach it when the model must not be able to choose arbitrary public endpoints.

Named HTTP toolsCopy Anchor Link

A named HTTP tool fixes the method, base URL template, static headers, authentication, and parameter schema. The model sees only the tool name, description, and declared parameter schema. It does not receive the stored authentication payload as a model argument.

For example, a tool can expose getOrders({ orderId }) while the Action Agent Studio owner configures:

GET https://api.example.com/orders/{orderId}

The runtime substitutes the encoded orderId into the path. The model cannot replace the method, host, authentication, or static headers for that named tool.

ParametersCopy Anchor Link

Each declared parameter has:

Runtime behavior by location:

• path: replaces a matching {name} in the URL and URL-encodes the string form.
• query: adds a query parameter.
• body: retains the declared value's JSON type and sends a JSON object. Bodies are omitted for GET and HEAD.
• header: converts the value to a string and adds that header.

Required values are enforced by the tool schema and again before the request. A missing path placeholder returns a tool error instead of sending a partial URL.

Named HTTP tool names are sanitized to a maximum of 64 characters for the base name. If the base starts with a digit, ActionFlows adds an http_ prefix after truncating the base, so the final name can exceed 64 characters. Creation collision handling is best-effort: it checks existing non-deleted tools for the sanitized name and tries numeric suffixes such as _2 and _3. Each suffix candidate is sanitized and truncated, so long bases can collapse candidates and creation may fail to find a distinct name. There is no persisted database uniqueness constraint, and updates can leave duplicate names. At runtime, the enabled named-tool loader attempts to de-duplicate loaded keys by trying the base, a suffix containing the first eight characters of the tool ID, and numeric suffixes. Because candidates are sanitized and truncated to 64 characters, long bases can leave suffix resolution unable to return a distinct candidate. The resolver reserves MCP names when building named HTTP and builtin tools, rejects effective descriptor collisions before merge, and then merges maps in MCP, named HTTP, builtin, and Knowledge order. If any remaining duplicate final runtime name exists, it throws Agent tool name collision; it does not overwrite an earlier entry. Current MCP keys are normally prefixed with their attachment ID, so cross-kind collisions are uncommon.

Authentication and headersCopy Anchor Link

The saved authentication modes are:

Authentication payloads are encrypted for the organization and decrypted only in the server runtime. Static named-tool headers are stored in headersJson; the current implementation does not encrypt that JSON field. Do not place reusable secrets in static headers unless you accept this current limitation. Prefer the encrypted authentication modes.

Request header precedence is JSON content type, static headers, encrypted authentication, and then model-supplied header parameters. Authentication therefore overrides a static header with the same name, and a declared header parameter can override both.

Network and response boundariesCopy Anchor Link

Builtin and named HTTP tools use the same server-side HTTP implementation:

• only http: and https: URLs are accepted;
• credentials embedded in the URL are rejected;
• DNS results are checked against loopback, private, link-local, carrier-grade NAT, multicast, reserved, and other blocked ranges;
• hostname resolution is pinned for the request to reduce DNS-rebinding risk;
• every redirect is revalidated, with at most five redirects;
• the default timeout is 30 seconds and the accepted range is 1-300 seconds; and
• the response body is capped at 5 MiB.

Action Agent Studio also checks a named tool's saved URL template when it is created or updated. Runtime checks remain authoritative because DNS and redirect targets can change after saving.

Which tools reach the modelCopy Anchor Link

The runtime builds the turn's tool set in this order:

1. enabled tools from attached MCP connections;
2. enabled, non-deleted named HTTP tools;
3. registered builtin bindings such as httpRequest; and
4. search_knowledge and read_document when at least one Knowledge collection is attached.

The maps are merged in the order listed above. The resolver rejects effective descriptor collisions before merge and then throws Agent tool name collision if any remaining duplicate final runtime name exists; it does not overwrite earlier entries. MCP tools are exposed only when their names are in that attachment's enabledToolNames; an empty MCP selection means no tools. Named HTTP tools are loaded only when enabled is true. The current named-tool readiness check requires only a non-empty name and an HTTP(S) URL template. A description may be empty (the runtime supplies a fallback), and a parameter schema may be empty; those fields affect model guidance, not that readiness check.

A tool that returns an error becomes tool output for the model; it does not automatically fail the whole chat turn. The model can try another tool or explain the failure.

Tool-call outputCopy Anchor Link

Action Agent Studio's transcript renders tool parts with the tool name, lifecycle state, model input, tool output, and tool error when present. The durable Agent transcript stores those non-text parts along with the assistant text.

The public REST JSON result and public Action Agent SSE contract expose final assistant text, not the internal tool-call event stream. Channel triggers send only the final reply according to their reply policy. Tool inputs and outputs can still be visible in Action Agent Studio, so do not return credentials or unnecessary personal data from a tool.

RelatedCopy Anchor Link

• Model selection
• Knowledge
• MCP
• Triggers
• Troubleshooting