feat: resolve ArgumentEmail and ArgumentGroupName recipients at runtime

[dushyant-uipath]

Summary

Updates resolve_recipient_value() in escalation_tool.py to handle the two new argument-driven recipient types added in UiPath/uipath-python PR #1521. At runtime, each type's argument_path is looked up in the agent's input kwargs using dot-notation (safe_get_nested) to produce a concrete TaskRecipient.

Also fixes create_mcp_tools_from_agent — the function was incorrectly aliased to create_mcp_tools_and_clients (which takes list[AgentMcpResourceConfig]), but callers pass a LowCodeAgentDefinition. Replaced with a proper wrapper that extracts MCP resources from the agent definition first.

Changed files

File	Change
escalation_tool.py	resolve_recipient_value accepts optional input_args; ArgumentEmailRecipient and ArgumentGroupNameRecipient handling added; call site passes tool.metadata["agent_input"]
mcp/__init__.py	create_mcp_tools_from_agent replaced with a proper wrapper (was a broken alias); extracts AgentMcpResourceConfig resources from agent definition before delegating
pyproject.toml	uipath>=2.10.44 (requires the companion PR), uipath-platform>=0.1.24

Failure modes & what was tested

The only runtime failure path

In resolve_recipient_value():

value = safe_get_nested(input_args or {}, recipient.argument_path)
if not value:
    raise ValueError(
        f"Argument '{recipient.argument_path}' has no value in agent input."
    )

This raises when:

1. The agent is invoked without the expected input argument (key missing)
2. The argument is present but empty / null

This is intentional — a misconfigured escalation should fail loudly at task creation time, not silently create a task with no assignee.

There is no feature flag in the Python layer. The flag (EnableEscalationArgumentAssignee) lives in the frontend only. If the frontend sends an ArgumentEmail/ArgumentGroupName recipient (flag is on), the Python side always processes it. The frontend strips these types from the payload when the flag is off, so the Python code never sees them in that case.

What was tested

• HC run end-to-end: agent with ArgumentEmail recipient, input arg assigneeEmail="test@example.com" → Action Center task created with correct assignee ✓
• HC run with missing argument: ValueError raised with clear message identifying the missing arg ✓
• create_mcp_tools_from_agent fixed: was crashing with 'tuple' object has no attribute 'is_enabled' because iterating a Pydantic model yields (field_name, value) tuples, not resource objects — now correctly filters isinstance(r, AgentMcpResourceConfig) ✓
• Existing AssetRecipient and StandardRecipient resolution paths unaffected ✓
• input_args=None default: all existing callers that don't pass input_args continue to work ✓

Related

• Agents repo PR: UiPath/Agents#4835
• Data model PR: feat: add ArgumentEmail and ArgumentGroupName escalation recipient types uipath-python#1521 (must merge first)
• Design doc: https://uipath.atlassian.net/wiki/spaces/BPA/pages/90469990611/Dynamic+Assignee

Test plan

• Configure escalation with ArgumentEmail recipient, argument_path="assigneeEmail", run with that input populated — verify Action Center task has correct assignee
• Same for ArgumentGroupName
• Run without the argument populated — verify ValueError with clear message
• Verify existing AssetRecipient and StandardRecipient paths unaffected
• Verify create_mcp_tools_from_agent no longer crashes when agent has MCP resources

[dianagrecu-uipath]

Please also add new tests to cover the new runtime code paths.