[Bug] FlowAgent connection/operation-discovery tools fail with malformed PPAPI hostname when environment is not "provisioned"

[eservicebluetree]

Plugin

power-automate

Plugin Version

2.5.0

Skill / Command

N/A — used FlowAgent MCP tools directly (pick_or_create_connection, search_operations, get_operation_details, list_connections)

Bug Description

Multiple FlowAgent MCP tools fail with a malformed PPAPI environment hostname when resolving connections/operations for an environment where resolve_environment reports "provisioned": false.

Affected tools (all fail identically):

• pick_or_create_connection (connector: shared_office365)
• search_operations (connector: shared_office365, query: "send email")
• get_operation_details (connector: shared_office365, operation: SendEmailV2)
• list_connections (connector: shared_office365)

Error returned by all of them (environment GUID redacted):

{"code":"tool-error","message":"Flow API 0 NetworkError: Network request failed: ENOTFOUND (hostname: <mangled-guid>.environment.api.powerplatform.com). This often means the environment ID produced an invalid PPAPI URL. Verify the environment ID is a valid GUID.","errorName":"FlowApiError"}

The malformed hostname pattern: the GUID's hyphens are stripped correctly (as expected for building a PPAPI subdomain), but a stray "." gets inserted two characters before the end of the string, producing an invalid, unresolvable hostname.

Diagnostic context: calling resolve_environment for this same environment returns {"environmentId":"Default-<redacted-guid>","source":"default","provisioned":false}. provisioned: false may be related to why the PPAPI host lookup falls back to constructing (and mis-constructing) a URL from the raw environment GUID instead of using a properly discovered environment instance host.

Impact: any workflow that needs to discover/search connector operations or create a brand-new connection in such an environment is blocked. Tools that don't need the PPAPI env-specific host (list_environments, list_flows, get_flow, create_flow, publish_flow, run_flow, set_current_env, set_current_flow, resolve_environment itself) all work fine against the same environment.

Workaround found: reusing an already-existing connectionReference (copied from an existing flow's properties.connectionReferences) and hand-authoring the flow definition's OpenApiConnection action lets create_flow / publish_flow / run_flow succeed normally — so the bug is isolated to the connection/operation-discovery code path's URL construction, not the core Flow API path.

Steps to Reproduce

1. Have an environment where resolve_environment reports provisioned: false.
2. Call any of: pick_or_create_connection, search_operations, get_operation_details, or list_connections, passing that environment's ID (with or without the "Default-" prefix) as env.
3. Observe the ENOTFOUND error with the malformed hostname described above.

Expected Behavior

These tools should either correctly resolve the environment's real PPAPI instance host, or surface a clear "environment not provisioned for connector discovery" error instead of an obscure DNS failure from a malformed URL.

Actual Behavior

All four tools throw a FlowApiError / ENOTFOUND with a malformed hostname, with no actionable guidance pointing at the real root cause (unprovisioned environment).

Relevant Logs / Screenshots

{"code":"tool-error","message":"Flow API 0 NetworkError: Network request failed: ENOTFOUND (hostname: <mangled-guid>.environment.api.powerplatform.com). This often means the environment ID produced an invalid PPAPI URL. Verify the environment ID is a valid GUID.","errorName":"FlowApiError"}

Environment

OS: Windows 11 Pro (10.0.26200)
Claude Code version: 2.1.232
PAC CLI version: not installed / N/A

---

🤖 This issue was created using the /report-issue skill.