Skip to main content
Glama
Sign In

Power Automate MCP Server by Flow Studio

by io.github.ninihen1
OverviewDiscussionsAdmin

Resolve action inputs

resolve_live_parameters
Read-only

Resolve a connector action's inputs the way the flow designer does: dropdown options, list and table columns, folder and file pickers — every input in one call, or one with parameterName. Reads only: it runs the lookups the designer runs, never an action. Pass values you have in parameters; pass a display name in match to get back the value to write into the flow. An input whose parent is not known yet has status "needs". Inputs inside an object are addressed by key (body/recipient/groupId). Omit connectionName and one is chosen.

Input Schema

NameRequiredDescriptionDefault
topNoMax options per dropdown (default 200). A longer list is marked truncated.
skipNoOptions to skip, to page through a truncated list (use nextSkip).
matchNoExact display name, or the value itself, per input, e.g. { "folderPath": "Inbox" }. Case-insensitive, never fuzzy. Folders also take /path. matchCount 0 answers status "nomatch".
browseNoOpen a folder: { "field": "<input>", "id": "<folder value>" }.
detailNoColumn detail. Default compact.
searchNoNarrow long option or column lists by name (a filter, not a pick).
apiNameNoAlias for connectorName.
includeNoAdd "outputs" to get the fields this action returns.
flowNameNoWith actionName: take the connector, operation and connection from this flow action.
actionNameNoAction (or trigger) name in flowName.
parametersNoValues already chosen, e.g. { "dataset": "<site url>" }.
operationIdNoOperation ID, e.g. PostItem. Not needed with flowName + actionName.
connectorNameNoConnector name, e.g. shared_sharepointonline.
parameterNameNoResolve only this input. Omit for every input.
connectionNameNoConnection to run as. Omit to have one chosen.
environmentNameYesName of the Power Platform environment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / skip
      Added value: +{
+  "description": "Options to skip, to page through a truncated list (use nextSkip).",
+  "type": "number"
+}
  2. Changed1 schema field changed
    • removedInput schema / properties / dynamicMetadata
      Removed value: -{
-  "description": "Not needed for the operation's own inputs. For a list the connector does not describe, send its dropdown metadata; it runs through the designer's dropdown service.",
-  "type": "object"
-}
  3. Changed1 schema field changed
    • changedInput schema / properties / dynamicMetadata / description
      Previous value: -"Not needed for the operation's own inputs. For a list the connector does not describe (e.g. Dataverse ListRecords over connectionreferences), send its dropdown metadata; it runs through the designer's dropdown service."New value: +"Not needed for the operation's own inputs. For a list the connector does not describe, send its dropdown metadata; it runs through the designer's dropdown service."
  4. Changed1 schema field changed
    • changedInput schema / properties / dynamicMetadata / description
      Previous value: -"Not needed for the operation's own inputs. For a lookup the connector does not define (e.g. Dataverse ListRecords over connectionreferences) send it and it is used as given."New value: +"Not needed for the operation's own inputs. For a list the connector does not describe (e.g. Dataverse ListRecords over connectionreferences), send its dropdown metadata; it runs through the designer's dropdown service."
  5. Added

TDQS

A4.4/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, but the description adds useful behavioral context: it runs the same lookups as the designer and never runs an action. It also mentions status behavior such as needs and how an unspecified connection is chosen.

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 dense but front-loaded: the core read-only resolution behavior comes first, followed by practical usage details. Every sentence contributes useful information for a complex 16-parameter tool.

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

Completeness4/5

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

For a complex tool with no output schema, the description explains the main return concepts such as dropdown options, columns, pickers, and statuses like needs and nomatch. It is not fully exhaustive about the response shape, but it is sufficient alongside complete schema descriptions.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already documents all 16 parameters. The description still adds cross-parameter meaning, including that nested inputs are addressed by key and that omitting connectionName causes one to be chosen.

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 a specific verb and resource: it resolves a connector action's inputs the way the flow designer does. It also distinguishes the tool from actually running an action by stating it is read-only and never executes an action.

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?

It clearly explains usage modes: resolve every input in one call or a single input with parameterName, pass known values in parameters, and use match to turn a display name into a value. It does not explicitly compare against sibling tools, 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.

All Power Automate MCP Server by Flow Studio toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources