Agent Tools

Adds a COMPLEX variable to a Robot v1 XML file. It automatically adds the type to the <referenced-types> section if missing. Args: file_path: Path to the .robot file. var_name: Name of the variable (e.g. 'MyData'). type_name: Name of the complex type (e.g. 'KFT_001_MyType'). Must match a .type file name usually.

Adds a new step to a Robot V1 XML file *safely* and returns the new step's ID. ROBOT TYPE: V1 XML only (files with <object class="Robot">) For V2 JSON robots, use add_robot_v2_step instead. This tool correctly handles all XML parsing and automatically rewires the graph. You MUST provide the node IDs for the step *before* (previous_node_id) and *after* (next_node_id) the new step. This tool automatically performs the following (and will ABORT if it cannot safely rewire the graph): 1. Renders the step XML from the template_name. 2. Validates there is an existing edge: previous_node_id -> next_node_id. If that direct edge is not present the insertion is aborted to avoid breaking the robot's control flow. 3. Inserts the new step *after* previous_node_id in the XML <steps> list. 4. Updates the located edge to: previous_node_id -> new_step_id. 5. Adds a *new* edge: new_step_id -> next_node_id. 6. Returns a JSON object with the status and the new_node_id. Args: file_path (str): The V1 .robot file to modify (e.g., "one of the files in the given file read path that ends with .robot"). previous_node_id (str): The 'id' of the step that comes *before* the new step. next_node_id (str): The 'id' of the step that comes *after* the new step. template_name (str): The key from 'list_available_step_templates' (e.g., 'assign_variable'). parameters (dict): A dict of parameters to fill the template (e.g., {"name": "My Step", "value": "123"}). Returns: str: A JSON string: {"status": "Success", "robot_type": "v1_xml", "new_node_id": "gen_..."} or {"status": "Error", "robot_type": "v1_xml", "message": "..."}

Adds MULTIPLE steps to a Robot (v1 XML) file in a single batch. This is much more efficient than adding steps one by one. Args: file_path (str): The .robot file to modify. previous_node_id (str): The ID of the node to start inserting after. next_node_id (str): The ID of the node that should follow the LAST inserted step. steps (list): A list of dictionaries, where each dict represents a step to add. Each dict must have: - 'template_name': str (e.g. 'ExtractCell') - 'parameters': dict (The parameters for that step) Example: [ {"template_name": "LoopInExcel", "parameters": {...}}, {"template_name": "ExtractCell", "parameters": {...}} ] Returns: str: JSON string with status and list of new node IDs.

Adds a new step to a Robot2 (JSON) file using a template. This tool performs 'surgical' JSON modification. It finds the 'after_step_name' and inserts the new rendered step after it. Make sure you are placing the step in the correct location, do not insert a step inside of another one accidentally. Place it as its own step on the top level on the hierarchy, dont put it inside another step. Args: file_path (str): The relative path to the .robot2 file. after_step_name (str): The 'customName' of the step *before* the new step. template_name (str): The key from the step template library (e.g., 'click'). parameters (dict): A dict of parameters to fill the template (e.g., '{"step_name": "Click Button"}').

Adds a variable to a Robot V2 (JSON) file's variables array. Use this for Robot2/DAS-style robots. For classic v1 XML robots, use add_robot_variable. Args: file_path: Path to the Robot2 file var_name: Name of the variable (e.g., "TransactionItem", "Config") var_type: Kofax type - one of: Text, Integer, Number, Boolean, Date, Password, Binary Returns: Success message or error details.

Adds a variable to a Robot v1 XML file's Variables section. Uses type mapping: String=12, Integer=11, Boolean=3, Date=8, Decimal=9, File=150.

Audit every step template for advertised/rendered parameter conflicts. A parameter that is advertised but not rendered can mislead agents into passing a value that has no effect. A rendered-but-unadvertised parameter can cause a step to render with an empty value. Both are reported.

No argument schema exposed.

Create a filtered SAP report ZIP from a transaction, recipients and structured filter. This is the preferred tool when an SAP report download request includes filtering. Convert the user's natural-language filtering request to the structured filter object. Generation only inserts Constant_Trsn1, Config.Mail_To and FilterJson into a copy; it does not alter the robot graph or helper files.

Create an unfiltered SAP report ZIP from the supplied working template. This is the preferred tool for a simple or standard SAP transaction report download request. Do not recreate that workflow with generic V1/V2 robot construction tools.

Creates a new, valid Kofax Robot V1 XML file. Use this for robots that require Excel operations, Variables, or other V1-exclusive features. The robot will contain a 'Start' node and an 'End' node connected by an edge. This tool does not create type 2 robots, use create_robot_v2 if thats what you mean. Args: file_path (str): Path for the new `.robot` file. It MUST be inside the active project's `Library` folder; use `Library\MyRobot.robot` or an absolute path ending in `...\<project>\Library\MyRobot.robot`. Paths directly under the project folder are rejected. robot_name (str): The name of the robot (optional). Returns: str: "Success" or an error message.

Creates a new, valid Kofax Robot V2 (JSON) file. Use this for modern robots with browser automation (CEF/Chrome). NOTE: Use add_robot_v2_variable() to add variables to V2 robots. For Excel operations and classic loops, use create_robot_v1 instead. This tool does not create type 1 robots, use create_robot_v1 if thats what you mean. Args: file_path (str): Path for the new `.robot` file. It MUST be inside the active project's `Library` folder; use `Library\MyRobot.robot` or an absolute path ending in `...\<project>\Library\MyRobot.robot`. Paths directly under the project folder are rejected. Extension MUST be `.robot` (not `.robot2`). robot_name (str): The name of the robot (optional). force (bool): When True, overwrite an existing robot file. Defaults to False. Returns: str: "Success" or an error message.

Retrieves a specific chunk of nodes from a robot file. Use this when fetch_file_overview indicates the robot is truncated. Works with both Robot v1 (XML) and Robot v2 (JSON) files. Args: file_path: Path to the robot file. offset: Starting index of nodes to retrieve (default 0). limit: Number of nodes to retrieve (default 50). Returns: JSON string containing the chunk of nodes and total count.

Return one parsed robot node and a small number of adjacent nodes.

Inspect an existing V1 step and return its template-backed edit contract. Use this before a structural edit. The result identifies the step template, returns the parameters extracted from the current node, and describes the accepted update shape. No file changes are made. Currently CallRobot2Step is supported. Unsupported step types return an explicit error rather than offering free-form XML editing.

Lists all available step templates from all libraries. This manifest lists available step types (e.g., 'click', 'enter_text'), their descriptions, and required parameters for both v1 and v2 robots.

Lists all variables from a given robot file. Returns a JSON string containing a list of variable objects.

Modifies an existing step in a Robot file (V1 XML or V2 JSON). ROBOT TYPE DETECTION: Automatically detects robot type from file structure: - V1 XML robots: Have <object class="Robot"> root element - V2 JSON robots: Have <object class="Robot2"> root element with JSON in <body> CRITICAL SAFETY WARNING: - This tool edits the robot structure directly. - XML syntax (brackets, tags) is handled automatically and safely by the library. - RISK: You must ensure the 'property names' and 'values' are valid for the Kofax step type. - Do NOT invent property names. Only use properties you know exist for that step type. Args: file_path: Path to the robot file (v1 .robot or v2 .robot/.robot2). step_id: The ID of the step to modify. For V1 XML: The XML 'id' attribute (e.g., 'step_123'). For V2 JSON: The parser-generated ID from fetch_file_overview (e.g., 'r2_node_5'). properties: Dict of properties to update. For V1 XML: Maps to XML properties (e.g., {'name': 'New Name', 'expression': '1+1'}). For V2 JSON: Maps to JSON fields. Supports dot notation for nested fields (e.g., {'gizmo.name.gizmo.customName.string': 'New Name'}). expected_name: (Optional but Recommended) The current name of the step. Used as a safety check to ensure we are modifying the correct node, especially for V2 where IDs are index-based. Returns: JSON with status, message, and robot_type field indicating which format was modified.

Replace an existing V1 step by re-rendering its inferred step template. This is the safe tool for structural changes such as adding inputs to a CallRobot2Step. `parameters` is a partial update merged into parameters extracted from the existing node. The tool controls the node ID, preserves graph edges, rejects unknown or malformed parameters, and aborts if the template cannot represent any existing configuration. Call get_robot_step_edit_contract first to inspect the accepted schema. Free-form XML and arbitrary property injection are never accepted.

Search and relevance-rank parsed robot nodes without returning the complete robot. Exact names and phrases rank first, followed by nodes containing all query terms, then partial matches. The highest-ranked matches include a bounded neighboring-node context so a second tool call is usually unnecessary.

Return bounded original-text windows around matches in a robot file.

Retrieves details of a specific step template. Args: step_id: The ID of the step (e.g., 'Click', 'EnterText'). robot_type: 'v1' (XML) or 'v2' (JSON). Defaults to 'v1'. include_template: If True, includes the full Jinja2 template content. If False (default), returns only description and parameters. Set to True ONLY when you need to generate code. Returns: JSON string with keys: id, description, parameters, [template_content if requested].

Adds an attribute to an existing .type file. Args: file_path: Path to the .type file. attr_name: Name of the attribute (e.g. 'MyField'). attr_type: Type of the attribute. Options: 'Text', 'Integer', 'Boolean', 'Date', 'Number', 'Password'. Defaults to 'Text'. Returns: Status message.

Analyzes an Excel (.xlsx, .xls) or OpenDocument (.ods) file. Automatically searches in TARGET_FOLDER and DATA_FOLDER if a full path is not provided. Returns: JSON with sheet names, columns, and a 2-row sample.

Creates a new .type file with the basic Kofax structure. Args: file_path: Absolute path where the .type file should be saved. type_name: The name of the type (usually matches the filename without extension). Returns: Status message.

Generic Kofax XML / .robot overview. Detects if file is Robot (v1 XML) or Robot2 (v2 JSON) and parses accordingly. Note that you do not need to waste an LLM generation to refresh your file memory. If you have the file you need on the keys to keep it always show you the freshest version of the file. You don't have to call it again. Returns JSON: { nodes[], edges[], groups[], variables[], sqls[], expressions[], llmSummary, truncated?, total_nodes? } NOTE: For large robots (>50 nodes), only the first 50 nodes are returned. Use fetch_robot_graph_chunk(file_path, offset, limit) to get more.

Return the *entire* XML element (opening → closing tag) whose id/idref == tag_id. Works for <object class="Transition">, <object class="Variable">, <typed-variable>, <Group>, etc. The original indentation is preserved.

Lists files under the active project or configured global roots, optionally scoped to Library/ folders. Behavior: - Root scope is the active project when set. - With no active project, "." searches both TARGET_FOLDER (the configured global/agent library) and PROJECTS_ROOT. - If folder_path is "." or empty and a project is active, it resolves to that project folder (otherwise PROJECTS_ROOT). - meta=False (default): only lists files under Library/ subfolders and will auto-scope to a project's Library/ if a project folder is provided. - meta=True: lists all files under the resolved folder (includes meta files). Returns JSON with: - files: array of file objects (name, path, type, size, modified) - scope: requested path, resolved folder/root, meta flag, active project info

This tool extracts the HTML content of the page at the time of the error. This tool should be used when asked to analyze or extract information from a Kofax error snapshot file. It extracts the HTML content of the page at the time of the error. Additional information on the robots error will be prepended to the HTML of the page that was open when the error occurred. If there is a new .html file that means an error has occured recently and you should always use this tool to take a look at the error snapshot, in order to fix the error. Reads a Kofax error snapshot file (XML) and extracts the HTML content of the page at the time of error. When picking tag selectors that will fix the error at the time of this snapshot, you should consider the tags in this page, which tag the error occured on. Usually an error occurs when the selector at a step is outdated and the page slightly changed its ids or names. Pick the new suitable selector for this html content. Args: file_path: Absolute path to the snapshot file. USAGE STRATEGY: 1. Use this tool to FIND the fix (e.g., Identify the new selector or error message). 2. Then, use `modify_robot_step` to APPLY the fix to the existing robot. 3. DO NOT add steps to the robot just to analyze this file. The analysis happens HERE, in your thought process. Returns: A JSON string containing: - html_content: The extracted HTML string. - status: "success" or "error". - message: Error message if applicable.

This tool should be used when asked for repeating the steps taken by a Computer Use Agent. It gives back the information on what the CUA did in its workflow. Reads the latest JSON file from the specified folder (default: 'cua-results') and parses the actions into a format suitable for creating Robot V2 steps. Returns a JSON string containing a list of actions with 'kofax_selector', 'action_type', 'text' (if applicable), and 'step_name'.

Converts a recording (actions.json) into a Markdown Design Document. Args: recording_path: Path to the actions.json file from the recorder. output_path: Path to save the resulting Markdown file (default: design_doc.md). Returns: Status message and the content of the generated design doc.

Gets the full details of a workflow pattern, including its steps and parameters. Use this ONLY when you've decided to apply a specific pattern and need to understand its structure. The steps are suggestions and can be modified. Args: pattern_id: The ID of the pattern (e.g., 'excel_to_sql_loop'). Returns: A JSON object with parameters, steps, and descriptions for adaptation.

Returns a compact catalog of all available workflow patterns. Use this to see what pre-built patterns are available for common tasks. These patterns are extracted from real robots and show how to accomplish specific automation tasks. Use 'get_workflow_pattern_detail' to get the full pattern including steps and variables. Returns: JSON list with pattern id, name, description, and usage_hint.

No argument schema exposed.

Lists available high-level workflow patterns. These patterns are SUGGESTIONS for common automation tasks. They provide a starting point that should be adapted to the specific use case. Returns: A JSON list of patterns with id, name, description, and usage_hint. Call 'get_workflow_pattern_detail' to see the full step sequence for a pattern.

No argument schema exposed.

Parses a design document (Markdown file with a table) into structured steps. Design document is a document created by the user to demonstrate the steps of a process that is being converted to a RPA robot. The steps contain human inputs and intents, you are ment to interpolate the RPA process from this file. Note that for RPA it is not always efficient to follow the steps one to one. And note that sometimes humans might make redundant actions such as click on open blank parts of the file or type wrong things and then correct themselves. You should ignore these redundant actions, intentions take precedence. The design document should contain a Markdown table with columns like: | Step | Action | Target Selector | Value/Variable | Description | The exact column names are flexible; the tool will return all columns found. Args: file_path: Path to the Markdown (.md) file. Returns: JSON object with: - total_steps: Number of steps found. - columns: List of column headers. - steps: List of step objects. - normalized_steps: Agent-friendly normalized steps with noise flags. - agent_guidance: Summary guidance for plan construction. - parser_warnings: Non-fatal table parsing warnings. Usage: Keep the result in `active_memory` and use `current_sub_goal` to track which step you are implementing (e.g., "Step 3 of 10: Adding LoopInExcel").

Reads a recording snapshot HTML file and returns cleaned content. Use this when analyzing detailed steps from a Design Document generated by a recorder. It removes scripts and styles to focus on the DOM structure, similar to `process_error_snapshot`. Args: file_path: Absolute path to the .html file (e.g., loaded from the 'Snapshot' column). Returns: Cleaned HTML content string.

Get detailed information for a specific execution step. Use this when you need more detail on a complex step, especially steps with nested sub-steps (like loops, branches, try-catch). Args: project_path: Path to the translated project folder workflow_path: Relative path to workflow step_number: Step number (e.g., "2.3", "12.15", "8.4.1") Returns: JSON object with: - step_number: The requested step number - uipath_activity: Original UiPath activity type - display_name: Human-readable name - kofax_equivalent: Recommended Kofax step type - description: What this step does - details: Expression/value/parameter info - nested_steps: Child steps if any (for loops, branches, etc.) - found: Boolean indicating if step was found Usage: Call when implementing complex nested structures.

Get current implementation progress for a project. Use this to see what workflows are done and what's left. Helpful for resuming work after a break. Args: project_path: Path to the translated project folder Returns: JSON object with: - completed_workflows: List of finished workflows - in_progress: Currently active workflow (if any) - pending_workflows: Workflows not yet started - created_robots: Mapping of workflow -> robot file - progress_percent: Overall completion percentage

Get the UiPath to Kofax translation reference guide. This is not a definitive way to do this translation, just a general guide. This provides common mappings between UiPath activities and Kofax steps, variable type conversions, and expression syntax translations. Returns: JSON object with: - activity_mappings: Common UiPath activity -> Kofax step mappings - variable_mappings: UiPath type -> Kofax type mappings - expression_patterns: VB.NET to Kofax expression conversions - control_flow_patterns: How to translate loops, branches, try-catch - common_gotchas: Things to watch out for Usage: Keep in active_memory as "translation_guide". Reference when encountering unfamiliar patterns.

No argument schema exposed.

Get a comprehensive summary of translation completeness. USE THIS TO ITERATE, NOT WATERFALL: - See which robots have actual steps vs empty robots - See which workflow docs haven't been read yet - Identify gaps that need revisiting - Get recommendations for what to work on next Call this periodically to review progress and decide what to revisit. The goal is ONE V1 robot that orchestrates everything - check if V1 has all needed logic! Args: project_path: Path to the translated UiPath project folder kofax_library_path: Optional path to the Kofax project Library folder (to count actual steps in created robots) Returns: JSON with: - architecture_status: Is there one V1 orchestrator? How many V2s? - robot_details: List of created robots with step counts - empty_robots: Robots with 0 steps (need attention!) - unread_workflow_docs: Workflow docs that weren't used to create steps - framework_workflows: Framework workflows and their status - recommendations: What to work on next

Load the specification for V1 operations (email, file, framework). V1 specs describe operations that should be implemented in the V1 orchestrator, NOT as separate V2 robots. These include: - Email_Operations: Outlook email handling - File_Operations: File system and Excel operations - Framework_Logic: Initialization, error handling, transaction processing Args: project_path: Path to the translated project folder spec_name: Name of the V1 spec (without .md extension) e.g., "Email_Operations", "File_Operations", "Framework_Logic" Returns: JSON object with: - spec_name: Name of the V1 spec - spec_content: Full specification markdown content - found: Boolean indicating if spec was found - note: Reminder that these go in V1, not V2 Usage: Load to understand what V1 operations are needed. Implement these operations in your V1 orchestrator robot.

Load the specification for a single V2 robot. Use this to load ONE V2 robot spec at a time during Phase 3 of execution. Each spec contains the detailed steps, inputs, and outputs for that V2 robot. IMPORTANT: After using this spec to create the robot, CLEAR it from your context_keys_to_keep before loading the next V2 spec. Args: project_path: Path to the translated project folder robot_name: Name of the V2 robot (without extension) e.g., "SAP_Login", "Email_Extract" Returns: JSON object with: - robot_name: Name of the V2 robot - robot_file: Full filename (e.g., "SAP_Login.robot") - spec_content: Full specification markdown content - found: Boolean indicating if spec was found Usage: Store in active_memory as "current_v2_spec". Use to create the robot, then REMOVE from context_keys_to_keep.

Get the complete design document for a specific UiPath workflow. This provides all the information needed to recreate the workflow in Kofax: variables, execution steps with Kofax equivalents, and implementation notes. Args: project_path: Path to the translated project folder workflow_path: Relative path to workflow (e.g., "Framework/KillAllProcesses.xaml") Returns: JSON object with: - workflow_name: Name of the workflow - purpose: What this workflow does - root_activity: Type of root activity (Sequence, StateMachine, etc.) - variables: List of variables with Kofax type mappings - execution_flow: Nested steps with Kofax equivalents - sub_workflow_calls: Other workflows this one invokes - kofax_notes: Implementation guidance specific to this workflow - total_steps: Number of top-level execution steps Usage: Keep result in active_memory as "current_workflow". Track: "Step 1/12: Create Assign Variable for SystemError"

Get just the variables section for a workflow. Use this to create all robot variables before adding steps. Variables should be created first since steps reference them. Args: project_path: Path to the translated project folder workflow_path: Relative path to workflow Returns: JSON object with: - workflow_name: Name of the workflow - total_variables: Number of variables - variables: List of variable definitions with: - name: Variable name - uipath_type: Original UiPath type - kofax_equivalent: Recommended Kofax type - default_value: Default value if any - scope: Variable scope - notes: Implementation notes Usage: Track: "Variable 3/8: Creating TransactionData (Database Table)"

Load a translated UiPath project and return its structure and key context files. This is the entry point for recreating UiPath robots in Kofax. By default, it loads all key context files to give the agent a complete picture. Args: project_path: Path to the translated project folder (e.g., "uipath_translator/output/U003_NC_LOJ_ZSD0010VLPOD") load_master_doc: Whether to return the full Master Design Doc (default: True) load_process_overview: Whether to return the Process Overview (default: True) load_instructions: Whether to return the Agent Instructions (default: True) Returns: JSON object with: - project_name: Name of the project - ... (project details) - master_design_doc: Content of MASTER_DESIGN_DOC.md (if requested) - process_overview: Content of PROCESS_OVERVIEW.md (if requested) - agent_instructions: Content of AGENT_INSTRUCTIONS.md (if requested) Usage: Keep result in active_memory as "uipath_project". Use current_sub_goal to track: "Workflow 1/15: Framework/KillAllProcesses.xaml"

Record that a workflow has been fully implemented as a Kofax robot. Call this after finishing each workflow to track progress. Progress is saved to {project_folder}/_implementation_progress.json Args: project_path: Path to the translated project folder workflow_path: The completed workflow (e.g., "Framework/KillAllProcesses.xaml") robot_file: The created Kofax robot file (e.g., "KillAllProcesses.robot") Returns: Updated progress summary showing what's complete and what's next.

Mark a workflow as SKIPPED because it cannot be implemented automatically. Use this when: 1. The workflow depends on features not supported by Kofax (and waiting for manual intervention). 2. You are stuck in a loop trying to implement it. 3. You have explicitly decided to abandon this workflow. This prevents the agent from infinite looping on difficult workflows. Args: project_path: Path to the translated project folder workflow_path: The workflow to skip reason: Explanation of why it was skipped Returns: Confirmation message.

Record that work has started on a workflow. Call this when beginning implementation of a new workflow. Helps track current position for resumability. Args: project_path: Path to the translated project folder workflow_path: The workflow being started Returns: Confirmation message.

Export a Kofax project and extract it for local editing. This tool: 1. Downloads the project as .zip from Management Console 2. Archives the zip with timestamp (keeps last 10 versions) 3. Extracts to a working folder After export, robot files are ready for editing with existing tools. Use mc_import_project with the same project_code to upload changes. Args: project_code: Project name or code (e.g., "K530", "Deneme") Returns: Dictionary with: - success: bool - working_folder: Path to extracted files - archive_path: Path to archived .zip - file_count: Number of files extracted - robot_files: List of .robot files found - message: Status message - error: Error message if failed

Import a project's working folder back to Management Console. This tool: 1. Zips the working folder (from previous export) 2. Uploads to Management Console 3. Optionally replaces existing project Use this after making changes to robot files in the working folder. Args: project_code: Project name (same as used in export) delete_if_exists: If True, replace existing project (default: True) Returns: Dictionary with: - success: bool - message: Status message - error: Error message if failed

List available execution clusters for a project. IMPORTANT: Call this BEFORE creating/running a schedule! You need a valid cluster name for mc_run_schedule to work correctly. Schedules created with invalid clusters will silently fail to run. Args: project_code: Project name or code (e.g., "K530") Returns: Dictionary with: - success: bool - clusters: List of {id, name} - count: Number of clusters - error: Error message if failed

List all projects in the Kofax Management Console. Use this to discover available projects before export/import operations. Returns: Dictionary with: - success: bool - projects: List of {id, name} - count: Number of projects - error: Error message if failed

No argument schema exposed.

List all robots in a project. Use this to find robot IDs and names before syncing tokens or creating schedules. Args: project_code: Project name or code (e.g., "K530") Returns: Dictionary with: - success: bool - robots: List of {id, name, type} - count: Number of robots found - error: Error message if failed

Get or create a schedule for a robot, then run it immediately. This tool: 1. Finds the project and its main robot 2. Looks for an existing schedule by name 3. Creates a new schedule if none exists (on the specified cluster) 4. Triggers the schedule to run immediately CRITICAL: The cluster_name must match an existing cluster! Call mc_list_clusters() first if you're unsure what clusters are available. Invalid cluster names will cause the schedule to be created but NOT run. Args: project_code: Project name (e.g., "K530", "Deneme") schedule_name: Name for the schedule (auto-generated if not provided) cluster_name: Which cluster to run on (default: "Production 2") Must match an existing cluster name (case-insensitive partial match) Returns: Dictionary with: - success: bool - schedule_id: The schedule ID (existing or newly created) - schedule_triggered: Whether the run was triggered - cluster_name: The matched cluster name - message: Status message - error: Error message if failed

Sync a robot's access token to the Credentials project. IMPORTANT: Call this after importing a robot so it can authenticate with external systems. The token is stored in the centralized "Credentials" project. Args: project_code: Project name (e.g., "K530") robot_name: Specific robot name (optional, uses main robot if not provided) credential_description: Custom description for the credential entry (optional) Returns: Dictionary with: - success: bool - credential_id: ID of the credential entry - token: Masked token preview - error: Error message if failed

Abort the current batch operation entirely. Use this when: - User asks to stop the batch - A critical error occurs that affects all remaining projects - The instruction needs to be revised Args: reason: Why the batch is being aborted Returns: JSON with abort confirmation and partial progress.

Mark current project as done and advance to the next project in the batch. Call this after completing work on the current project. The tool will automatically switch project context to the next one. Args: success: Whether you successfully completed the instruction for this project notes: Optional notes about what was done or why it failed Returns: JSON with next project info or batch completion status.

Clean up old runs to free disk space. Args: project_path: Path to the project folder max_days: Remove runs older than this (default 30) max_size_mb: Remove oldest runs if total size exceeds this (default 500) Runs with errors are kept by default. Returns JSON with cleanup results.

Cleanup old runs using project_code instead of project_path.

Create a backup checkpoint (zip) of the entire project's active folder. Steps: 1. Zips contents of 'projects/[code]/active' 2. Stores in 'projects/[code]/archive/checkpoints' Args: project_code: Project identifier (e.g. "K053_NC_FNS...") description: Short note about this checkpoint

Get the current status of the active batch operation. Returns progress (X/Y projects done), current project, and lists of completed/failed/skipped projects. Returns: JSON with detailed batch status.

No argument schema exposed.

Get detailed information about a specific project. Args: project_code: The project identifier (e.g., "K053_NC_FNS_TersBakiyeRaporu") Returns JSON with full project details including paths and settings.

Get paths to artifacts (screenshots, DOM snapshots, error capture) for a run. Args: project_path: Path to the project folder run_id: The run ID Returns JSON with artifact paths.

Get run artifacts using project_code instead of project_path.

Get full details of a specific run. Args: project_path: Path to the project folder run_id: The run ID (e.g., "run_2026-01-03_143500") Returns JSON with full run log including status, artifacts, and agent actions.

Get run details using project_code instead of project_path.

List all registered projects. Returns a summary of all projects including their code, name, description, status, tags, and whether auto-trigger is enabled. Use this to see what projects are available before focusing on one.

No argument schema exposed.

List available backup checkpoints for a project.

List historical revisions of a specific file. Use this to see what past versions are available for rollback.

List accumulated errors waiting for review. Args: project_code: Filter to specific project (empty = all projects) Returns JSON with pending error entries.

List recent changes made to a specific project. Use this to review what modifications were made during batch operations. Args: project_code: The project to get changes for limit: Maximum number of changes to return (default 20) Returns: JSON with list of changes (most recent first).

List recent runs for a project. Args: project_path: Path to the project folder limit: Maximum number of runs to return Returns JSON with recent run summaries.

List recent runs for a project using project_code instead of project_path.

Log a change made to the current project for later review. Call this after making any modification to a robot file. Changes are stored in the project's changelog.json for user review. Args: change_type: Type of change (e.g., "step_modified", "step_added", "variable_added") summary: Human-readable summary (e.g., "Updated selector for login button") details: Optional JSON string with specific change details Returns: JSON with change ID. Example: tool_log_project_change("step_modified", "Fixed selector for login button", '{"step_id": "42", "before": "old", "after": "new"}')

Register a new project in the system. Args: project_code: Unique identifier (e.g., "K053_NC_FNS_TersBakiyeRaporu") display_name: Human-readable name description: Project description tags: Comma-separated list of tags mc_project_id: Management Console project ID (if known) Returns JSON with registration result.

Restore the project active folder from a checkpoint. WARNING: THIS WILL OVERWRITE THE CURRENT ACTIVE FOLDER. A safety backup is automatically created before restoration.

Restore a specific file to a previous version. The current version will be saved as a new revision before overwriting.

Search for projects by query string and/or tags. Args: query: Search string (matches name, description, project code) tags: Comma-separated list of tags to filter by Returns JSON with matching projects. Example: tool_search_projects(query="invoice", tags="SAP,FNS")

Set focus to a specific project. This loads the project's context (file summaries, settings) and makes it the "active" project for subsequent operations. Always call this before working on a specific project's files. Args: project_code: The project to focus on Returns JSON with project context summary.

Skip the current project and move to the next one in the batch. Use this when you cannot apply the instruction to the current project (e.g., project structure doesn't match expectations). Args: reason: Why the project is being skipped Returns: JSON with next project info.

Start a batch operation to apply an instruction across multiple projects. Use this when a user request mentions "all projects", "every project tagged X", or when you detect the same issue in multiple projects. Args: instruction: The high-level instruction to apply (e.g., "Update error handling") tags: Comma-separated tags to filter projects (e.g., "FNS,SAP") project_codes: Comma-separated explicit project codes (overrides tags) Returns: JSON with batch info and first project to work on. Example: tool_start_batch_operation("Fix the selector error", tags="FNS")

Update per-project settings. Args: project_code: The project to update settings_json: JSON string with settings to update Valid settings: - auto_trigger_on_error (bool): Trigger agent on error detection - auto_trigger_on_change (bool): Trigger agent on file changes - read_only (bool): Prevent modifications to project - monitor_runs (bool): Track run history - inject_screenshots (bool): Add screenshot steps to robot - inject_dom_snapshots (bool): Add DOM snapshot steps to robot Example: tool_update_project_settings("K053_...", '{"auto_trigger_on_error": true}')

Opens a robot in Kofax/Tungsten Design Studio on this machine and validates that it loads without error dialogs, then captures a screenshot of the robot graph. Use this after creating or modifying a robot to visually confirm it opens correctly in Design Studio. Sends a tungstenrpa: deep-link to the running Design Studio instance, waits for the robot's editor window, dismisses benign popups, records any error popups (license, internal error, MC connection), minimizes the side panels, and screenshots the graph canvas. Args: robot_path: Path or name of the .robot file, e.g. "Library/MyRobot.robot" or just "MyRobot.robot" (resolved against the active project's Library). wait_seconds: Max seconds to wait for the Design Studio editor window. Returns: JSON string: {status: "ok"|"error", robot, window_title, screenshot_path, error_dialogs: [...], dialog_actions: [...]} Note: If the robot file was created on disk AFTER Design Studio started (e.g. by this agent), Studio's project cache may not know it yet. In that case the tool reports a "not found / error navigating" dialog. Refresh the project's Robots folder in Design Studio once (right-click project > Robots > Refresh) and retry.

Queue a command for the mission agent loop to process on next tick.

Get mission agent-loop runtime status (pid/heartbeat/health).

Agentically create/refine mission contracts and artifact instrumentation using holistic context (design doc + robots + recent runs), then optionally validate.

Generate explicit agent instructions for robot file-writing instrumentation artifacts.

Bootstrap mission step contracts from robot structure or run artifacts. source='robot': derive contracts from step IDs in a robot file. source='run': derive contracts from run DOM snapshots. source='design_doc': derive contracts from DOM links embedded in design doc markdown.

Trigger/observe a run, then bootstrap/refine contracts from captured DOM snapshots. This is the recommended path to refresh contracts after robot changes. In manual_operator mode, first call with manual_triggered=false to get operator instructions, then call again with manual_triggered=true after manual trigger.

Configure mission runtime behavior. - execution_mode: auto_mc | manual_operator - run_artifacts_dir: optional override path to observe run_* folders - manual_operator_notes: optional operator instructions shown in manual mode

Evaluate a run against mission step contracts and detect regressions.

Generate mission report markdown under mission workspace.

Launch dedicated mission agent loop process for the selected mission.

Launch mission agent loop and immediately queue a build command driven by mission objective/design doc.

Load project-level persistent contracts and apply them to mission contracts.

Trigger/observe mission run and wait for artifacts. In manual_operator mode: - manual_triggered=False returns operator instructions and does not call MC. - manual_triggered=True starts waiting on artifact evidence (optionally with run_id_hint). Key outputs: - run_observation.dom_count / snapshot_count - expected_artifacts existence status - evaluation summary (when evaluate_run=True) - next_action hint when DOM evidence is missing

Save current mission contracts into project-level persistent contract registry.

Set/merge mission artifact expectations used for robot instrumentation guidance. expectations_json must be a JSON array with entries like: { "artifact_id": "run_status", "stage": "OBSERVE", "artifact_path": "{run_id}/run_status.json", "description": "Write current run status", "required": true, "producer_step_id": "STEP_010" }

Set or merge mission step contracts. contracts_json must be a JSON array of contract objects.

Start a mission orchestrator run and acquire single-project lock. execution_mode: - auto_mc (default): orchestrator calls MC trigger tools - manual_operator: human operator triggers runs; orchestrator only observes artifacts

Get mission status. Without mission_id, returns active mission.

Request mission agent loop stop (and optionally force terminate process).

Move mission to a new phase. Allowed phases: - INTAKE - BASELINE - BUILD - DEPLOY - OBSERVE - TUNE - COMPLETE - FAILED Returns JSON with: - success: bool - phase/status on success - error plus valid_phases on invalid phase requests

Update mission contracts, auto-derive artifact expectations, persist both registries, and return explicit WriteFile instrumentation instructions for the agent. contracts_json must be a JSON array of contract objects.