Skip to main content
Glama
jgt87

Copilot Studio MCP

by jgt87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Scaffold a cloud flow (experimental)

cs_add_flow

Generate a Copilot Studio flow with an agent-call trigger and response; preview metadata.yaml and workflow.json, then confirm to write and optionally expose as a tool.

Instructions

EXPERIMENTAL: write workflows//metadata.yaml + workflow.json for a flow with the 'when an agent calls the flow' trigger and a response, optionally exposing it as a tool. Format follows the schema's CloudFlowDefinition and the Power Automate solution JSON; verify with cs_pack and in the portal after push. The first call changes nothing: it returns the files it would write, as a diff against what is there now, for the user to approve. Call it again with the same arguments plus confirm: true to write them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
inputsNo
actionsNoExtra Power Automate actions (name -> definition) inserted before the response
addToolNoAlso create actions/<name>.mcs.yml invoking this flow
confirmNoRequired to write the change to the file. Without it the tool returns a preview - the changed lines against the current ones, and the character count - and writes nothing.
outputsNo
overwriteNo
workspaceNoPath to (or inside) the agent workspace. Defaults to CPS_WORKSPACE or the current directory.
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.8
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / actions / propertyNames
      Added value: +{
+  "type": "string"
+}
    • removedInput schema / properties / inputs / items / additionalProperties
      Removed value: -false
    • removedInput schema / properties / outputs / items / additionalProperties
      Removed value: -false
  2. Changed1 schema field changedv0.1.7
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Required to write the change to the file. Without it the tool returns a preview - the changed lines against the current ones, and the character count - and writes nothing.",
+  "type": "boolean"
+}
  3. First observedv0.1.5

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well on the highest-risk trait: it states that the first call is non-mutating and returns a diff for approval, and that confirm: true is required to actually write. It still omits overwrite/collision behavior and whether existing files are destroyed, so it is not fully transparent for a write tool.

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 EXPERIMENTAL marker and the concrete artifacts written, then the confirmation protocol. Four dense sentences with little waste, though the confirm explanation partially restates the schema's own confirm description.

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 9-parameter write tool with nested objects and no output schema, the description usefully describes the preview return shape ('the files it would write, as a diff against what is there now'), which the schema cannot convey. Remaining gaps are overwrite semantics and the meaning of several parameters.

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 description coverage is only 44%, so the description must compensate. It clarifies confirm and addTool (both already documented in the schema) and implies outputs via 'a response', but name, inputs, actions, overwrite, workspace, and description get no added meaning beyond the schema, leaving a real gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb and resource: it names the exact artifacts it writes (workflows/<Name>/metadata.yaml + workflow.json) and the trigger it scaffolds ('when an agent calls the flow'). However it never distinguishes itself from close siblings such as cs_create_flow, cs_build_flow_definition, or cs_add_tool, so an agent cannot route between them from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives post-conditions for use (verify with cs_pack and in the portal after push) and explains the two-step preview/confirm invocation, which is genuine usage guidance. But there is no statement of when to prefer this over cs_create_flow or cs_build_flow_definition, and no prerequisites (workspace, auth profile) are mentioned.

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