Skip to main content
Glama
adamstuber

uipath-orchestrator-mcp

by adamstuber

stop_job

Stop a running UiPath job by job ID and folder, choosing between a graceful SoftStop or an immediate Kill strategy.

Instructions

Stop a running job.

Args: job_id: The ID of the job to stop. folder_name: The display name of the folder containing the job. strategy: Stop strategy — 'SoftStop' (graceful, waits for current transaction) or 'Kill' (immediate).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYes
strategyNoSoftStop
folder_nameYes
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must disclose behavioral implications. It mentions strategy semantics ('SoftStop' waits, 'Kill' immediate), but does not state reversibility, required permissions, or the effect on the job's final state. For a mutating tool, this is minimal disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, with a clear action line followed by a concise Args block. Every sentence contributes value, and there is no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The core operation and parameters are covered, but the tool has no annotations and no output schema. It would benefit from stating what happens after stopping (e.g., job state, return value, whether the operation is idempotent), leaving some gaps for a mutating action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description fully compensates by listing all three parameters and adding meaning: job_id is an ID, folder_name is a display name, and strategy explicitly defines allowed values. This goes well beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Stop' with the resource 'a running job', clearly defining the tool's function. It naturally distinguishes this from sibling tools like start_job and get_job by indicating the action on a job.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: it stops a running job and explains the two strategies ('SoftStop' and 'Kill'), which helps the agent decide based on desired behavior. It lacks explicit alternatives or when-not-to-use guidance, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adamstuber/uipath-orchestrator-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server