Skip to main content
Glama
jgt87

Copilot Studio MCP

by jgt87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Bind a flow's connection

cs_bind_flow_connection

Binds a flow's connection reference to a real connection so the flow can be switched on. Supports direct and solution-based flows, optional activation, and live-change confirmation.

Instructions

Point one of a flow's connection references at a real connection, which is the step that lets a flow be switched on. Picks the reference and the connection for you when there is only one of each, and asks when there is a choice. Handles both shapes: a flow that names a connection directly is edited in place, while a flow that came from a solution has its connectionreference row bound instead. Pass activate: true to turn the flow on in the same call once it is bound. Changes a live environment: requires confirm: true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
flowIdYesFlow (workflow) id (cs_list_flows)
searchNoNarrow the candidate connections by display name or owner
confirmNoRequired to actually perform a change in a live environment. Without it the tool returns a dry run.
activateNoTurn the flow on after binding; default false
clientIdNoEntra app (client) id for MSAL. Defaults to CPS_CLIENT_ID, then the first-party VS Code id.
tenantIdNoEntra tenant id. Defaults to the workspace sync metadata, then CPS_TENANT_ID.
connectorNoConnector id, e.g. shared_office365, to choose the reference by connector instead
referenceNoWhich connection reference to bind; only needed when the flow has more than one
workspaceNoPath to (or inside) the agent workspace. Defaults to CPS_WORKSPACE or the current directory.
connectionIdNoThe connection to bind (its name from cs_list_connections); default: the only usable one for this connector
dataverseUrlNoDataverse URL; default: from the workspace or the environment
environmentIdNoPower Platform environment id (GUID). Defaults to workspace sync metadata or CPS_ENVIRONMENT_ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.8
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv0.1.6

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries full burden and does well: it discloses the confirm-required live-environment change and dry-run-without-confirm behavior, the in-place vs connectionreference row dual handling, and the automatic selection behavior. It omits failure/idempotency behavior, keeping it from a 5.

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?

Front-loaded with the core purpose, then progressively adds conditional behavior. Four dense sentences each carry information, though the passage is on the longer side for a single 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 12-parameter, annotation-free mutation tool with no output schema, the description covers the essential behavioral facts an agent needs (confirm gate, dual binding shapes, auto-selection, activate). It does not describe the return value or failure modes, a modest gap.

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 coverage is 100%, so baseline is 3, but the description meaningfully augments it: it clarifies confirm as the gate for live changes (dry run otherwise), activate as the switch-on step, and describes the auto-pick logic that governs reference/connectionId/connector usage.

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?

States a specific verb (bind/point) and resource (a flow's connection reference) and frames the scope precisely: it is 'the step that lets a flow be switched on'. This clearly distinguishes it from siblings like cs_create_connection, cs_update_flow, and cs_set_flow_state.

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?

Explains the workflow context and the auto-selection rule ('picks the reference and the connection for you when there is only one of each, and asks when there is a choice'), plus the activate flow. It lacks explicit when-not or named alternatives, 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.

Deploy Server

Other Tools