Why I built a Python MCP server for UiPath Orchestrator

Anthropic shipped the Model Context Protocol because the alternative is every agent reinventing how it talks to every tool. Once a system speaks MCP, any MCP-aware agent — Claude Desktop, an IDE, a custom workflow — can drive it without bespoke integration. That's the bet, and it's the right one.

The natural question for anyone in the UiPath ecosystem is: where does the largest installed base of process automation sit in this story? Today, mostly outside it. Orchestrator has a clean REST API, but a REST API isn't an MCP server — and "the agent can technically curl the endpoint" isn't the same as "the agent knows the verbs, the resources, the auth model, and the failure modes." It needs to be wired through, in the language of the protocol, with the auth strategies real deployments actually use.

So I built that wiring: uipath-orchestrator-mcp-python — a Python MCP server that exposes Orchestrator as a first-class agent tool. 29 tools across folders, robots, processes, jobs, queues, schedules, logs, audit, analytics, and licensing — all typed, async, organised by domain.

The three auth strategies decided the shape. Most automation tooling I've seen treats authentication as an afterthought — one happy path, usually cloud OAuth, with everything else papered over later. That collapses the first time you hit a real deployment. So the server ships with three first-class strategies, picked by a single env var:

• Cloud OAuth for hosted Orchestrator tenants
• On-prem (username + password) for the deployments where the agent has to live inside the boundary — sovereign, regulated, mission-critical, the work I do most of
• Personal Access Token for quick scripts, IDE integrations, anything where OAuth is overkill

The on-prem strategy is the one that exists because demos don't survive contact with the kind of infrastructure I work against. If your agent can't reach Orchestrator behind a corporate firewall with no line to the outside, it doesn't matter how clever the model is.

What it lets you do. With the server running and Claude Desktop pointed at it, you can ask the agent:

• "Schedule the Invoice Processing job to run weekdays at 9 AM in the Finance folder."
• "List all jobs that failed in the last 24 hours, group them by process, show me the error message for the most common failure."
• "How many items are pending in queue OnboardingEmployees, and which robots are configured to process it?"
• "Run a one-time execution of Reconciliation in the AsiaTenant, then tell me when it finishes."

The agent reads the request, picks the right tool, calls the right Orchestrator endpoint, and returns a result you can act on — without leaving the chat, and without anyone writing a bespoke integration.

What's next. The README lists the install path; the repo is public. If you build something interesting on top of it, or hit a missing tool you'd like exposed, open an issue — I read every one. There's more coming around examples, packaging, and CI; this is the first cut of something I plan to maintain.

The bigger thesis is the obvious one: the enterprises that actually have production automation today are the ones with UiPath estates. Connecting that estate to the new generation of agents isn't a side project — it's how the existing investment compounds rather than gets replaced. A small piece of public infrastructure to make that easier seemed worth the weekend it took.