v1.0.8

• Bug fix — create_connection no longer produces connections that can never be signed in. The create body always sent connectionParameters and never connectionParameterSets, so for a connector publishing more than one authentication mode the service stored a connection with no auth mode attached. It looked fine — the tool reported "Connection created" and handed over sign-in instructions — but the portal's Fix connection then showed only the parameter form with an Update button and no consent step, so reconnecting looped forever. Field report: an Azure Key Vault connection created this way sat Unauthenticated through repeated reconnect attempts and had to be deleted and rebuilt by hand. Azure Key Vault, SQL Server and Azure Blob all publish parameter sets, so this was the general case rather than one connector's quirk. create_connection now takes parameterSet, sends the correct connectionParameterSets shape, auto-selects when a connector publishes exactly one mode, and refuses up front — naming the valid modes — rather than creating a dead connection. Connector metadata that can't be read is not treated as an error: those connectors fall back to the previous behaviour, so discovery can never become a new way for a working create to fail.
• Bug fix — list_connections ignored the environment argument. The tool validated environment, logged it, then called listConnections() with no argument, so the API always filtered on its own configured environment. Connections are environment-scoped, so the result was a confident answer about the wrong environment. Field report: list_connections({environment: <production>}) returned the DEFAULT environment's 82 connections — which read as "Jira is already connected in Production" when Production had none, and a flow migration was planned on the strength of it. The environment now reaches the API call and is validated like any other environment id; omitting it still uses the configured default. build_flow takes no environment parameter and is unaffected.
• Bug fix — validate_flow no longer reports "Unbalanced brackets" on valid index accessors. The pattern that finds bare @function() expressions ended in a greedy .*\), which backtracks to the LAST ) in the string — so anything closing after it was cut off. @variables('EinToCompany')?[outputs('Parse_EIN')] was captured as variables('EinToCompany')?[outputs('Parse_EIN') and then confidently reported as "Unbalanced brackets: missing ']'" on a flow that was valid and already deployed. A truncated capture is worse than none: it becomes a definite error about correct code. Expressions are now located by regex and terminated by a scanner that tracks paren/bracket depth, respects '' escapes inside string literals, and follows chained accessors (?['a'], .value, [0]) to the real end. Genuinely unbalanced expressions are still reported.
• Bug fix — a misspelled parameter no longer reports success while doing nothing. Tool inputs are validated with zod, which strips keys it doesn't recognize rather than rejecting them — so a parameter named slightly wrong was silently discarded and the tool cheerfully reported that it had done the work. Field report: update_flow was called with patchTrigger (the real name is trigger, and patchActions next to it makes the wrong name look right), the tool answered "Updated …", and the flow's trigger was never touched; the mistake only surfaced later when the schedule hadn't changed. Unknown top-level parameters are now rejected with an error that names the likely intended parameter ('patchTrigger' (did you mean 'trigger'?)) and lists the valid ones. Checked against each tool's published JSON Schema, so it needs no per-tool upkeep; nested objects — fields, data, a flow's trigger and actions — stay deliberately open-ended and are not policed.
• Bug fix — get_run_actions now surfaces the real error on failed actions. The platform's run-action records carry an error object for skipped actions (the runAfter noise) but leave it null for many genuine connector failures — so the one action that actually failed reported error: null while the AI had to dig the real 400 out of the raw outputs. Failed actions with no platform error now derive one from the already-fetched outputs ([HTTP 400] …the vendor's actual message…), platform-provided errors are untouched, and the summary line now counts skipped actions separately.
• Bug fix — connector actions that take an object parameter save again. Some connector operations declare a parameter as an object rather than a string — Files.com's Move File or Folder takes a { destination } body, for example. When such a parameter contained an expression, the rewrite that keeps expressions out of object payloads emitted string interpolation (@{json(...)}), whose result is a String. Power Automate type-checks connector parameters against the connector's definition when the flow is saved, so it refused the flow outright: "Input parameter 'body' validation failed … type/format 'String' is not convertible to type/format 'Object'." Connector parameters now use the bare @json(...) form, which keeps the declared object type while still being the single expression that avoids object-level evaluation at save time. HTTP action bodies are untouched, and the runtime JSON-escaping of every substituted value is unchanged.