Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Copilot Studio MCP clone the marketing agent from the live environment into my workspace"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets a coding agent (GitHub Copilot in VS Code, Claude Code, or any other MCP client) build, test, ship and look after Microsoft Copilot Studio agents from the editor.
An agent becomes a folder of YAML you can read, diff and commit. The server writes that folder the
way the Copilot Studio VS Code extension does, syncs it with the live agent through the official
Power Platform CLI (pac), and calls the Power Platform, Dataverse, BAP, Power Automate and
DirectLine APIs for what the CLI does not cover: evaluations, chat, cloud flows, portal drift,
transcripts. Nothing reaches a live environment without your approval, and when a choice is still
open the tool asks a question instead of failing.
You want to | What happens | Read |
Stand up a new agent and get it live | create it inside a solution, generate instructions, add knowledge, topics and tools, review, validate, push, publish, talk to it | |
Change an agent that already exists | clone it to files, edit or remove components, review, merge what colleagues changed, push | |
Give the agent something to call | connector actions, MCP servers, cloud flows, AI Builder prompts, other agents, chosen from what the environment actually has | |
Know whether it works | chat with the published agent, repeatable conversation tests, evaluation runs with per-case results | |
Learn from real users | transcripts, session outcomes, escalation rate, a regression test set built from real questions | |
Not overwrite what a colleague did in the portal | see portal changes since your last sync, block a push that would collide, merge | |
Write a Power Automate flow without hand-writing Logic Apps JSON | compose a definition from steps, create the flow, bind its connections, switch it on, read its run history | |
Find out why a flow keeps failing | resolve the real error behind a failed connector action, diff the run against one that worked, and see where the failures concentrate | |
Move to test and production | pull the whole solution, map connections and variables, deploy 1:1, publish; or use a pipeline | |
Prove the stages match | snapshot each environment, compare, gate a pipeline on drift | |
Run the tenant | environments, security roles, DLP, tenant settings, backups to files, onboarding a team, the Microsoft 365 agent catalogue |
The complete tool list is in docs/tools.md and the diagrams in
docs/flows.md; both ship
inside the npm package under docs/. The reference sections at the end of this page cover the
agent settings the server can write,
authentication and permissions,
configuration, the hard limits and
how this differs from pac's own MCP server.
Related MCP server: copilot-studio-code
Early release. What has actually been exercised:
Offline: 251 unit tests over the compiled output, plus a pack oracle that round-trips every
authoring tool's YAML through pac copilot init and pac copilot pack.
Against a real tenant (2026-09-08, phases A to F of docs/live-verification.md): the
connector registry, the pac connection list layout, pac copilot clone and its sync metadata,
drift detection and the cs_push conflict refusal, and the evaluation path end to end including
the portal's CSV import format and the metric status strings. A portal-made agent validates
clean, so cs_validate produces no false positives on real content. That run also caught a real
bug: pac copilot publish prints "Failed to publish" and exits 0, so a failed publish was being
reported as a success. Fixed.
Not yet verified live: the transcript tools, cs_check_drift in quick mode, cs_chat, the
Dataverse listBots path, moving a solution between environments, and every flow the flow
builder produces (none has been imported into an environment yet).
docs/verify.md is the short list of what is still open, docs/STATUS.md the full record. Read
the dry run before confirming anything that writes.
Node.js 20+.
.NET 10 SDK and the Power Platform CLI: dotnet tool install --global Microsoft.PowerApps.CLI.Tool.
If the SDK lives in your user profile, set DOTNET_ROOT to that folder; the server defaults it
to ~/.dotnet when that folder exists.
A pac auth profile for the environment you work in, created once in a terminal:
pac auth create --environment <id or URL>. Everything that goes through pac (create, clone,
pull, push, publish, solutions, administration) uses it, with Microsoft's own first-party app.
For the API-based tools (environments, evaluations, chat, flows, drift, transcripts): an Entra
sign-in through cs_login, done from the session. By default no app registration is needed;
Authentication and app registration says when you need
one and which permissions it must carry.
The server is on npm as copilot-studio-mcp, so the usual install is no install: point your MCP
client at npx, and the first start fetches the package.
There is also a VS Code extension, vscode-extension/, which registers the server with VS Code's
MCP host and exposes the environment variables below as settings. It carries the server and its
dependencies inside the VSIX, so it needs no npm and no network on first start. Build it with
cd vscode-extension && npm install && npm run package; install the resulting .vsix with
code --install-extension copilot-studio-mcp-<version>.vsix.
VS Code, from a terminal or by hand in .vscode/mcp.json (workspace) or the user-level mcp.json:
code --add-mcp '{"name":"copilot-studio","command":"npx","args":["-y","copilot-studio-mcp"]}'{
"servers": {
"copilot-studio": {
"type": "stdio",
"command": "npx",
"args": ["-y", "copilot-studio-mcp"],
"env": { "CPS_WORKSPACE": "${workspaceFolder}" }
}
}
}Claude Code (user scope):
claude mcp add-json copilot-studio '{"type":"stdio","command":"npx","args":["-y","copilot-studio-mcp"]}' --scope userMistral Vibe, in ~/.vibe/config.toml (or $VIBE_HOME/config.toml; a ./.vibe/config.toml in
the working folder takes precedence). Vibe gives a server 10 seconds to start by default, which a
first npx fetch on a corporate network can exceed, so install globally and run the entry point
with node (find the folder with npm root -g). On Windows, keep paths in single quotes: TOML
reads backslashes inside double quotes as escapes, and "C:\Users\..." is not valid TOML.
[[mcp_servers]]
name = "copilot-studio"
transport = "stdio"
command = "node"
args = ['C:\Users\<you>\AppData\Roaming\npm\node_modules\copilot-studio-mcp\dist\index.js']
startup_timeout_sec = 60 # default 10
tool_timeout_sec = 300 # default 60; solution exports and evaluation runs take longernpm install -g copilot-studio-mcp with "command": "copilot-studio-mcp" avoids the npx start-up
cost. The server is published to the MCP Registry as io.github.jgt87/copilot-studio-mcp, which is
what VS Code's MCP gallery (Extensions view, search @mcp) draws from through the GitHub MCP
Registry. To run from a clone instead, see Development.
Environment variables are optional and listed under Configuration.
cs_init. Reports pac and .NET, the pac profiles and which one is active, the MSAL sign-in,
the write policy in force, the workspace it found and the next steps for it. It also returns a
menu of tool presets; on a smaller model pick one (see
Running on a smaller model).
cs_login when a cloud tool needs it. The call opens the browser from the server and returns
within 15 seconds; if the sign-in has not finished by then it returns status: pending with the
URL so you can open it yourself, and the next cloud call (or cs_login_status) picks the token
up. That is what makes sign-in work from clients that cap tool-call duration or run the server
where no browser can be launched. Device code (mode: device_code) is the alternative where the
tenant allows it; many block it by Conditional Access policy.
cs_guide <topic> when you want the walkthrough for one job rather than inventing a
sequence: getting-started, instructions, knowledge, tools, topics, evaluations,
publish-and-test, drift, transcripts, solutions, administration, troubleshooting.
Each names the tool per step, the portal steps that cannot be automated, and the next steps for
your workspace. Six MCP prompts (new agent, add knowledge, add tool, write instructions, review
and push, check drift) wrap the same walkthroughs in clients that show prompts as commands.
The server never changes a live Copilot Studio environment on its own. Every tool that can
(cs_push, cs_publish, cs_run_evaluation, cs_import_solution, cs_deploy_solution,
cs_create_agent with an environment, the delete tools, the flow and admin tools that write, and
the environment-changing pac wrappers) returns a dry run describing what it would do, and does
nothing else, until it is called again with confirm: true. The calling agent is instructed, in the
MCP handshake, to show that dry run and pass confirm only after you agree; one approval covers one
call.
Changing the agent on disk asks the same way, for the same reason: an edit you did not intend is
cheap to make and expensive to notice. cs_add_topic, cs_add_knowledge_source, cs_add_tool,
cs_add_flow, cs_add_trigger, cs_add_variable, cs_edit_topic, cs_edit_tool,
cs_edit_knowledge, cs_update_settings, cs_update_agent and cs_generate_instructions write
nothing on the first call. They return the change instead - a file that would be created shown in
full, a file that would be edited shown as a diff against what is there now - and write it when the
same call is repeated with confirm: true. Reviewing, validating and describing read only, and ask
nothing.
The prose fields get their own accounting, because they are the change a diff alone does not
settle: the preview carries the character count and how much of the product's limit is left, and an
edit that would exceed it is refused outright rather than failing at push time. The limits are not
the same - instructions holds 8000 characters, and the Settings > Responses > "Response
formatting" box (responseInstructions) only 500.
For a hard lock, set CPS_READ_ONLY=1 in the server's environment: the environment-changing tools
are then not registered at all, so no confirmation can reach the environment, while authoring,
validation, review and the read-only tools keep working. cs_init reports the mode and which tools
are withheld. test/policy.test.js fails if a tool that declares confirm is missing from that
list, so the two layers cannot drift apart.
Three more behaviours you will meet in every workflow:
A question instead of an error. When a call cannot proceed because something has not been
decided (which connector, which operation, which agent), the tool returns needsInput: true with
what it needs, why, the real choices when the server can list them, and the tool that lists more.
Nothing is written; the calling agent asks you and calls again. This works in every client,
including those without MCP elicitation.
Long calls run in the background. MCP clients cap a tool call at about a minute. Tools that
can run longer (cs_pull_solution, cs_create_auth_profile, environment provisioning, every pac
wrapper) accept background: true, return a jobId at once, and cs_job_status reports the
phases and the result from an on-disk record that survives a server restart. A tool decides
whether it may change anything before it starts a job, so the confirm contract is unaffected.
Writes are never retried. A read that fails on a transport error or a 429/5xx is retried with
backoff and honours Retry-After; a publish or an import that timed out may already have been
applied, so it is reported, not repeated.
Making agents and administering the tenant are usually different accounts. pac keeps one active authentication profile per machine, so create one profile per account and let the server switch:
pac auth create --name maker --environment <environment id or url>
pac auth create --name admin --environment <environment id or url>Or from the session: cs_create_auth_profile with name, environment and background: true,
because pac opens its own browser and waits for the sign-in (cs_job_status reports when the
profile exists). cs_list_auth_profiles shows the profiles and which is active.
Core sync and solution tools use CPS_PAC_PROFILE; admin commands and tenant backup use
CPS_ADMIN_PROFILE; every pac wrapper and cs_pac also accept an explicit profile. When the
server selects a profile it restores the previous one afterwards, and every pac call in the process
shares one queue, so multi-step operations (bootstrap, solution pull and deploy, snapshots) hold
the profile for the whole run. Other server instances and terminal pac commands are outside that
coordination. The MSAL sign-in used by the API-based tools is separate again and independent of pac.
From an empty folder to a published agent you can talk to. Each step is one tool call; the steps that change the environment show a dry run first.
Pick the environment. cs_list_environments (needs cs_login), or take the environment id
from the Copilot Studio URL.
Pick or create the solution. cs_list_solutions shows what exists; an existing solution
works as long as it is unmanaged and you use its publisher prefix. To start a solution for your
agents: cs_create_solution uniqueName=contoso_Agents publisherPrefix=contoso confirm=true.
The solution is the unit you later export and import to move the agent to test and production,
so it is worth choosing rather than letting one be created per agent.
Create the agent inside it.
cs_create_agent name="Contoso Support" publisherPrefix=contoso projectDir=./contoso-support environment=<id> solutionName=contoso_Agents confirm=true (add createSolution=true to fold
step 2 in). The server scaffolds locally with pac copilot init, packs with the solution name,
imports, then clones the live agent back so projectDir is a sync-connected workspace with the
default system topics. Without environment you get a local scaffold only, which can pack
settings, agent and topics but not knowledge, tools or flows.
Leave out publisherPrefix or projectDir and the tool asks instead of guessing, listing the
publishers in the environment (and, when you named a solution, the one prefix that solution's
publisher allows) and suggesting a folder named after the agent. The prefix is worth the
question: it becomes part of the schema name of every component the agent will ever have
(contoso_contososupport.topic.Greeting), it cannot be changed afterwards without recreating
them, and it has to match the publisher of the solution the agent lands in.
Say what the agent is for. cs_generate_instructions purpose="Answer IT questions and create ServiceNow tickets" audience="Employees" tone="Friendly, brief" boundaries=["never reset passwords"] modelName="Agent instructions" drafts the instructions with an AI Builder prompt
(cs_list_prompts shows the prompts in the environment; create a "write agent instructions"
prompt once in AI Builder if you have none). Review the draft, call again with apply=true to
write it into agent.mcs.yml; later refine=true with a changeRequest revises what is
there. Or write them yourself with cs_update_agent, which also sets response instructions and
mode, conversation history, capabilities, moderation, model and conversation starters (the
full map).
Give it something to work with. cs_add_knowledge_source for a public website, SharePoint,
a Graph connector or uploaded files; cs_add_topic for deterministic conversations built from
trigger phrases plus message, question, condition, set-variable, redirect, HTTP, flow, generative
answers (optionally scoped to named knowledge sources), adaptive card, transfer and end nodes;
cs_add_tool for anything the agent should call (the tools workflow).
cs_add_trigger and cs_add_variable cover event triggers and global variables.
Review and validate. cs_review_agent is a rules-based read of the whole workspace with a
10-point score: missing escalation or fallback, weak tool descriptions, overlapping trigger
phrases, private knowledge with no authentication, secrets in files. Each finding names the rule
and the fix. cs_validate then checks every file against the authoring schema (744 definitions)
and across files: connection references that nothing binds, catalog operations that do not
exist, redirects to topics that are not there. It also blocks on the mistakes that a push
accepts without complaint and then stores wrongly: merge-conflict markers left by a pull (the
push keeps only the text before them), leftover <AGENT_SCHEMA> placeholders, file and schema
names pac rejects, and more than 200 trigger phrases. It warns about text cut off by an
unquoted #, nodes after an end node, formulas missing their =, adaptive cards without a
submit action, and topic names with a period, which stop the solution from exporting.
Push. cs_push confirm=true is the portal's Save: the draft agent now shows your topics,
knowledge and tools. The dry run runs validation and the quick drift check first, and the push
is refused when a colleague changed the same component in the portal since your last pull.
Tools with a connection reference need one portal step: open the tool under the agent's Tools,
Connect, then cs_pull to bring the binding down.
Publish and talk to it. cs_publish confirm=true, then cs_chat utterance="my laptop is slow". The testing workflow turns that into repeatable checks.
flowchart TD
A["cs_init"] --> B["cs_list_solutions<br/>pick one, or cs_create_solution"]
B --> C["cs_create_agent<br/>environment + solutionName + confirm"]
C --> D["cs_generate_instructions<br/>AI Builder prompt, then apply"]
D --> E["cs_add_topic / cs_add_knowledge_source / cs_add_tool<br/>(cs_list_connectors, cs_describe_connector)"]
E --> R["cs_review_agent"]
R --> H["cs_validate"]
H -- errors --> E
H -- clean --> I["cs_push confirm"]
I --> J{"tool needs a connection?"}
J -- yes --> J1["portal: authorise once"] --> J2["cs_pull"] --> K
J -- no --> K["cs_publish confirm"]
K --> L["cs_chat"]GitHub Copilot harness agents (cs_create_agent with authoringMode: cli-copilot) are a smaller
surface: init, pack, import, instructions and chat. Topics and evaluations are standard-harness
features.
Most agents already exist, often made in the portal. The loop is clone, change, review, merge, push.
Clone it. cs_list_agents (through pac or Dataverse), then cs_clone_agent bot=<id or schema name> outputDir=./support-agent. The result is a sync-connected workspace with
agent.mcs.yml, settings.mcs.yml, topics/, knowledge/, actions/, trigger/,
variables/, workflows/ and the connection references. cs_describe_workspace inventories
it and ends with next steps.
Change it. Components are found by name, file stem or path. cs_edit_topic changes trigger
phrases, priority and nodes (by position or id); cs_edit_tool changes descriptions, inputs and
the connection; cs_edit_knowledge changes a site or a trigger condition;
cs_remove_component deletes a topic, knowledge source, tool, trigger or variable and prunes
the connection reference nothing else uses, noting any redirect left dangling. cs_update_agent
and cs_update_settings cover the agent's own settings. Adding works as in the new-agent flow.
Every edit keeps the file header the extension expects.
Review and merge. cs_review_agent, then cs_pull to bring down what colleagues changed in
the portal (pac's three-way merge), then cs_validate.
Push. cs_push confirm=true. If a portal change and a local edit touch the same component
the push is blocked; cs_pull resolves it, force: true overrides it.
Commit. Keep the workspace in git and commit after every pull (the tool result reminds you). Portal drift then shows up as a diff you can review: accepting it is a commit, rejecting it is a push of the local version.
Around that loop: cs_delete_agent and cs_delete_solution remove things from the environment
(confirm); cs_extract_agent_template and cs_create_agent_from_template turn one agent into a
template for more; cs_extract_translations and cs_merge_translations do the localisation round
trip (.resx or .json, with whatIf); cs_quarantine_agent takes an agent out of service and back.
Copilot Studio agents can call any connector in the environment (more than a thousand Microsoft-published ones plus custom connectors), MCP servers exposed through connectors, cloud flows, AI Builder prompts, other agents, and a few rarer kinds. The server knows the kinds from the YAML schema and the instances from the environment, which is the only source that knows what exists there.
Find the connector. cs_list_connectors search=ServiceNow lists the environment's connector
registry, the same list the portal's Add a tool shows, with MCP servers flagged. Without a
sign-in it falls back to an offline seed generated from the public connector reference (display
name to shared_ id, no operations): a starting point, not proof the connector is enabled for
you.
Find the operation. cs_describe_connector connector=shared_service-now operation=incident
turns the connector's OpenAPI definition into operations with operationId, required and
optional parameters and response fields; x-ms-agentic-protocol: mcp-streamable-1.0 marks MCP
endpoints. Definitions are cached under .cs-catalog/<environment>/ so later calls are offline.
Add the tool. cs_add_tool takes a typed spec for a connector action, an MCP server, a cloud
flow, an AI Builder prompt (cs_list_prompts shows them), a connected agent or a child agent,
and a raw type for the rest (AI plugin, Bot Framework skill, client action, computer-use
agent). With the definition cached it checks the operationId, fills the automatic inputs from
the operation's required parameters, and writes the YAML under actions/ plus a
connection-reference stub. If you have not named a connector or operation yet the call comes
back as a question with the ranked candidates.
Connect it, once, in the portal. A connection is an authorised link that only the portal can
create (the one exception is a service-principal Dataverse connection, which
cs_create_connection makes). After cs_push, open the tool under the agent's Tools, Connect,
then cs_pull. cs_validate warns about tool files whose operation is not in the cached
definition, and cs_review_agent flags tools whose description will not let the orchestrator
pick them.
A unit test compares the schema's list of tool kinds with the server's table, so a schema update
that introduces a new kind fails the build until the kind is classified. Flows as tools are either
a scaffold (cs_add_flow, experimental) or a real flow built with the
flow builder and referenced from the agent.
Publish. cs_publish confirm=true is the Publish button, through pac copilot publish or
the Dataverse PvaPublish action polled until publishedon moves.
Chat. cs_chat utterance="..." sends one utterance to the published agent and returns the
reply; pass the conversationId back for the next turn. With transport: auto the server reads
the agent's authentication mode: no-auth and manual-auth agents go through DirectLine (the token
endpoint of a published agent is anonymous, so no app is needed); an agent with integrated Entra
authentication goes through the Copilot Studio client SDK and needs your own app id with the
CopilotStudio.Copilots.Invoke scope (clientId, or CPS_CLIENT_ID).
Make it repeatable. cs_run_conversation_tests runs a YAML file of utterances and
expectations through the same chat path and reports what failed. Expectations cover the
wording and what the agent did: usedTool, notUsedTool, usedTopic, notUsedTopic and
citedKnowledge read the topic, tool and knowledge attribution from the activities, so a test
can tell a real tool call from an answer that merely reads correctly. Every result, and every
cs_chat reply, reports the observed topic, tool and citations; an expectation that cannot be
judged (no attribution in the activities) says so rather than failing the agent. The
attribution key names come from documentation and are unverified live;
docs/test-verification.md is the runbook that settles them.
Evaluate. The portal's Evaluation feature runs a test set of questions against the agent and scores each answer. The one thing its API cannot do is create the test set, so the loop is:
cs_create_test_set_csv suggestFromWorkspace=true writes the CSV in the portal's import
format (max 100 cases), seeded from your topics and knowledge.
Import it once in the portal's Evaluation tab.
cs_list_test_sets, then cs_run_evaluation confirm=true wait=true, then
cs_get_evaluation_run for per-case results with pass and fail buckets;
cs_list_evaluation_runs for the history.
flowchart TD
A["cs_create_test_set_csv"] --> B["portal: Evaluation > Import CSV"]
B --> C["cs_list_test_sets"] --> D["cs_run_evaluation confirm wait"]
D --> E["cs_get_evaluation_run"] --> F{"failures?"}
F -- yes --> G["fix topics / instructions / knowledge"] --> H["cs_push confirm"] --> D
F -- no --> I["cs_publish confirm"]Once people use the agent, the transcripts are the best source of test cases and of the questions
it cannot answer. Copilot Studio stores every session in the Dataverse conversationtranscript
table; the server reads it and never writes.
cs_list_transcripts lists sessions in a window: when, how many turns, the first question, the
topics and tools that fired, how it ended.
cs_get_transcript returns one session's full turn list with the topic and tool attributed to
each turn.
cs_summarize_transcripts aggregates a window: outcomes, escalation rate, sessions that matched
no topic, the top topics and tools, and the questions behind the failures.
cs_test_set_from_transcripts builds the Evaluation import CSV from questions people actually
asked, failures first, so the next evaluation run covers what went wrong.
Copilot Studio does not report whether a conversation succeeded. The outcome is this server's
reading of the transcript (an escalation, the agent saying it could not answer, a user turn with no
reply); resolved means nothing marked the session as failed, not that the user was satisfied.
Every result repeats that caveat, and cs_guide transcripts walks the loop from a summary to one
transcript to a regression test set. Transcripts hold what users said to the agent, so the
signed-in user needs a role that grants read on that table and results are customer data.
Unverified against a live tenant.
Makers can keep editing an agent in Copilot Studio after it was cloned; nothing stops them and the
platform sends no notification. Every portal edit lands in Dataverse rows: the bot row for
settings and instructions, and one botcomponent row per topic, knowledge source, tool, trigger
and variable, each with a modified-on stamp and the user who changed it. The server uses those rows
to see drift without a re-scan, and a clone to confirm it when the details matter.
Sync stamp. cs_clone_agent, cs_pull, cs_push and cs_create_agent (with
environment) write .mcs/cs-sync.json: a fingerprint of every workspace file and, when a
Dataverse sign-in is cached, the modified-on stamp of every component. cs_describe_workspace
shows the last sync.
Quick check. cs_check_drift (default mode: quick) reads the bot row and its component
rows and compares them with the stamp: which components were modified, added or removed in the
portal, by whom and when, whether the agent settings changed, and whether the live agent has
unpublished changes. Each component is mapped to its workspace file; when that file also changed
locally the entry is a conflict. Seconds, no pac; needs cs_login.
Full check. cs_check_drift mode=full runs pac copilot clone into a temporary folder and
classifies every file three ways against the stamp: local-modified, remote-modified,
both-modified (conflict), added or deleted on either side, with unified diffs. Use it when the
quick check reports drift and you want the exact content, or when there is no Dataverse sign-in
(only the pac profile is needed). Uploaded knowledge files are covered here, not in the quick
check.
Push preflight. The cs_push dry run includes the quick check, so the caller sees "three
components changed in Copilot Studio since your last pull" before confirming. With confirm,
the push is blocked when a portal change and a local edit touch the same component; cs_pull
(pac's three-way merge) resolves it and force: true overrides it.
Git as the ledger. Commit after every cs_pull; cs_check_drift reports whether the
workspace is in a repository and how many of its files are uncommitted.
Limits. The quick check does not see connections (a maker connecting a tool is expected, and
connection ids are ignored in every comparison), uploaded knowledge files, channel configuration or
the security group. When the stamp has no per-component baseline (no Dataverse sign-in at sync
time) it falls back to the sync time with a two-minute margin, so edits made right after a sync
count as the sync itself. The component query has not been verified against a live environment
yet; see docs/STATUS.md.
Flows are built from a step spec, the way topics are, so you do not have to write Logic Apps JSON
by hand. cs_build_flow_definition composes the definition locally and returns it together with
the connection references it needs; cs_create_flow takes the same spec and creates the flow in an
environment or a solution; cs_update_flow takes it and replaces the definition of an existing
unmanaged flow, keeping its connection references.
A spec is a trigger plus steps that run in order:
Trigger | For |
| the flow a Copilot Studio agent calls as a tool, with typed inputs and a response |
| started by a person or by an HTTP request |
| a schedule |
| a connector event, such as a Dataverse row being created |
| any other trigger, written verbatim |
Step | Emits |
| a connector operation ( |
| an HTTP call |
| branching, looping and grouping, with their own nested steps |
| variables and intermediate values |
| end the run with a status |
| what an agent-callable or HTTP flow answers with (added automatically when you give |
| any other action, written verbatim |
The builder chains runAfter so each step waits for the previous one, normalises action names the
way Power Automate does, and collects one connection reference per connector used, reusing it
across steps. Expressions are Logic Apps expressions, not Power Fx: @{triggerBody()?['orderId']},
@body('List_rows')?['value']. Connector ids and operation ids come from cs_list_connectors and
cs_describe_connector; an operation's parameters are exactly the parameters of a connector
step.
Around the builder: cs_list_flows shows the flows in the environment with state, owner and
connection references; cs_get_flow returns one with its full definition; cs_delete_flow removes
one for good; cs_list_flow_runs, cs_get_flow_run and cs_run_flow read the run history and
start a manual run through the Power Automate service (a separate sign-in, cs_login scope='flow';
the signed-in user must own or co-own the flow).
Bind the connections. A connection reference names a connector; a connection is one person's
authorised account for it, and until the two are joined the flow cannot run. cs_bind_flow_connection
joins them: with one reference and one usable connection it needs nothing but the flow id, and it
asks which when there is a choice. It writes whichever of the two shapes the flow uses - a flow
built outside a solution names its connection directly, while one that arrived in a solution points
at a connectionreference row - and activate: true turns the flow on in the same call.
cs_set_flow_state turns one on by itself once it is bound.
Work out why a run failed. The run list says a run failed and nothing more.
Tool | Answers |
| Why did this run fail? A failed connector action carries no error message of its own - the message is in the action's outputs, behind a link that expires after a few days - so this fetches it, says whether the fault is the connector, an expression or a timeout, and shows the inputs the action was called with next to the outputs of the actions that ran just before it. |
| It worked yesterday. Diffs the failed run against the most recent successful one and names the action where they part company. With |
| It fails sometimes. Failure rate, duration median and 90th percentile, and which actions the failures land on. One action responsible for most of them is a broken step; failures spread across many point at the connection, throttling or the system being called. |
A trigger that failed means the flow never ran at all, so the fault is in the trigger's connection or its parameters rather than the logic. Run detail ages out: inputs and outputs are kept for a limited time, so diagnose a failure while it is recent.
Two things the builder cannot do for you. The connections themselves must exist in the target environment before anything can be bound to them, which is why a new flow is created switched off. And the definitions follow the Logic Apps schema and exported solutions rather than a verified round trip, so import one and open it in Power Automate before trusting the shape.
Per-agent sync stays bound to the environment the agent came from. Moving to test or production is a solution export and import, and the server makes that a pull, a settings file and a deploy.
See what you are moving. cs_list_solutions, then cs_describe_solution exports, unpacks
and inventories: agents, bot components, flows, connection references, environment variables,
custom connectors.
Pull it. cs_pull_solution exports the solution unmanaged and managed, unpacks it to
src/, writes solution.json (the manifest the deploy reads), creates
deployment-settings.json and clones every agent into agents/. A full pull runs for minutes,
so pass background: true and follow it with cs_job_status; the outcome also lands in
pull-job.json in the target directory.
Map the target. cs_list_connections on the target environment shows the connections that
exist there; cs_create_deployment_settings maps each connection reference to one of them, sets
the environment variable values for the target and, per agent, the Entra security group that may
use it.
Deploy. cs_deploy_solution confirm=true imports into the target with the settings file and
runs pac copilot publish on every agent (publishAgents, default on). It refuses to import
while any connection reference is unmapped unless you pass allowUnmapped: true. If you edited
src/ by hand, cs_pack_solution first.
Quality gates and alternatives on the same path: cs_check_solution runs Solution Checker before a
deploy; cs_set_solution_version, cs_solution_online_version and cs_upgrade_solution handle
release numbering and staged upgrades; cs_publish_customizations publishes everything in an
environment; cs_list_pipelines and cs_deploy_pipeline use Power Platform pipelines instead of
a direct import; cs_init_solution_project, cs_clone_solution, cs_sync_solution,
cs_add_solution_reference and cs_add_solution_license keep a source-controlled solution
project (.cdsproj); cs_add_solution_component adds an existing component to a solution.
Plan for these before calling the copy "1:1":
Connections are not part of a solution. A solution carries connection references; the
connections themselves (the authorised links to SharePoint, Outlook, Dataverse, MCP servers, ...)
must already exist in the target environment, created and consented by a user there.
cs_create_connection is the one exception and only covers service-principal Dataverse
connections. With allowUnmapped: true the tools stay unbound until someone binds them in the
target portal.
Cloud flows land switched off when their connection references cannot be resolved. Bind the
connections, then cs_list_flows shows which are not activated and cs_set_flow_state switches
each on; the portal is not needed for that step.
Environment variables need target values. The settings file lists every variable; leave a value empty and the target inherits the default from the solution, which is usually a dev value.
Who can use the agent is per environment. The settings file has a CopilotAgents section
with an AadGroupId per agent (verified with pac 2.11.2). Map it to the target's Entra group
(copilotAgents in cs_create_deployment_settings) or set access in the target portal after
import; an all-zero id means no group is set.
Some agent content lives outside the solution. Uploaded knowledge files, Dataverse tables used as knowledge, SharePoint permissions, and channel configuration (Teams, web, Microsoft 365 Copilot) are environment-specific. After import, check knowledge sources and re-publish to channels in the target portal.
Managed vs unmanaged. cs_pull_solution exports both. Deploy managed for downstream
environments and keep unmanaged only for development; a managed import cannot be edited in place
in the target.
Per-agent sync does not cross environments. Workspaces from cs_clone_agent or
cs_pull_solution push back to their source environment only. Edit the agents/<name>
workspace, push to the source, then pull and deploy the solution again.
When the same solution is promoted through development, test, acceptance and production, the question is whether each stage still holds what the previous one holds. The platform has no cross-environment diff, but every input is reachable, so the server captures each environment into a snapshot folder and compares snapshots offline.
Snapshot each stage with cs_snapshot_environment (or all at once with
cs_compare_environments, which takes an ordered chain and compares each adjacent pair). A
snapshot folder contains:
snapshots/TEST/
snapshot.json label, environment, time, solution version and managed flag,
agents with publish state, flows, connection references,
environment variables, notes
agents/<Agent name>/ the agent as YAML, from pac copilot cloneAgents are cloned rather than exported as a solution, because a managed solution cannot be
exported from test or production. Flows, connection references, environment variables and
publish state come from Dataverse and are included when you are signed in with cs_login;
otherwise the snapshot notes that they were skipped.
Compare adjacent stages with cs_compare_snapshots (DEV vs TEST, TEST vs ACC, ACC vs PROD).
Each comparison writes <A>-vs-<B>.md and .json.
Read the verdict. A report starts with DRIFT or no drift, then lists the drift, the
expected differences, and tables per layer with unified diffs for changed agent files.
Act on it. Drift in agent YAML means the later stage is behind or was edited in place: promote again with the solution flow above. Unbound connection references, missing flows, or variables without a value are deployment-settings problems: fix the settings file and redeploy.
Keep history. Snapshot folders are plain files; commit them (without .mcs/ state) to get
a timeline per stage.
What counts as drift, and what is an expected difference between stages:
Layer | Drift | Expected difference (reported, not drift) |
Solution | version differs, missing in a stage | managed in later stages, unmanaged in development |
Agent YAML (topics, instructions, knowledge, tools, triggers, variables) | any changed, added or removed file after normalisation | ids, audit info, version fields, connection ids inside |
Publish state | modified after last publish in any stage (unpublished changes) | |
Flows | missing in a stage, on/off state differs | |
Connection references | missing, connector differs, unbound in a stage | bound to a different connection per stage |
Environment variables | missing, no value in a stage | different values per stage (drift only with |
Authentication mode | differs between stages |
Pipeline gate. cs_compare_snapshots and cs_compare_environments accept failOnDrift; the
tool result is then an error, which a scripted MCP client or a pipeline step can turn into a failed
job. A typical gate before promoting TEST to ACC:
cs_snapshot_environment label=TEST environment=<test id> dir=snapshots/TEST solution=<name>
cs_snapshot_environment label=ACC environment=<acc id> dir=snapshots/ACC solution=<name>
cs_compare_snapshots a=snapshots/TEST b=snapshots/ACC failOnDrift=trueCaveats: all stages must be reachable from the active pac auth profile (for chains that span
tenants, run pac auth select between stages and snapshot them one by one); whether
pac copilot clone succeeds on a managed agent is unverified live (the fallback is reading the same
component definitions through the Dataverse Web API); uploaded knowledge files and channel
configuration are listed by name and size only; without a Dataverse sign-in the comparison covers
solution version and agent YAML only, and the report says so.
Administration runs as the admin account (two accounts): pass
profile, or set CPS_ADMIN_PROFILE once. Every change goes through the same dry run and
confirm; reset, delete, copy and restore destroy or overwrite whole environments, and the dry run
says what will be lost.
Back the configuration up to files. cs_backup_tenant writes the whole tenant configuration
to a folder: tenant settings, environments, DLP policies, environment groups, service principals,
registered applications, templates, and per environment its details, solutions, agents,
connections, security roles and platform backups. Raw output is kept next to parsed rows, and a
capture that fails is isolated so the rest of the backup still lands.
Read and change the tenant. Environments and their operations in progress, tenant settings
(read to a JSON file, change one), DLP policies (which connectors may be combined), environment
groups, security roles, service principals and registered applications, managed-environment
governance, administration mode and backup retention, and the environment lifecycle: create,
copy, back up, restore, reset, delete. Each is one cs_admin_* tool
(list).
Onboard a team into a new environment. cs_admin_create_environment (slow; pair it with
background: true and cs_job_status), then cs_admin_assign_users with a CSV:
UPN,Security Roles,Business Unit
alice@contoso.com,"System Customizer,Basic User",Sales
bob@contoso.com,Environment Maker,pac takes one user and one role per call, so that roster is five calls; the tool expands it,
shows you every user-and-role pair in the dry run, and runs them under one approval. Rows are
independent, so a mistyped UPN is reported and the rest still run. Prefer
cs_admin_assign_group when the roster is really a group: binding an Entra group to a role is
one call however many people are in it, and new joiners inherit access. Role names are
per-environment (cs_admin_list_security_roles against the new one), and a user who has not
been provisioned into the environment yet cannot hold a role there.
The Microsoft 365 agent catalogue. cs_list_agents reads one environment's bots table and
stops at the Power Platform boundary. The catalogue (Microsoft Graph, a separate sign-in with
cs_login scope='graph') is tenant-wide and answers the question that follows cs_publish: did
the agent actually reach anyone? cs_list_org_agents reports who each agent is available to,
where it is deployed and whether it is blocked, filtered by platform, host, element type or
last-modified date; cs_get_org_agent returns one entry in full; cs_block_org_agent blocks an
agent for everyone in the tenant or lifts the block, and cs_reassign_org_agent hands it to a
new owner when the old one leaves (both confirm). Needs a Microsoft Agent 365 licence, is
global-cloud only, is unverified against a live tenant, and block and reassign exist only on
Graph beta.
Every pac command without a tool of its own is reachable through cs_pac: read-only commands run
immediately, the others return a dry run and need confirm. The pac groups outside Copilot Studio
work (application, canvas, catalog, code, data, managed-identity, model, modelbuilder, package,
pages, pcf, plugin, power-fx, telemetry, test, tool) are deliberately left there.
An agent's settings live in two files, and the server reads, validates and pushes both. The table
maps what the portal shows to the field and the tool argument that writes it. Everything here is a
local file change, shown before it is made and written only with confirm: true; cs_push applies
it, and cs_publish makes it live. instructions is capped at 8000 characters by the product, and
the preview counts them.
agent.mcs.yml (the agent definition), written by cs_update_agent:
Portal | Field | Argument |
Instructions |
|
|
Responses: how answers are worded and formatted ("Response formatting") |
|
|
Responses: response mode |
|
|
Conversation history the agent sees |
|
|
Capabilities: web browsing, code interpreter, image generation, Teams / SharePoint / email / meeting / people search |
|
|
General knowledge: may the model answer beyond your knowledge sources |
|
|
Content moderation |
|
|
File analysis, semantic search |
|
|
Model |
|
|
Conversation starters |
|
|
Display name |
|
|
Values are checked against the authoring schema, so a response mode or moderation level outside the allowed set is refused rather than written.
settings.mcs.yml (how the agent runs), written by cs_update_settings with dot paths, for
example {"configuration.settings.GenerativeActionsEnabled": true}:
Portal | Path |
Generative orchestration on or off |
|
Authentication |
|
Language |
|
Agent can be called by other agents |
|
Analytics, telephony, voice, network |
|
cs_update_settings refuses to change authoringModel, recognizer.kind and template,
because the tooling depends on them. cs_lookup_schema shows any other field the schema allows,
and cs_validate checks whatever you write by hand.
One caveat: these field names come from the authoring schema, not from a round trip through a live
agent, so which portal control maps to which field is inference. Set one in the portal, run
cs_clone_agent and compare if you need certainty.
The server signs users in with an MSAL public client (interactive browser or device code). It
never uses client secrets, so every permission it needs is a delegated permission acting as the
signed-in user. Application permissions are listed below only where Microsoft offers them, for
people who build a headless pipeline on top of the same APIs. How cs_login behaves inside an MCP
client is described under The first session.
Do you need your own app registration?
Situation | App registration needed? |
| No. |
Cloud tools with the default client id ( | No. The server uses the first-party VS Code client id |
Same tools, but your tenant blocks that id (app consent policy, conditional access, "user assignment required") | Yes. Create the registration below and set |
| Yes, always. The first-party id does not carry |
Headless CI (service principal, no user) | Not supported by this server today (public client only). For pipelines use |
Permissions for your own app registration (Entra ID > App registrations > API permissions > "APIs my organization uses"):
Used by | API to pick in Entra | Permission | Delegated or application | Notes |
| Power Platform API (app id |
| Delegated is what this server uses. An application permission of the same name exists for confidential clients (Microsoft 365 Agents SDK); not used here. | Admin consent is normally required. Redirect URI |
| Power Platform API | Token scope | Delegated only. Power Platform API has no application permissions; service principals get access through RBAC roles instead. | Verified with the first-party id by Microsoft's own tooling. Not yet verified with a custom registration; if calls return 403, the signed-in user needs maker access to the agent. |
| PowerApps Service (app id |
| Delegated. | Calls the BAP environments API ( |
| Dynamics CRM (Dataverse, app id |
| Delegated. There is no application permission; server-to-server access to Dataverse means an application user with a security role in each environment. | The user still needs a Dataverse security role that can read and publish bots (System Customizer or a Copilot Studio maker role). The drift checks only read the |
| Microsoft Flow (Power Automate service, app id |
| Delegated. | A separate resource from Dataverse and the Power Platform API, so it needs its own consent: sign in with |
| Microsoft Graph (app id |
| Delegated is what this server uses; an application permission of the same name exists for reads. | The Microsoft 365 agent catalogue, a different resource again: sign in with |
| Microsoft Graph |
| Delegated only. Microsoft offers no application permission for these two actions. | Same licence and cloud limits as above; sign in with |
| Power Platform API | Token scope | Delegated only. | Same resource as the evaluations. Consent bypass is an admin setting on the agent, so the write (and possibly the read) needs a Power Platform or Copilot Studio admin role; the manifest download needs maker access and an agent published to the Microsoft 365 / Teams channel. All three follow the published reference and are unverified against a live tenant. |
| none | none | not applicable | The DirectLine token endpoint of a published agent is anonymous. |
| none | none | not applicable | Microsoft's own app; |
Steps for your own registration:
Entra ID > App registrations > New registration. Single tenant. Under Authentication add the
platform Mobile and desktop applications with redirect URI http://localhost (the loopback
MSAL uses for cs_login interactive). Set Allow public client flows to Yes if you plan to use
cs_login with mode: device_code.
Add the permissions from the table. If Power Platform API does not appear when you search
by name or by the id above, its service principal is missing from your tenant; create it with
az ad sp create --id 8578e004-a5c6-46e7-913e-12f58912df43 (or
New-MgServicePrincipal -AppId 8578e004-a5c6-46e7-913e-12f58912df43) and search again.
Grant admin consent for the tenant, or let each user consent interactively on first sign-in.
Put the ids in the MCP server environment: CPS_CLIENT_ID=<application (client) id> and
CPS_TENANT_ID=<directory (tenant) id>. cs_chat also accepts clientId per call.
All environment variables are optional:
Variable | What it does |
| the agent workspace to start in (VS Code: |
| the Entra tenant and app registration for |
| defaults for cloud tools when the workspace carries no sync metadata; explicit arguments win, then workspace metadata, then these, then a BAP lookup |
| the pac auth profile for maker commands and for admin commands (two accounts) |
| withhold every environment-changing tool (approval) |
| trim the tool list: presets and comma-separated names with |
| override the token scopes for the Power Automate service and Microsoft Graph |
| token cache location, the pac executable, the .NET root |
The full tool list is 148 tools, about 50k tokens of schema before any work starts. A frontier
model copes; a smaller one spends most of its context on the menu and chooses worse from it. Set
CPS_TOOLS to a preset in the server's environment, or let the user choose during the session:
cs_init returns a toolPresets block with the question, the option table and a live count per
preset, and cs_set_tool_preset applies the answer.
Preset | Tools | When to use it |
| 148 | everything; a large model, or you do not know yet what the task needs |
| 34 | build or change one agent and get it live: the usual choice |
| 25 | write and check files only; no sign-in, nothing reaches an environment |
| 49 | tenant administration as the admin account, plus |
| 25 | pull, deploy and compare solutions, and bind the flows an import left switched off |
Nothing is removed: a preset only changes which tools are offered, and cs_init, cs_guide,
cs_set_tool_preset and cs_job_status survive every preset so a session can always change its
mind. cs_pac is in core, admin and solutions so any pac command a preset hides is still
reachable, and cs_init says that a missing tool is hidden rather than absent. Presets compose
with each other and with globs: CPS_TOOLS=core,cs_admin_*, or
CPS_TOOLS_EXCLUDE=cs_*_pipeline,cs_env_*,cs_*_auth_profile. The SDK sends
notifications/tools/list_changed on a switch, so a client that honours it sees the shorter list
at once; one that caches the list needs a restart. Runtime switching can only narrow what was
registered at startup, so leave CPS_TOOLS unset if you want every preset available to choose
from.
A tool list this long is a routing problem: the descriptions decide whether "why did my flow fail
last night?" reaches cs_explain_flow_run or something that answers a different question. The
package ships the check, so you can measure it against your own preset, your own model and your
own phrasings rather than trusting the numbers here:
npx copilot-studio-mcp-routing-eval --dry-run # free: shows the corpus and the cost
npx copilot-studio-mcp-routing-eval --preset core --repeat 3 --yes
npx copilot-studio-mcp-routing-eval --cases ./my-questions.json --yesIt puts the tool list in front of a model exactly as your client sees it, one utterance at a time,
and scores the first tool named. --cases takes your own file in the shape of the bundled
reference/routing-cases.json, which is rather the point: the questions your users actually ask
are better evidence than the ones shipped here. With ANTHROPIC_API_KEY set it calls the Messages
API with the tool list as a cached prefix and a run costs cents; without one it falls back to the
claude CLI and the sign-in that machine already has. Either way a run calls a model once per
case and spends real money, so nothing happens without --yes.
Read it with --repeat 3, never a single run. Measured on Haiku 4.5, the score moves by two
cases between runs of an identical build, and a third of the cases answer differently each time.
One run will happily tell you a change helped when it did not. The report separates the cases that
are always misrouted, which are worth acting on, from the ones that flap, which prove nothing.
The handshake instructions are written for a smaller model: one rule per line, an explicit trigger before each instruction, and a section naming the failures seen in the first live run (a call cut off at the client's ~60s limit, a tool missing because the server binary was stale, a cloud tool failing for want of a sign-in, pac reporting failure while exiting 0) with the action for each.
Capability | How | Status |
Agent as files, sync both ways |
| official, GA |
Topics, knowledge, tools, triggers, flows as YAML | workspace layout of the VS Code extension and | official |
Local validation | JSON schema from microsoft/skills-for-copilot-studio (MIT) + structural checks | this server |
Run evaluations, read results | Power Platform API | official, GA, standard harness |
Chat with the published agent | DirectLine v3 (no-auth / manual-auth agents) or Copilot Studio client SDK (Entra SSO) | official |
Publish |
| official |
Read, create, change and delete cloud flows | Dataverse | official API, shapes unverified live |
Bind a flow's connections |
| official API, shapes unverified live |
Flow run history, start a run | Power Automate Process Simple API | the service the portal calls, unverified live |
Explain a failed run, diff it against one that worked, score a flow's reliability | the same API's per-run actions route, plus the SAS-signed content links it returns | this server, unverified live |
Portal drift since the last sync |
| this server |
Tenant configuration to files |
| this server |
Hard limits the server works around rather than hides:
Evaluation test sets cannot be created through the API. cs_create_test_set_csv writes
the CSV the portal imports (max 100 cases); after one import, runs and results are automated.
Connector, MCP and prompt tools need a connection that only the portal can authorise.
cs_add_tool writes the YAML and the connection-reference stub and returns the portal step.
The one exception is a service-principal Dataverse connection, which cs_create_connection
can create. The same limit is why a new cloud flow is created switched off: bind its
connections, then cs_set_flow_state.
Evaluations and topic YAML are standard-harness features. GitHub Copilot harness agents
(--authoring-mode cli-copilot) get init / pack / import / instructions / chat only.
Copilot Studio does not report whether a conversation succeeded. The transcript tools derive an outcome from the activities. Treat the rates as a place to look, and read the transcript before acting.
A workspace that was never connected to an environment packs less. Verified against pac
2.11.2: pac copilot pack on a workspace from pac copilot init without --environment
packages settings, agent and topics only and rejects knowledge/, actions/, tools/,
trigger/, variables/, workflows/ and connectionreferences.mcs.yml. Those folders are
handled by pac copilot push from a sync-connected workspace (clone, or init with an
environment). The authoring tools tell you when you are in a pack-only workspace.
The Power Platform CLI ships a built-in MCP server (pac copilot mcp --run, preview, named
"Power Platform Management MCP Server"). It is a natural-language front end to pac itself: each
of its tools runs one pac command. Probed on pac 2.11.2 it exposes 70 tools, of which exactly one
is about Copilot Studio (copilot_publish); 51 are tenant administration, managed identity,
model-driven apps and generated pages, Power Pages, code apps and code generation.
pac MCP server ( | copilot-studio-mcp (this repo) | |
Purpose | run pac commands in natural language; tenant and environment administration | build, test, ship and maintain Copilot Studio agents from the editor |
Copilot Studio commands |
| init, clone, pull, push, pack, publish, status, list, delete, templates, translations, quarantine, AI Builder instructions |
Authoring | none | topics, knowledge sources, tools (connector / MCP / flow / prompt / agent), triggers, variables, and the agent's own settings as YAML; day-two edit and remove; schema validation (744 definitions); rules-based review with a score |
Testing | none | evaluation test sets and runs (Power Platform API), chat through DirectLine or the client SDK, local conversation tests, production transcripts |
ALM | solution list, export, import, check | pull a whole solution with a deployment settings file and redeploy it 1:1, Solution Checker, versioning, staged upgrades, pipelines, DTAP snapshots and comparison |
Drift | none | portal changes since the last sync (quick Dataverse check, full clone diff) and a push preflight that blocks on conflicts |
Safety | no dry run in the server; the client's approval prompt is the only gate | every environment-changing tool returns a dry run until |
Tenant administration | admin commands as native tools | the admin commands plus |
Cloud flows | none beyond raw pac | list, read, create, rebuild, switch on or off, run history, and a step-based definition builder |
Guidance | tool descriptions | usage instructions in the handshake, |
Other pac groups | managed-identity, model, pages, code, modelbuilder as native tools | reachable through |
Sign-in | pac auth profile | pac auth profile, plus MSAL for the APIs pac does not cover (evaluations, Dataverse reads, environments, chat) |
Tool list | fixed | presets and |
Both are stdio servers and can be registered side by side: pac's for tenant administration, this one for agent work. One practical note: pac's server prints a non-JSON line on stdout at startup, which strict MCP clients may reject.
Sources: Use Power Platform CLI with built-in MCP server
and a tools/list probe of pac 2.11.2 (2026-09-07).
flowchart LR
VS["VS Code / GitHub Copilot"] --> TOOLS
CC["Claude Code"] --> TOOLS
subgraph SERVER["copilot-studio-mcp"]
TOOLS["MCP tool call"] --> SYNC["Sync layer: pac copilot, pac solution, pac admin"]
TOOLS --> AUTH["Authoring layer: YAML + schema validation, flow builder"]
TOOLS --> CLOUD["Cloud layer: evaluations, publish, chat, flows, drift"]
end
AUTH --> WS["Agent workspace on disk: topics, knowledge, actions, workflows"]
SYNC --> WS
SYNC --> DV["Dataverse / Copilot Studio"]
SYNC --> BACKUP["Tenant backup and solution folders on disk"]
CLOUD --> PPAPI["Power Platform API"]
CLOUD --> DV
CLOUD --> FLOW["Power Automate service: flow runs"]
CLOUD --> DL["Published agent: DirectLine or SDK"]The cloud workflows were built from documentation and the published schema; phases A to F
received a first live verification on 2026-09-08. docs/verify.md is the current follow-up list.
docs/live-verification.md is the full runbook: phases A to D are read-only and retire most of the
open questions without touching the tenant, E to G write and say so. docs/verification-template.md
is the results file to fill in, and scripts/redact-verification.mjs replaces GUIDs, org URLs,
emails and tokens with stable pseudonyms so a result can be shared from a public repo.
docs/STATUS.md is the full historical record. docs/test-verification.md is the runbook for the
feedback loop (static checks, behavioural tests, transcripts, closing the loop); its phase 1
settles whether live activities carry the topic, tool and citation attribution the conversation
tests read.
git clone https://github.com/jgt87/copilot-studio-mcp.git
cd copilot-studio-mcp
npm install
npm run build # dist/index.js is the server: register it as "command": "node", "args": ["<repo>/dist/index.js"]
npm test # build + unit tests (fixtures, no network)
node scripts/smoke.mjs # drive the built server over stdio
node scripts/oracle-pack.mjs # pac copilot init + authoring tools + pac copilot packreference/bot.schema.yaml-authoring.json and reference/templates come from
microsoft/skills-for-copilot-studio (MIT, see reference/LICENSE.skills-for-copilot-studio.txt).
Fixtures under test/fixtures/pac-* were generated with pac copilot init.
MIT licensed.
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.
Inputs: name (required), inputs, actions, addTool, +5 more.
Add knowledge as YAML: kind 'public-site' (Bing-scoped website, max 2 path levels), 'sharepoint' (direct folder URL), 'graph-connector' (Microsoft Graph connector via environment variable), or 'files' (copy documents into knowledge/files for upload on push). Dataverse, AI Search and SQL knowledge are portal-only. 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.
Inputs: kind (required), name (required), site, files, +9 more.
Add an existing component (an agent, flow, connection reference, environment variable, table ...) to an unmanaged solution by schema name or id and component type code. Runs 'pac solution add-solution-component' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: component (required), solutionName (required), componentType (required), cwd, +7 more.
Attach license plan definition and mapping CSV files to a solution project (ISV licensing). Run in the solution project folder (cwd). Local file change only. Runs 'pac solution add-license' with the active pac auth profile.
Inputs: planMappingFile (required), planDefinitionFile (required), cwd, profile, +2 more.
Reference another project (plug-in, PCF, ...) from a .cdsproj so it is packed into the solution. Run in the solution project folder (cwd). Local file change only. Runs 'pac solution add-reference' with the active pac auth profile.
Inputs: path (required), cwd, profile, background, +1 more.
Create actions/.mcs.yml. type 'connector': a connector operation (connectorId like shared_office365, operationId like SendEmailV2; use cs_list_connectors / cs_describe_connector to find them). type 'mcp': an MCP server exposed through a connector. type 'flow': a cloud flow by id. type 'prompt': an AI Builder prompt by model id (cs_list_prompts). type 'connected-agent': another Copilot Studio agent by schema name. type 'child-agent': a child agent's GPT component. type 'raw': any other TaskAction kind with the action object supplied. When the connector definition is cached, the operationId is checked and required inputs are filled from the catalog unless inputs are given. Connector and MCP tools need a connection that only the portal can authorise; the tool writes the connection-reference stub and returns the portal step. 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.
Inputs: name (required), type (required), description (required), action, +15 more.
Create topics/.topic.mcs.yml from a declarative spec: trigger phrases (or a system trigger) plus message / question / condition / redirect / setVariable / searchKnowledge / http / invokeFlow / end / raw nodes. Validates the result. Push to apply. 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.
Inputs: name (required), actions (required), confirm, priority, +5 more.
Create trigger/.trigger.mcs.yml pointing at a cloud flow that starts the agent (WorkflowExternalTrigger). 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.
Inputs: name (required), flowId (required), confirm, overwrite, +2 more.
Create variables/.variable.mcs.yml (GlobalVariableComponent, conversation scope). 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.
Inputs: name (required), confirm, overwrite, workspace, +3 more.
Put an environment into an environment group, which applies that group's rules to it. Changes tenant configuration: requires confirm: true. Runs 'pac admin add-group' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: environmentGroup (required), cwd, confirm, profile, +3 more.
Give an Entra group a security role in an environment through a Dataverse team. Changes a live environment: requires confirm: true. Runs 'pac admin assign-group' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: role (required), group (required), teamType (required), groupName (required), +8 more.
Give a user (or an application user) a security role in an environment. Changes a live environment: requires confirm: true. Runs 'pac admin assign-user' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: role (required), user (required), cwd, confirm, +6 more.
Give many users their security roles in one environment, from a CSV roster or an inline list. pac assigns one user and one role per call, so a roster of ten developers with three roles each is thirty calls; this expands the roster and runs them under a single approval. Without confirm it returns the plan: every user-and-role pair it would attempt, so you can read the whole thing before any of it happens. Rows are independent, so a bad UPN or a role the environment does not have is reported and the rest still run. Changes a live environment: requires confirm: true. Runs as the admin account: pass 'profile' or set CPS_ADMIN_PROFILE. Prefer cs_admin_assign_group when the roster is really a group: that is one call per role however many people are in it, and new joiners inherit access. Unverified against a live tenant.
Inputs: environment (required), csv, confirm, profile, +4 more.
Take a manual backup of an environment (the platform's own backup, not the file backup cs_backup_tenant writes). Changes a live environment: requires confirm: true. Runs 'pac admin backup' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: label (required), cwd, confirm, profile, +3 more.
Copy a source environment onto a target environment. Everything in the target is replaced: requires confirm: true. Runs 'pac admin copy' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: cwd, name, type, async, +8 more.
Create a Dataverse environment in the tenant. Consumes tenant capacity: requires confirm: true. Runs 'pac admin create' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: type (required), cwd, name, user, +19 more.
Register an Entra application and give it an application user with a security role in an environment: the headless identity a pipeline signs in as. Changes a live environment: requires confirm: true. Runs 'pac admin create-service-principal' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: cwd, name, role, confirm, +4 more.
Delete an environment from the tenant, with everything in it: agents, solutions, flows and data. Irreversible beyond the platform's own backup retention: requires confirm: true. Runs 'pac admin delete' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: cwd, async, confirm, profile, +4 more.
Status of the tenant operations that are still running (copies, restores, resets, deletions). Runs 'pac admin status' with the active pac auth profile.
Inputs: cwd, profile, background, timeoutSeconds.
Entra applications registered with the tenant for Power Platform. Runs 'pac admin application list' with the active pac auth profile.
Inputs: cwd, profile, background, timeoutSeconds.
The Dynamics 365 application templates that can be installed when creating an environment, per region. Runs 'pac admin list-app-templates' with the active pac auth profile.
Inputs: cwd, region, profile, background, +1 more.
Backups of an environment, with their labels and dates: what cs_admin_restore_environment can restore. Runs 'pac admin list-backups' with the active pac auth profile.
Inputs: cwd, profile, background, environment, +1 more.
Data loss prevention policies in the tenant: the connector groups that decide which connectors an agent or flow may combine. Runs 'pac admin dlp-policy list' with the active pac auth profile.
Inputs: cwd, profile, background, timeoutSeconds.
Environment groups in the tenant (the grouping used for managed-environment rules). Runs 'pac admin list-groups' with the active pac auth profile.
Inputs: cwd, profile, background, timeoutSeconds.
Every environment in the tenant with its type, region and state, as the admin centre lists them. Filters by name, type or installed application. Runs 'pac admin list' with the active pac auth profile.
Inputs: cwd, name, type, profile, +4 more.
Security roles in an environment, optionally including child roles: what cs_admin_assign_user and cs_admin_assign_group can grant. Runs 'pac admin list-roles' with the active pac auth profile.
Inputs: cwd, profile, background, environment, +3 more.
Entra applications that have an application user in Dataverse: who can act without a person signing in. Runs 'pac admin list-service-principal' with the active pac auth profile.
Inputs: cwd, max, filter, profile, +2 more.
The tenant-wide Power Platform settings (governance, sharing, support, licensing). With settingsFile, pac writes them as JSON to that path; that file is the reference copy to keep in source control. Runs 'pac admin list-tenant-settings' with the active pac auth profile.
Inputs: cwd, profile, background, settingsFile, +1 more.
Run a tenant-level resource query (the admin centre's own query language) and optionally write the results to a file as JSON, list or CSV. Runs 'pac admin query' with the active pac auth profile.
Inputs: cwd, query, profile, queryFile, +4 more.
Register an Entra application with the tenant so it can be used by Power Platform. Changes tenant configuration: requires confirm: true. Runs 'pac admin application register' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: applicationId (required), cwd, confirm, profile, +2 more.
Reset an environment to an empty Dataverse instance. Everything in it is deleted: requires confirm: true. Runs 'pac admin reset' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: cwd, name, async, domain, +11 more.
Restore a backup into the same or another environment. Overwrites the target's data and customisations: requires confirm: true. Runs 'pac admin restore' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: selectedBackup (required), cwd, name, async, +8 more.
Give yourself the System Administrator role in an environment. Needs Global, Power Platform or Dynamics 365 admin. Changes a live environment: requires confirm: true. Runs 'pac admin self-elevate' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: cwd, confirm, profile, background, +2 more.
Set how many days backups of an environment are kept (7, 14, 21 or 28). Changes a live environment: requires confirm: true. Runs 'pac admin set-backup-retention-period' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: days (required), cwd, async, confirm, +5 more.
Turn managed environments on ('Standard') or off ('Basic') for an environment and set its governance options: sharing limits, solution checker mode, maker onboarding. Changes tenant governance: requires confirm: true. Runs 'pac admin set-governance-config' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: environment (required), protectionLevel (required), cwd, confirm, +15 more.
Put an environment into administration mode (only admins can use it) or back, and control background operations. Changes a live environment: requires confirm: true. Runs 'pac admin set-runtime-state' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: environment (required), runtimeState (required), cwd, async, +6 more.
One data loss prevention policy in full: its connector classification and the environments it applies to. Runs 'pac admin dlp-policy show' with the active pac auth profile.
Inputs: policyName (required), cwd, profile, background, +1 more.
Remove an Entra application's tenant registration. Changes tenant configuration: requires confirm: true. Runs 'pac admin application unregister' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: applicationId (required), cwd, confirm, profile, +2 more.
Change tenant-wide settings, either from a settings file or one setting at a time (for example powerPlatform.governance.disableDeveloperEnvironmentCreationByNonAdminUsers). Affects the whole tenant: requires confirm: true. Runs 'pac admin update-tenant-settings' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: cwd, confirm, profile, background, +4 more.
How reliable a cloud flow is across its recent runs: failure rate, duration spread (median and 90th percentile), and which actions the failures concentrate on. The verdict distinguishes one broken step from failures spread across many actions, which points at a connection, throttling or an unreliable downstream system instead. Read-only. Use it before cs_explain_flow_run when the complaint is 'it fails sometimes' rather than 'it failed just now'. Uses the Power Automate service (cs_login scope 'flow'). Unverified against a live tenant.
Inputs: flowId (required), lastN, clientId, tenantId, +3 more.
Who pac is signed in as, and against which environment. Runs 'pac auth who' with the active pac auth profile.
Inputs: cwd, profile, background, timeoutSeconds.
Write the tenant's Power Platform configuration to local files for reference, diffing and source control: tenant settings, environments, DLP policies, environment groups, service principals, registered applications and app templates, plus per environment its details, solutions, agents, connections, security roles and platform backups. Read-only for the tenant; it only writes files. Runs as the admin account: pass 'profile' or set CPS_ADMIN_PROFILE. Each capture is independent, so a command the account cannot run is reported in 'skipped' and the rest still completes.
Inputs: dir (required), profile, clientId, tenantId, +6 more.
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.
Inputs: flowId (required), search, confirm, activate, +8 more.
Block an agent so nobody in the organisation can use it, or lift an existing block. This is a governance action across the whole tenant, not a deployment one: it does not unpublish or delete the agent, and it affects every user at once. Changes a live tenant: requires confirm: true. Needs the CopilotPackages.ReadWrite.All permission and runs against Graph beta, the only version that exposes it (cs_login scope 'graph_write'). Needs a Microsoft Agent 365 licence and is global-cloud only. Unverified against a live tenant.
Inputs: id (required), blocked (required), confirm, clientId, +2 more.
Compose a Power Automate cloud flow definition from a step spec, without touching any environment: a trigger (agent-callable by default, or manual, HTTP, schedule or a connector trigger) plus steps (connector operations, HTTP calls, conditions, loops, scopes, variables, compose, terminate, response, or raw JSON). Steps run in order. Returns the definition, the connection references it needs and any notes, and can write it to a file. Feed the same spec to cs_create_flow to create the flow, or cs_update_flow to replace an existing one. Use cs_list_connectors and cs_describe_connector to find connector ids, operation ids and their parameters first.
Inputs: name (required), steps, outputs, trigger, +3 more.
Send one utterance to the published agent and return its replies (and raw activities). Use conversationId to continue. If the agent answers with a sign-in card, signInUrl is returned.
Inputs: utterance (required), botId, maxMs, clientId, +10 more.
Find changes made directly in Copilot Studio after the workspace was last cloned, pulled or pushed. mode 'quick' (default) reads the agent's component rows from Dataverse and compares them with the sync stamp: which topics, tools and knowledge sources changed, by whom, when, whether the agent settings changed and whether there are unpublished changes; needs a cached cs_login, no pac. mode 'full' runs pac copilot clone into a temporary folder and classifies every file as local-modified, remote-modified or both (conflict) against the stamp, with unified diffs. Both are read-only. Resolve drift with cs_pull (three-way merge), then commit.
Inputs: mode, clientId, tenantId, keepClone, +2 more.
Analyse solution zip files with the Power Apps Checker service (Solution Checker or AppSource Certification rule set) and write the results locally. Use as a quality gate before cs_deploy_solution. Runs 'pac solution check' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise). Only some inputs mutate; see the parameter descriptions.
Inputs: cwd, geo, path, confirm, +12 more.
pac copilot clone: download an existing agent into a sync-connected workspace (a subfolder named after the agent under outputDir). Needs a pac auth profile. Records a sync stamp (.mcs/cs-sync.json) that cs_check_drift and the cs_push preflight compare against.
Inputs: bot, outputDir, displayName, environment, +1 more.
Export a solution from the environment and unpack it into a solution project folder (source-control layout). Read-only for the environment. Runs 'pac solution clone' with the active pac auth profile.
Inputs: name (required), cwd, map, async, +9 more.
Snapshot every environment in an ordered chain (e.g. DEV, TEST, ACC, PROD) and compare each adjacent pair. Returns one report per pair plus the first stage where drift appears. Snapshots go to /, reports to /reports.
Inputs: dir (required), chain (required), agents, clientId, +7 more.
Diff a failed run against a successful one to separate a data problem from a logic problem. Names the action where the two runs part company, lists every action whose status differs, and flags actions present in one run but not the other, which means the definition changed between them. With compareTriggerData it also reports which top-level keys of the trigger payload differ (key names only, never the values). The baseline defaults to the most recent successful run. Read-only. Uses the Power Automate service (cs_login scope 'flow'). Unverified against a live tenant.
Inputs: runId (required), flowId (required), clientId, tenantId, +5 more.
Offline diff of two snapshot folders: solution version, per-agent YAML differences (noise such as ids, audit info and connection ids removed), flows, connection references, environment variables, unpublished changes. Writes /-vs-.md and .json. failOnDrift returns an error result when drift is found (for pipeline gates).
Inputs: a (required), b (required), reportDir, failOnDrift, +3 more.
pac copilot init: create a new agent workspace on disk. Without 'environment' it is a local scaffold (no sign-in). With 'environment' it also creates the live agent and connects the workspace (needs pac auth profile and confirm: true). With 'solutionName' the agent is created inside that solution (existing unmanaged solution, or a new one with createSolution: true) via init, pack, import and clone; without it, pac puts the agent in a solution named after the agent. authoringMode 'classic' is the standard harness (topics, evaluations); 'cli-copilot' is the GitHub Copilot harness.
Inputs: name (required), confirm, template, background, +8 more.
Create a new agent in a solution from a template produced by cs_extract_agent_template. Runs 'pac copilot create' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: solution (required), schemaName (required), displayName (required), templateFile (required), +6 more.
Create a pac authentication profile. Non-interactive: service principal (applicationId + clientSecret + tenant), certificate, managed identity, or GitHub / Azure DevOps federation. Interactive (a person signing in, which is the usual way to add an admin account): pass name, environment and background: true - pac opens its own browser, the call returns a jobId at once, and cs_job_status reports when the profile exists. Without background this blocks until the sign-in finishes and the client will usually give up first. Device code needs a terminal: this server gives pac no stdin. Runs 'pac auth create' with the active pac auth profile.
Inputs: cwd, name, cloud, tenant, +14 more.
Create a Dataverse connection that authenticates with an app registration (application id + client secret) so flows and tools owned by a pipeline do not depend on a person. This is the only connection kind pac can create; connector connections (SharePoint, Outlook, MCP servers ...) are still authorised in the portal. Runs 'pac connection create' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: name (required), tenantId (required), clientSecret (required), applicationId (required), +6 more.
pac solution create-settings: the JSON that maps every connection reference (to a connection id in the target environment) and environment variable (to a target value). Pass connectionReferences / environmentVariables to fill values; the result lists what is still unmapped.
Inputs: zip, regenerate, solutionDir, settingsFile, +3 more.
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.
Inputs: name (required), steps, confirm, outputs, +12 more.
Create a new unmanaged solution (and its publisher if missing) in an environment by packing an empty solution manifest and importing it with pac. Use it to prepare the container before cs_create_agent with solutionName. Requires confirm: true.
Inputs: uniqueName (required), publisherPrefix (required), confirm, workDir, +3 more.
Write the CSV the portal's Evaluation page imports (columns Question, Expected response; max 100 cases). Test sets cannot be created through the API, so this file is imported once in the portal; runs and results are then automated via cs_run_evaluation. suggestFromWorkspace derives cases from topics, starters and knowledge.
Inputs: cases, workspace, outputPath, maxSuggested, +1 more.
pac copilot delete: permanently delete an agent from the environment. Requires confirm: true.
Inputs: bot (required), confirm, environment.
Remove a pac auth profile by index or name (local credential store only). Runs 'pac auth delete' with the active pac auth profile.
Inputs: cwd, name, index, profile, +2 more.
Delete a connection by id. Flows and tools bound to it stop working until rebound. Runs 'pac connection delete' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: connectionId (required), cwd, confirm, profile, +3 more.
Remove a cloud flow from the environment for good. Read it with cs_get_flow first: any agent tool that calls this flow will be left pointing at nothing, and a flow that is still switched on has to be turned off with cs_set_flow_state before Dataverse will delete it. A managed flow cannot be deleted this way; uninstall the solution it came in. Changes a live environment and cannot be undone: requires confirm: true.
Inputs: flowId (required), confirm, clientId, tenantId, +3 more.
pac solution delete: delete an unmanaged solution container (its components stay in the environment) or uninstall a managed one (its components are removed). Requires confirm: true.
Inputs: name (required), confirm, environment.
Start a pipeline deployment of a solution to a stage (the alternative to cs_deploy_solution when the tenant uses Power Platform pipelines). stageId comes from cs_list_pipelines. Runs 'pac pipeline deploy' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: stageId (required), newVersion (required), solutionName (required), currentVersion (required), +7 more.
pac solution import into the target environment using the deployment settings file, then publish every Copilot Studio agent from the solution. Source: a zip, or a solutionDir from cs_pull_solution (managed zip preferred when present unless unmanaged: true), or an unpacked srcFolder (packed first). Blocks when connection references or environment variables are unmapped unless allowUnmapped. Requires confirm: true.
Inputs: targetEnvironment (required), zip, confirm, srcFolder, +9 more.
Fetch (or read from cache) a connector's OpenAPI definition and list its operations with operationId, parameters (required, type, description) and response fields; marks MCP-capable connectors (x-ms-agentic-protocol). Exactly what cs_add_tool needs. Cached under .cs-catalog//connectors/.json and used by cs_validate.
Inputs: connector (required), refresh, clientId, tenantId, +4 more.
Export a solution (unmanaged, async) and unpack it locally, then inventory everything inside: agents (with harness and component counts), bot components by kind, cloud flows, connection references, environment variables, custom connectors, other component folders. Read-only for the environment.
Inputs: name (required), workDir, environment.
Inventory of an agent workspace: settings, instructions, topics (with trigger phrases), knowledge sources, tools, flows, triggers, variables, connection references, sync metadata.
Inputs: workspace.
Answer 'give me the Teams app package for this agent': download the channel manifest zip (manifest.json plus icons) for an agent published to the Microsoft 365 and Teams channel, the same file the portal offers as 'Download .zip', for sideloading or the Teams admin centre. Writes only the zip file; nothing in the environment changes. The agent must already be published to that channel. Follows the published Power Platform API reference; not yet verified against a live tenant.
Inputs: botId, channel, clientId, tenantId, +4 more.
Answer 'what exactly did that evaluation run test?': download the agent content snapshot the run was scored against, as the service zipped it, so it can be compared with the workspace now (unzip, then cs_compare_snapshots or a file diff). Writes only the zip file; the environment is not touched. Follows the published Power Platform API reference; not yet verified against a live tenant.
Inputs: runId (required), botId, clientId, tenantId, +3 more.
Change a knowledge source file: name, description, site URL, includeSubPages, trigger condition (null removes it), additional search terms. 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.
Inputs: knowledge (required), site, rename, confirm, +5 more.
Change an existing tool file: name, description, modelDescription / modelDisplayName (what the orchestrator routes on), operationId, connection mode or reference, output mode, and inputs (set / add / remove). Validates afterwards. 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.
Inputs: tool (required), rename, confirm, addInputs, +10 more.
Change an existing topic in place, keeping its comment header: rename, description, trigger phrases (set / add / remove), priority, append or insert nodes (same node spec as cs_add_topic), remove top-level nodes by id. Validates the file afterwards. 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.
Inputs: topic (required), rename, confirm, priority, +8 more.
Run a FetchXML query against Dataverse through pac (read-only), e.g. to inspect bot or botcomponent rows without an MSAL sign-in. Runs 'pac env fetch' with the active pac auth profile.
Inputs: cwd, xml, profile, xmlFile, +3 more.
Environments visible to the active pac auth profile. The pac-based alternative to cs_list_environments, which needs a cs_login. Runs 'pac env list' with the active pac auth profile.
Inputs: cwd, filter, profile, background, +1 more.
Set the environment that pac commands use when none is passed (local profile setting). Runs 'pac env select' with the active pac auth profile.
Inputs: environment (required), cwd, profile, background, +1 more.
Organisation id, URL, version and the signed-in user for an environment. Runs 'pac env who' with the active pac auth profile.
Inputs: cwd, profile, background, environment, +1 more.
Why one run of a cloud flow failed, in terms of the action that broke and what it was given. For each failed action it resolves the real error message - a failed connector action carries no error of its own, so the message is fetched from the action's outputs - classifies the failure as a connector, expression or timeout problem, and returns the inputs it was called with plus the outputs of the actions that ran just before it. Read-only. Start here when cs_list_flow_runs shows a failure. Uses the Power Automate service (cs_login scope 'flow'). Unverified against a live tenant.
Inputs: runId (required), flowId (required), clientId, tenantId, +4 more.
Write a reusable YAML template from an existing agent (its topics, settings and components), for cs_create_agent_from_template in another environment or solution. Runs 'pac copilot extract-template' with the active pac auth profile.
Inputs: bot (required), templateFile (required), cwd, profile, +6 more.
Export the localisable strings of one or all agents as .resx or .json files, from the environment or from an unpacked solution folder. Runs 'pac copilot extract-translation' with the active pac auth profile.
Inputs: all, bot, cwd, format, +7 more.
Write the agent's instructions for it - the system prompt that decides how it answers. Builds a brief from purpose, audience, tone, capabilities, boundaries and examples, send it to an AI Builder prompt or model (pac copilot model predict; pick one with cs_list_prompts), and return the generated instructions. With apply: true the text is written into the agent's instructions (agent.mcs.yml, or settings.mcs.yml for cli-copilot), and only with confirm: true as well - without it the generated text comes back with the change it would make and the character count, and nothing is written. Pass currentInstructions/changeRequest (or refine: true to read the workspace) to revise existing instructions instead.
Inputs: tone, apply, refine, confirm, +12 more.
Answer 'do users have to approve this agent's connectors?': read whether an admin has switched connector consent bypass on for the agent, so its connector tools run without each end user consenting to the connection first. Read-only. cs_set_connector_consent_bypass is the separate step that changes it. Follows the published Power Platform API reference; not yet verified against a live tenant.
Inputs: botId, clientId, tenantId, workspace, +1 more.
Status and per-case results of an evaluation run, with a pass/fail summary per test method.
Inputs: runId (required), botId, clientId, tenantId, +3 more.
Answer 'what does this flow actually do?': one flow's trigger and action names, its connection references, and the whole Power Automate definition when 'includeDefinition' is set. Read-only. Use it before cs_update_flow, and to see why a flow cannot be switched on. For what happened on a particular run, use cs_list_flow_runs and cs_explain_flow_run instead.
Inputs: flowId (required), clientId, tenantId, workspace, +3 more.
One run of a cloud flow with its status, timing, trigger and error. Read-only. Uses the Power Automate service (cs_login scope 'flow'). Unverified against a live tenant.
Inputs: runId (required), flowId (required), clientId, tenantId, +2 more.
Full catalogue entry for one agent: metadata, element types, availability and deployment state, and whether it is blocked. The raw body is returned alongside the mapped fields, because the detail resource carries more than the list rows. Read-only (cs_login scope 'graph'). Needs a Microsoft Agent 365 licence and is global-cloud only. Unverified against a live tenant.
Inputs: id (required), version, clientId, tenantId, +1 more.
Show one evaluation test set of an agent with its test cases. Read-only. testSetId comes from cs_list_test_sets. Runs 'pac copilot-studio get-maker-evaluation-test-set' with the active pac auth profile.
Inputs: botId (required), testSetId (required), cwd, profile, +3 more.
The full turn list of one session: who said what, in order, with the topic and tool attributed to each turn where the transcript records them. Read-only.
Inputs: transcriptId (required), botId, clientId, tenantId, +2 more.
Explain how to do one part of Copilot Studio agent development with this server's tools: 'getting-started' (clone or create an agent and take it to a published, tested state), 'instructions' (write the agent's instructions, with AI Builder or by hand), 'knowledge' (add public site, SharePoint, Graph connector or file knowledge), 'tools' (find a connector operation, add the tool, bind its connection), 'topics' (deterministic conversations: triggers and the node types), 'flows' (build a cloud flow, bind its connections, run it, and work out why a run failed), 'evaluations' (test sets, runs and results, plus local conversation tests), 'publish-and-test' (publish the agent and chat with it), 'drift' (changes made in the portal since the last sync, and how to merge them), 'transcripts' (what real users asked, how those sessions ended, and turning the failures into a test set), 'solutions' (pull a solution, redeploy it elsewhere, compare environments), 'administration' (tenant administration with a separate admin account, and backing the tenant configuration up to files), 'troubleshooting' (the errors this server can return, and what each one means). Read the relevant topic when you do not know which tools a job needs or what order they go in; it names the tool for each step and the manual portal steps that cannot be automated. It only explains - it changes nothing and does no work, so when the user asked for something to be built, written or run, call the tool that does it rather than this one. Also returns next steps for the workspace at hand.
Inputs: topic, workspace.
pac solution import of a packed agent (from cs_pack) into an environment. Mutates the environment: requires confirm: true.
Inputs: path (required), confirm, environment, forceOverwrite, +1 more.
Check whether this machine is ready to work: the pac CLI and .NET, which pac auth profile is active, which cloud resources have a usable token, the environment variables, the write policy in force, and the agent workspace it found, ending with the next steps for that workspace. Read-only. Call it once at the start of a session, and again when a tool fails and you need to know whether the CLI, the credentials or the workspace is the reason. It reports the state of the machine and nothing else: when the user asked for something specific - an agent, a flow, a solution, an environment, instructions - call the tool for that thing instead. cs_create_agent scaffolds or creates an agent; cs_guide explains a task.
Inputs: workspace.
Scaffold a Dataverse solution project (.cdsproj) on disk for source-controlled solution development. Runs 'pac solution init' with the active pac auth profile.
Inputs: publisherName (required), publisherPrefix (required), cwd, profile, +3 more.
The state of a job started with background: true - running, succeeded or failed - with the phases it has reached and, once finished, the result the tool would have returned. Read-only. Jobs live in the server process, so a restart loses them; pass recordFile to read the copy the job wrote to disk instead.
Inputs: jobId, recordFile.
List Copilot Studio agents in an environment. via 'pac' uses 'pac copilot list' (needs a pac auth profile); via 'dataverse' queries the bots table with the MSAL token. Default auto: pac when available, else dataverse.
Inputs: via, clientId, tenantId, ownerOnly, +3 more.
The pac authentication profiles on this machine, which one is active, and which account each belongs to. Use it to find the name of the admin profile to pass as 'profile' to the admin tools. Read-only.
Inputs: no named parameters.
pac connection list: connections that exist in an environment (id, connector, owner). Use the ids to map connection references in a deployment settings file before cs_deploy_solution.
Inputs: environment.
The environment's connector registry (the same list the portal's Add a tool shows): Microsoft-published and custom connectors, with an mcpLikely flag for MCP servers. Cached under .cs-catalog//connectors.json for offline use; with search and no sign-in, falls back to the offline seed of public connectors.
Inputs: search, mcpOnly, offline, refresh, +5 more.
List Power Platform environments the signed-in user can access (BAP API), with Dataverse URLs.
Inputs: clientId, tenantId.
Previous evaluation runs for the agent.
Inputs: botId, clientId, tenantId, workspace, +1 more.
Answer 'when did this flow last run, and did it work?': the run history of one cloud flow, most recent first, with status, start and end time, duration and the error of a failed run. Read-only. Use it to find the run you care about, then cs_explain_flow_run on that run to learn why it failed. Uses the Power Automate service, which is a separate sign-in from Dataverse (cs_login scope 'flow'). Unverified against a live tenant.
Inputs: flowId (required), top, clientId, tenantId, +2 more.
Answer 'which flows are there?': every cloud flow in the environment with its state, owner and last change, so you can see what the agent's flow tools can call and what a solution import left switched off. Read-only. This is the inventory only. For one flow's contents use cs_get_flow; for its execution history use cs_list_flow_runs; for the cause of a failure use cs_explain_flow_run.
Inputs: top, search, clientId, tenantId, +4 more.
Every agent in the organisation's Microsoft 365 catalogue, across environments, with the things Power Platform cannot see: who the agent is available to, where it is deployed, and whether an admin has blocked it. Defaults to agents built in Copilot Studio; pass platform: 'all' to include the Agent Builder and acquired apps. Read-only. Uses Microsoft Graph, a separate sign-in from Dataverse (cs_login scope 'graph'). Needs a Microsoft Agent 365 licence and is global-cloud only. Unverified against a live tenant.
Inputs: top, host, filter, version, +7 more.
List the pipelines that can deploy from an environment, or the stages of one pipeline. Read-only. Runs 'pac pipeline list' with the active pac auth profile.
Inputs: cwd, profile, pipeline, background, +2 more.
pac copilot model list: AI Builder models (including custom prompts) in the environment, with ids for cs_add_tool type 'prompt'.
Inputs: search, activeOnly, environment.
pac solution list: solutions in an environment with version and managed flag. Needs a pac auth profile.
Inputs: environment, includeSystem.
Power Platform API: test sets defined for the agent (standard harness).
Inputs: botId, clientId, tenantId, workspace, +1 more.
Sessions people had with the published agent, newest first: when, how many turns, the first thing the user asked, which topics and tools fired, and how the session ended. Read-only. Needs a cached cs_login. Use it to find the session behind a bad answer, then cs_get_transcript for the full turn list.
Inputs: top, days, botId, search, +5 more.
Acquire a Microsoft Entra token for the cloud tools (evaluations, environments, agents, publish, chat, drift). mode 'interactive' (default) starts a browser sign-in and returns within waitSeconds: status 'ok' when it completed, otherwise status 'pending' with the sign-in URL. If no browser opened, show the user that URL to open on the machine running this server; the page redirects to localhost and the login completes in the background (check cs_login_status or call any cloud tool). mode 'device_code' returns a code to enter at microsoft.com/devicelogin (some tenants block this flow). Not needed for pac commands, which use 'pac auth create'.
Inputs: mode, scope, clientId, tenantId, +4 more.
Answer 'am I signed in?' for the cloud tools: the cached MSAL accounts, and whether a browser or device-code sign-in is still pending, with its URL or code; optionally wait for it to complete. For the separate pac sign-in, cs_auth_who.
Inputs: wait, tenantId, workspace.
Remove cached MSAL accounts for the tenant.
Inputs: tenantId.
Inspect the Copilot Studio authoring schema: summarize or resolve a definition (e.g. Question, SearchAndSummarizeContent, KnowledgeSourceConfiguration), search by keyword, or list all kinds.
Inputs: name, depth, search, resolve, +1 more.
Import translated .resx or .json files back into one or more agents (environment or unpacked solution folder). whatIf previews the merge without writing. Runs 'pac copilot merge-translation' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise). Only some inputs mutate; see the parameter descriptions.
Inputs: files (required), cwd, whatIf, confirm, +7 more.
Escape hatch: run 'pac <args...>' directly. Read-only commands (list/who/status/help) run immediately; anything else needs confirm: true. 'profile' runs it as another pac auth profile, for example the tenant admin account.
Inputs: args (required), cwd, confirm, profile, +1 more.
pac copilot pack: local-only packaging of the workspace into a Dataverse solution .zip (no sign-in). Also a cheap structural check of the workspace. outputPath must be outside the workspace.
Inputs: publisherPrefix (required), workspace, outputPath, solutionName.
pac solution pack: zip an unpacked source folder (after local edits) so it can be deployed.
Inputs: zip (required), folder (required), packagetype.
Make the agent's current draft visible to real users on its channels - the tool for 'go live', 'release it' and 'make my changes live'. It publishes what is already in Copilot Studio, so send local edits up with cs_push first. via 'pac' runs 'pac copilot publish'; via 'dataverse' calls the PvaPublish action with the MSAL token and polls until publishedon changes. Requires confirm: true.
Inputs: via, botId, confirm, clientId, +6 more.
Publish every unpublished customization in the environment (the 'Publish all customizations' button). Runs 'pac solution publish' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: cwd, async, confirm, profile, +4 more.
pac copilot pull: three-way merge of server changes into the local workspace (also downloads knowledge files). Run before editing and before pushing. Records a sync stamp (.mcs/cs-sync.json) so cs_check_drift can tell later portal changes from yours; commit the workspace afterwards to keep a reviewable history.
Inputs: workspace.
Export the solution (unmanaged and optionally managed), unpack it to /src, write /solution.json, generate deployment-settings.json (connection references + environment variables to map), and clone every agent in the solution into /agents/ as a sync-connected workspace. This is the input for cs_deploy_solution.
Inputs: name (required), targetDir (required), background, cloneAgents, +2 more.
Send local file changes up into the agent's draft in Copilot Studio - topics, knowledge files, flows, connection references - so the draft matches your workspace (pac copilot push). This is the tool for 'upload', 'send my changes up' and 'sync my edits'. It only moves files into the draft; cs_publish is the separate step afterwards. Validates YAML first and blocks on errors unless force. The dry run also reports components changed in Copilot Studio since the last sync (quick drift check, needs a cached cs_login); when one of those also changed locally the push is blocked unless force. Changes the agent in Copilot Studio: requires confirm: true.
Inputs: force, confirm, workspace.
Put an agent in quarantine (users cannot talk to it) or release it. Admin operation. Runs 'pac copilot quarantine' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: botId (required), cwd, confirm, profile, +4 more.
Make another person the owner of a Copilot Studio agent in its Power Platform environment, so they can edit, publish and manage it there. Admin operation. cs_reassign_org_agent is a separate tool for the Microsoft 365 side. Runs 'pac copilot-studio reassign-copilot-agent' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: botId (required), newOwner (required), cwd, confirm, +4 more.
Hand ownership of an agent in the Microsoft 365 agent catalogue to another user, by their Entra object id. Used when the owner leaves the organisation. The agent's owner inside a Power Platform environment is cs_reassign_agent_owner. Changes a live tenant: requires confirm: true. Needs CopilotPackages.ReadWrite.All and runs against Graph beta (cs_login scope 'graph_write'). Needs a Microsoft Agent 365 licence and is global-cloud only. Unverified against a live tenant.
Inputs: id (required), userId (required), confirm, clientId, +2 more.
Delete a topic, knowledge source, tool, trigger, variable or flow from the workspace files (the live agent changes on the next cs_push). For tools, the connection reference is dropped too unless another tool uses it. Reports topics that still redirect to a removed topic. Deletes files: requires confirm: true.
Inputs: kind (required), name (required), confirm, workspace, +1 more.
Judge whether the agent is any good and say what to improve, as a score out of 10 with a fix for each finding: instructions present and sized, escalation and fallback topics, trigger phrase count and overlap, tool descriptions and name collisions, unbound connections, authentication versus private knowledge, web browsing with internal sources, orchestration off with tools, duplicate names, credentials in YAML, pack-only workspace. Returns a score, findings with fixes, and optional Markdown.
Inputs: markdown, workspace, reportPath.
Run a YAML test file (tests: name, utterance, expect, continueConversation) against the published agent through cs_chat and report pass/fail. expect asserts on wording (contains, containsAny, notContains, regex, minLength, noSignIn) and on what the agent did (usedTool, notUsedTool, usedTopic, notUsedTopic, citedKnowledge), so a test can tell a real tool call from an answer that merely sounds right. Every result reports the observed topic, tool and citations whether or not it asserted on them. The CLI-native complement to portal evaluations. Pass writeExample to create a starter file.
Inputs: file, botId, tests, clientId, +11 more.
Start an evaluation run for a test set (draft agent by default, or the published one). Optionally wait for completion and return the summary. mcsConnectionId runs it signed in as a user profile (the id of that user's Copilot Studio connection) so authenticated knowledge and tools answer; toolsConnections picks the connection each connector tool uses. Counts against the 20 runs per agent per 24h limit: requires confirm: true.
Inputs: testSetId (required), wait, botId, confirm, +9 more.
Start a run of a manually triggered cloud flow, with an optional payload. Only flows whose trigger is manual or agent-callable can be started this way; scheduled and event-driven flows run on their own. Whatever the flow does (sending mail, writing records) happens for real, so this changes a live environment: requires confirm: true. Uses the Power Automate service (cs_login scope 'flow'). Unverified against a live tenant.
Inputs: flowId (required), confirm, payload, clientId, +4 more.
Make a pac auth profile the active one, by index (cs_init lists them) or name. Runs 'pac auth select' with the active pac auth profile.
Inputs: cwd, name, index, profile, +2 more.
Switch connector consent bypass on or off for one agent. On, end users stop being asked to approve the agent's connectors and the tools run straight away; off restores the consent prompt. An admin setting through the Power Platform API, so the signed-in user needs a Power Platform or Copilot Studio admin role. Changes a live environment: requires confirm: true. Follows the published Power Platform API reference; not yet verified against a live tenant.
Inputs: enabled (required), botId, confirm, clientId, +3 more.
Switch a flow on (Activated) or off (Draft). This is the step a solution import leaves for you: flows whose connection references were unbound at import time land switched off. A flow can only be turned on once its connections are bound and its definition is valid. Changes a live environment: requires confirm: true.
Inputs: state (required), flowId (required), confirm, clientId, +4 more.
Update the version in a local unpacked solution's Solution.xml, explicitly or by strategy (gittags, filetracking, solution). Local file change only. Runs 'pac solution version' with the active pac auth profile.
Inputs: cwd, profile, filename, strategy, +5 more.
Answer 'there are too many tools': narrow, or restore, the tool list for the rest of this session. The full list is 146 tools and about 50k tokens of schema, which crowds a smaller model's context and makes it choose worse. Presets: core (the loop that builds an agent and gets it live), authoring (local files only), admin (tenant administration), solutions (moving solutions between environments), full (everything). Read-only: it changes nothing in any environment and no tool is lost, only hidden. Ask the user before calling it.
Inputs: preset (required), keep.
Capture one environment into a folder for comparison or history: solution version, every agent cloned with pac copilot clone (agents/), and, when signed in, flows, connection references, environment variables and publish state. Read-only for the environment.
Inputs: dir (required), label (required), environment (required), agents, +5 more.
Without solutionVersion: read the version of a solution in the environment. With it: set that version (mutating). Runs 'pac solution online-version' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise). Only some inputs mutate; see the parameter descriptions.
Inputs: solutionName (required), cwd, confirm, profile, +4 more.
pac copilot status for an agent id.
Inputs: botId, workspace, environmentId.
Aggregate over recent sessions: how they ended, the escalation rate, average turns, how many never matched a topic, the topics and tools that actually fire, and the questions behind the sessions that went badly. Read-only. This is the input for deciding what to fix next, and for cs_create_test_set_csv fromTranscripts.
Inputs: top, days, topN, botId, +4 more.
Re-export the solution and update an existing unpacked solution folder or .cdsproj with the environment's current state. Read-only for the environment. Runs 'pac solution sync' with the active pac auth profile.
Inputs: cwd, map, async, include, +8 more.
Write the portal's import CSV from questions people actually asked, most frequent first, instead of guessing from the workspace. onlyFailed (default true) keeps the sessions that escalated, went unanswered or were abandoned, which are the ones worth turning into regression cases. Read-only apart from writing the file; import it once in the portal, then cs_run_evaluation automates the runs.
Inputs: top, days, botId, clientId, +6 more.
Edit agent.mcs.yml (standard harness): instructions, display name, conversation starters, model hint, and the settings the portal groups under responses and generative AI: response instructions (wording and formatting), response mode, conversation history, capability toggles (web browsing, code interpreter, image generation, Teams / SharePoint / email / meeting / people search), whether the model may use its own general knowledge, content moderation level, file analysis and semantic search. The first call writes nothing: it returns the change - the current lines against the proposed ones, and the instruction character count against the 8000 the product allows - and the file is written on a second call with confirm: true. Local file change; cs_push applies it. For GitHub Copilot harness (cli-copilot) workspaces the instructions go into settings.mcs.yml.
Inputs: confirm, history, workspace, displayName, +14 more.
Rotate the app registration or secret behind a service-principal Dataverse connection. Runs 'pac connection update' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: tenantId (required), clientSecret (required), connectionId (required), applicationId (required), +6 more.
Change a flow's name, description or definition in the environment. Pass 'steps' (and optionally 'trigger') to rebuild the definition the way cs_build_flow_definition does, or 'definition' for a ready-made one; either replaces properties.definition inside the existing clientdata and keeps the connection references. 'clientData' replaces the whole document. Read the current one with cs_get_flow includeDefinition first. Managed flows cannot be edited in place; edit them in their source environment or through a solution. Changes a live environment: requires confirm: true.
Inputs: flowId (required), name, steps, confirm, +12 more.
Set values in settings.mcs.yml by dot path, e.g. {"configuration.settings.GenerativeActionsEnabled": true}. Do not change authoringModel/recognizer/template. 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.
Inputs: patch (required), confirm, workspace.
Complete a managed solution upgrade that was imported as a staged upgrade (pac solution import --stage-and-upgrade or the portal's 'Stage for upgrade'). Runs 'pac solution upgrade' with the active pac auth profile. Mutates a live environment: requires confirm: true (a dry run otherwise).
Inputs: solutionName (required), cwd, async, confirm, +5 more.
Structural validation of every component file against the Copilot Studio authoring schema (kinds, unknown/missing properties, duplicate ids, placeholders, Power Fx prefixes, variable scopes) plus cross-file checks (connection references, topic redirects). Answers 'is anything broken in these files?'; it only reads them and sends nothing anywhere. cs_push runs it itself and blocks on errors.
Inputs: file, workspace.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 148 tools
Descriptions are unusually thorough and explicitly cross-reference siblings (e.g. cs_list_flow_runs vs cs_get_flow vs cs_explain_flow_run, cs_pull vs cs_publish), which resolves most confusion. However, with 148 tools there are several genuinely close pairs an agent could misselect: cs_list_environments / cs_env_list / cs_admin_list_environments, cs_list_agents / cs_list_org_agents, cs_reassign_agent_owner / cs_reassign_org_agent, cs_deploy_solution / cs_deploy_pipeline, and cs_admin_assign_user / cs_admin_assign_users / cs_admin_assign_group.
Every tool uses the uniform cs_ prefix with snake_case and a near-consistent verb_noun or verb_noun_qualifier pattern (cs_create_agent, cs_list_flows, cs_delete_flow, cs_admin_create_environment). The namespace grouping by domain (cs_admin_*, cs_solution_*, cs_flow_*) is predictable and readable.
148 tools is a severe overload for any single server; the server itself concedes this by shipping cs_set_tool_preset to hide ~50k tokens of schema because the full list crowds a model's context and degrades selection. This is exactly the extreme-mismatch case the rubric flags at 50+ tools.
Coverage is exceptional across the whole lifecycle: agent authoring/editing, knowledge, tools, flows, connections, solutions, pipelines, publishing, drift, evaluations, transcripts, and full tenant administration with backup/restore/governance. Almost no dead ends exist; the gaps are portal-only actions that are explicitly called out as such.
Debug, build, and manage Power Automate cloud flows with AI agents
Build, deploy, and sell AI agents for local-service businesses - from your IDE.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
Governed app access for AI agents: 1,000+ apps & 12,000+ tools via Code Mode MCP.
