- Getting started
- UiPath Agents in Studio Web
- About UiPath Agents
- Licensing
- Running agents
- Working with files
- Contexts
- Escalations
- Evaluations
- Agent traces
- Agent score
- Managing UiPath agents
- UiPath Coded agents
- Build with Coding Agents
Client-side tools execute on the user's browser or host application, enabling access to client-local data and device capabilities unavailable server-side.
Client-side tools execute on the client surface — the user's browser or host application — rather than on the UiPath server. When the agent calls a client-side tool, the runtime pauses, delegates the tool call to the client, and resumes once the client returns a result.
Use client-side tools when the agent needs access to data or capabilities that only exist on the client, such as application state, local data, or UI actions that cannot be performed server-side.
When to use client-side tools
Use client-side tools when the agent needs to:
- Access client-local data — Read information from the host application that is not available to the server, such as the contents of a task board, form fields, or session-specific state.
- Trigger client-side actions — Perform actions within the host application, such as navigating to a page, opening a dialog, creating a record in the local UI, or updating a component.
- Leverage client-specific capabilities — Use device or browser features that are not accessible from the server, such as clipboard access, local storage, or geolocation.
Client-side tools are available only for conversational agents deployed through a surface that supports client-side tool handling, such as the UiPath TypeScript SDK or any surface that implements the UiPath conversation protocol. The surface must register a handler for each client-side tool; tools without a registered handler return an error to the agent.
Configuring client-side tools
To add a client-side tool to your conversational agent:
-
In the agent designer, select Add tool.
-
Select the Client-side tools category.
-
Fill in the following fields:
- Tool name — A unique name for the tool. Must begin with a letter or underscore and can contain only letters, digits, spaces, and underscores.
- Description — Describe what the tool does and when to use it. This description guides the agent's decision to call the tool.
- Input schema — A JSON Schema object defining the parameters the agent passes to the client when calling the tool.
- Output schema — A JSON Schema object defining the structure of the result the client returns to the agent.
-
Select Create.
After creating the tool, you can configure additional settings in the tool properties panel:
- Edit the tool name, description, and schemas.
- Apply guardrails to enforce runtime policies.
- Enable tool-call confirmations to require user approval before execution.
Input and output schemas
Both schemas are required and must be valid JSON Schema objects. They define the contract between the agent and the client:
- The input schema specifies what data the agent sends to the client when it calls the tool. The agent populates the input values based on the conversation context and the schema definition.
- The output schema specifies what data the client returns to the agent after executing the tool. The agent uses this result to continue its reasoning.
Example schemas
For a tool that reads tasks from a project board:
Input schema:
{
"type": "object",
"properties": {
"boardId": {
"type": "string",
"description": "The ID of the task board to read from"
},
"status": {
"type": "string",
"enum": ["todo", "in-progress", "done"],
"description": "Filter tasks by status"
}
},
"required": ["boardId"]
}
{
"type": "object",
"properties": {
"boardId": {
"type": "string",
"description": "The ID of the task board to read from"
},
"status": {
"type": "string",
"enum": ["todo", "in-progress", "done"],
"description": "Filter tasks by status"
}
},
"required": ["boardId"]
}
Output schema:
{
"type": "object",
"properties": {
"tasks": {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": { "type": "string" },
"title": { "type": "string" },
"status": { "type": "string" },
"assignee": { "type": "string" }
}
}
}
}
}
{
"type": "object",
"properties": {
"tasks": {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": { "type": "string" },
"title": { "type": "string" },
"status": { "type": "string" },
"assignee": { "type": "string" }
}
}
}
}
}
Behavior on pre-built surfaces
On pre-built surfaces like Instance Management and iFrame embedding, client-side tools display a form to the user based on the output schema. The user fills in the fields manually and submits the result back to the agent.
The full value of client-side tools is realized on custom surfaces built with the UiPath TypeScript SDK, where the host application handles tool calls programmatically — reading data, triggering actions, or interacting with local systems without manual user input.
How client-side tools work at runtime
When the agent calls a client-side tool during a conversation:
- The agent decides to use the tool based on the conversation context and the tool description.
- If tool-call confirmations are enabled, the user reviews and approves the proposed input before the tool proceeds.
- The runtime sends the tool call — including the tool name, input values, and input/output schemas — to the client surface.
- The client surface executes its registered handler for the tool using the provided input.
- The client returns the result to the runtime.
- The agent receives the result and continues its reasoning.
Tool-call confirmations
You can require user confirmation before a client-side tool executes. This is useful for tools that perform actions with visible side effects, such as creating a task, updating a record, or navigating away from the current page.
To enable confirmation for a client-side tool:
- Select the client-side tool in the agent designer.
- In the tool properties, enable Require confirmation.
When enabled, the agent pauses before executing the tool and shows the user the proposed input parameters. The user can approve, modify the inputs, or reject the tool call.
Example: project planning assistant
Consider a project planning assistant embedded in a task management application. The agent has two client-side tools:
- read_board_tasks — Reads the current tasks from the user's task board in the host application.
- create_task — Creates a new task on the user's board.
Reading data from the client: When a user asks "What should I work on next?", the agent calls read_board_tasks. The host application reads the board state and returns the task data. The agent then analyzes the tasks and suggests a priority order based on status, deadlines, and dependencies.
Writing data to the client: When the user asks "Add a task to review the Q3 report by Friday", the agent calls create_task with the title, description, and due date. If confirmation is enabled, the user reviews the proposed task details first. The host application creates the task on the board and the agent confirms it was created.
Limitations
- Client-side tool execution depends on the client surface's availability and responsiveness. If the client disconnects during tool execution, the tool call may fail.
- The client surface must register a handler for each client-side tool the agent defines. If a handler is missing, the tool call returns an error to the agent.