Skip to main content
Glama
jgt87

Copilot Studio MCP

by jgt87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create a cloud flow

cs_create_flow

Create a Power Automate cloud flow from a step spec or ready-made definition, optionally into a solution. The flow starts disabled until connection references are bound and activated.

Instructions

Create a new Power Automate cloud flow, from a step spec (see cs_build_flow_definition: trigger plus connector, HTTP, condition, loop, variable and response steps) or from a ready-made definition, optionally straight into a solution. The flow is created switched off, because a flow can only be activated once its connection references are bound: bind them, then cs_set_flow_state on. To let an agent call it, use a trigger of type Request/kind Skills and add it as a tool with cs_add_tool type 'flow'. Changes a live environment: requires confirm: true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesFlow display name
stepsNoSteps in order; each waits for the previous one to succeed
confirmNoRequired to actually perform a change in a live environment. Without it the tool returns a dry run.
outputsNoWhat the flow answers with (agent-callable and HTTP flows)
triggerNoDefault: 'agent' (When an agent calls the flow)
clientIdNoEntra app (client) id for MSAL. Defaults to CPS_CLIENT_ID, then the first-party VS Code id.
solutionNoUnique name of the solution to create it in
tenantIdNoEntra tenant id. Defaults to the workspace sync metadata, then CPS_TENANT_ID.
workspaceNoPath to (or inside) the agent workspace. Defaults to CPS_WORKSPACE or the current directory.
clientDataNoThe whole clientdata document, when you have one (from cs_get_flow of another flow, for example)
definitionNoA ready-made Power Automate definition, instead of steps
descriptionNo
dataverseUrlNoDataverse URL; default: from the workspace or the environment
environmentIdNoPower Platform environment id (GUID). Defaults to workspace sync metadata or CPS_ENVIRONMENT_ID.
connectionReferencesNoproperties.connectionReferences, when you pass a definition rather than steps
connectionReferencePrefixNoPrefix for generated connection reference names, usually your publisher prefix

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.5

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the flow is created switched off (with the reason), that it changes a live environment and requires confirm: true, and explains the activation dependency. This is transparent about side effects and prerequisites, though it does not discuss permissions or reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences and each one contributes essential information: the core purpose, the created-off behavior with reason, the agent-callable path, and the confirmation requirement. It is well-structured, though slightly long, but appropriate given the tool's complexity.

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?

Given the tool has 16 parameters, complex nested schemas, and no output schema, the description gives a solid high-level overview and references other tools for details (cs_build_flow_definition). It covers the critical workflow steps and side effects. It does not describe return values, but the absence of an output schema makes that less critical. Overall, it is adequate for a tool of this complexity.

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

Parameters3/5

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

Schema coverage is 94%, so the schema already documents parameters in detail. The description adds context by referencing cs_build_flow_definition for the step spec and mentioning 'solution' and 'confirm', but it does not add significant semantics beyond what the schema provides. It meets the baseline for high coverage without over-delivering.

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 clearly states the tool creates a new Power Automate cloud flow, and distinguishes between two input modes (step spec or ready-made definition). It also differentiates from siblings like cs_build_flow_definition (which builds definitions) and cs_update_flow (which updates), making the purpose unambiguous.

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?

The description provides a clear workflow: create the flow off, bind connection references, then use cs_set_flow_state to activate. It also explains how to make the flow agent-callable (trigger type Request/kind Skills and cs_add_tool type 'flow'). It does not explicitly state alternatives, but the references to related tools give strong usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools