UiPath Documentation
uipath-cli
latest
false
UiPath CLI user guide

Tools (plugins)

Tools architecture in UiPath CLI, covering how installable npm packages extend the host with new top-level commands.

UiPath CLI is a small host wrapped around a set of installable tools. Each tool is an ordinary npm package that registers one top-level command (and its subcommands) with the host. This is the single most important concept for understanding why uip works the way it does — what installs automatically, what doesn't, how versions are kept in sync, and why uip --help shows different commands on different machines.

Host and tools​

The host (@uipath/cli, the uip executable) owns only a narrow set of concerns:

  • Authentication (uip login, uip logout, uip login status, uip login tenant …).
  • Session and credential management.
  • Tool lifecycle (uip tools list / search / install / update / uninstall).
  • Skills for coding agents (uip skills install / update / uninstall).
  • The Model Context Protocol bridge (uip mcp).
  • Shell completion installation (uip completion).
  • Global options (--output, --output-filter, --log-level, --log-file) and the JSON output envelope.

Everything that touches a UiPath surface — Orchestrator, Solutions, Agents, Flows, Maestro, RPA packaging, Test Manager, Integration Service, Data Fabric, Insights, Traces, DocsAI, API Workflow, Vertical Solutions, Coded Agents, and Coded Apps — lives in a separate npm package that the host loads on demand.

Why the split:

  • Independent release cadences — the Orchestrator tool can ship without re-releasing the host, and vice versa.
  • Smaller install footprint — a user who only runs test pipelines does not need the Flow or Maestro tools on disk.
  • Stable contract — tools talk to the host through a versioned programmatic interface (command registration, output envelope, context, telemetry), not through shared internals.
  • Faster startup — tool code is loaded lazily. The host does the minimum to parse argv and identify the relevant tool, then requires that tool's bundle once.

The auto-install whitelist​

A set of UiPath-owned tools is on an auto-install whitelist. The host knows them by their command alias and maps the alias to an npm package:

AliasPackageLong name
or@uipath/orchestrator-toolOrchestrator (jobs, folders, processes, packages, machines, users, roles, licenses, assets, queues, storage buckets, libraries, triggers, webhooks)
solution@uipath/solution-toolSolution
rpa@uipath/rpa-toolRPA (Studio packaging, analyzer, restore)
agent@uipath/agent-toolAgent
codedagent@uipath/codedagent-toolCoded Agent
codedapp@uipath/codedapp-toolCoded App
maestro@uipath/maestro-toolMaestro
tm@uipath/test-manager-toolTest Manager
is@uipath/integrationservice-toolIntegration Service
vss@uipath/vertical-solutions-toolVertical Solutions
api-workflow@uipath/api-workflow-toolAPI Workflow
df@uipath/data-fabric-toolData Fabric
insights@uipath/insights-toolInsights
traces@uipath/traces-toolTraces
docsai@uipath/docsai-toolDocsAI
rpa-legacy@uipath/rpa-legacy-toolRPA Legacy — Windows-only wrapper around uipcli.exe for the Studio commands not yet ported to the cross-platform rpa tool (debug, validate, find-activities, find-package, type-definition, package). See uip rpa-legacy.
eval@uipath/eval-toolRuntime evaluation of deployed packages against an Orchestrator process — evaluators, eval sets, evaluations, schedules. Standalone package, not a sub-command of or.
platform@uipath/platform-toolPlatform — tenant licensing, user bundles, group rules, consumables
admin@uipath/admin-toolAdmin — users, groups, robot accounts, external apps, SMTP, authorization, IP restriction, organizations, tenants, VPN gateways, resource catalog, audit
gov@uipath/gov-toolGovernance — AOps policies, access policies, compliance packs
agenthub@uipath/agenthub-toolAgentHub — MCP server registrations, tools, remote A2A agents
ah@uipath/automation-hub-toolAutomation Hub — ideas, pipeline, taxonomy, users
aops@uipath/aops-toolStudioAdmin AOps — connections, repos, projects, solutions, pipelines, executions
coder@uipath/coder-toolCoder — AI coding agent (Preview build only)
context-grounding@uipath/context-grounding-toolContext Grounding — Python bridge
conversational@uipath/conversational-toolConversational — chat, agents, conversation history, trunks
function@uipath/function-toolFunctions — build, serve, publish JS/TS and Python Functions
guardrails@uipath/guardrails-toolGuardrails — BYO guardrail configurations, AI Trust Layer
ixp@uipath/ixp-toolIXP — Intelligent Document Processing (projects, taxonomy, documents, deployments)
llm-configuration@uipath/llmgw-toolLLM Configuration — BYO LLM connections, AI Trust Layer. Note the package name (llmgw-tool) does not match the alias.
llm-gateway@uipath/llm-gateway-toolLLM Gateway — list available models. A separate package from llm-configuration above, despite the similar name.
model-hub@uipath/model-hub-toolModel Hub — LLM Gateway routing configuration
pm@uipath/pm-toolProcess Mining — apps, transformations, data ingestion
tasks@uipath/tasks-toolAction Center tasks — catalogs, comments, labels, metadata, data

The host treats everything else as not-a-tool. This table matches the current TOOLS_WHITELIST exactly — every entry has a reference page on this site. @uipath/flow-tool and @uipath/case-tool are deliberately absent: they are not independently whitelisted, but dependencies that @uipath/maestro-tool imports directly to register its flow and case branches (see the note on About UiPath CLI).

What installs automatically, and what doesn't​

Nothing is preinstalled. A fresh npm install -g @uipath/cli puts only the host on disk.

Two ways a tool is installed on your machine:

  1. Auto-install on first use. The first time you invoke a command whose prefix matches a whitelist entry — for example uip or folders list before the Orchestrator tool is installed — the host downloads and installs @uipath/orchestrator-tool from npm, then runs your command. Subsequent invocations use the installed tool directly, so the second run is fast.

  2. Explicit install. Run uip tools install <alias> (or the full package name). Same end state; faster at runtime because no auto-install step is needed. See uip tools reference.

Use explicit install in CI runners and for offline environments so that build times are deterministic and the first command in a job does not pay the one-time download cost. See the install guide's auto-install section for the full tradeoff.

Note:

CI=true does not disable auto-install — that variable is not consulted anywhere in the auto-install path. The real opt-out is UIPATH_CLI_DISABLE_AUTOINSTALL=true, which turns off implicit tool installs entirely, including the daily per-tool freshness check (see Version resolution below). Without it, the pragmatic workaround is still to pre-install the tools you know you'll use — auto-install is a no-op when the tool is already present.

Third-party tools are not supported in UiPath CLI 1.x. The host validates against the whitelist at install time, so uip tools install my-company/some-tool fails with a ValidationError. A public extension mechanism may appear in a later version; for now, uip only loads the tools in the table above.

Where tools live on disk​

Tools install into an @uipath/ folder under the npm prefix that owns the CLI's entry script:

  • If you installed @uipath/cli globally (npm install -g @uipath/cli), tools install globally next to it — at $(npm root -g)/@uipath/<tool-name>/.
  • If you installed the CLI into a local project (npm install @uipath/cli inside a package), tools install locally next to it — at that project's node_modules/@uipath/<tool-name>/.

In other words, tools follow the CLI: global CLI, global tools; local CLI, local tools. This is handled automatically — you do not need to pass any scope flag to uip tools install.

Run uip tools list to see which tools are installed and what version. Run npm root -g to find the global install path on your machine.

Version resolution — tools track the host​

By default, each tool version is pinned to the CLI's major.minor line. When you run uip tools install or with CLI 1.0.x, the host resolves the latest @uipath/orchestrator-tool whose version begins with 1.0. and installs that. When you run uip tools update, every installed tool is bumped to the latest version still within the CLI's major.minor line.

The practical consequences:

  • Upgrading the CLI to a new MINOR version is a two-step operation. After npm install -g @uipath/cli@1.1.0, run uip tools update to bring every installed tool to the 1.1.x line.
  • Pinning the CLI effectively pins all tools. npm install -g @uipath/cli@1.0.3 and then uip tools update produces a deterministic set of tool versions on any machine.
  • Host and tools ship compatible protocol changes together. A tool built against 1.1.x may call internal contract that 1.0.x doesn't know about — allowing mixed CLI+tool versions would risk loading a tool the host cannot understand.

You can override the default and install a specific tool version explicitly:

uip tools install orchestrator-tool@1.2.3
uip tools update --name @uipath/orchestrator-tool --version 1.2.5
uip tools install orchestrator-tool@1.2.3
uip tools update --name @uipath/orchestrator-tool --version 1.2.5

Preview builds are not selected with an npm dist-tag like @beta on the install command — that syntax doesn't exist. Instead, the CLI-wide release channel is a config setting, core.updateChannel, managed with uip config:

uip config set updateChannel preview   # opt into preview tool builds
uip tools install orchestrator-tool    # now resolves the preview line

uip config set updateChannel stable    # switch back
uip config set updateChannel preview   # opt into preview tool builds
uip tools install orchestrator-tool    # now resolves the preview line

uip config set updateChannel stable    # switch back

updateChannel is one of stable (default) or preview; a third, unadvertised dev channel exists for CLI builds published from main. Preview commands within an otherwise-stable tool are labeled independently; see Versioning and stability.

The CLI also keeps itself and its tools fresh automatically. Once a day, the first eligible uip command checks for a newer CLI version on the configured channel and re-executes itself on it if one exists (never crossing a new MAJOR version unattended); separately, each installed tool is refreshed to the latest version on the CLI's own line the first time you use it each day. Both checks fail closed rather than silently skip if they can't complete. Disable both with UIPATH_CLI_DISABLE_VERSION_SYNC=true. To freeze the version line yourself instead of tracking "latest," pin it with uip config set version <major.minor[.patch]> — see uip config for the exact version/updateChannel contract.

Tip:

To verify which tool versions are on a machine after a deploy, uip tools list --output json prints the name, version, and command prefix of each installed tool. Diff this against a known-good snapshot to catch drift.

How the host loads tools​

When uip <alias> … runs:

  1. The host reads argv, strips global flags (--output, --log-level, etc.), and identifies the first non-flag token as a potential tool alias.
  2. If the alias matches an installed tool, the host loads that tool on demand and asks it to register its subcommands.
  3. If the alias is on the whitelist but the tool is not installed, the host runs auto-install (see above) and then goes to step 2.
  4. If the alias is not on the whitelist and not a recognized host command, the host fails with "unknown command" and prints usage.

That is the entire loading model. There is no plugin manifest, no registry config file, no user-editable list. The whitelist built into the host package is the source of truth.

Was this page helpful?

Connect

Need help? Support

Want to learn? UiPath Academy

Have questions? UiPath Forum

Stay updated