Copilot Studio MCP

Overview Schema Source Related Servers Discussions Admin

Update the agent's settings

cs_update_agent

Preview and apply changes to a Copilot Studio agent's configuration: instructions, display name, capabilities, response mode, moderation, and more. First call shows a diff and character count; confirm to write the file.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`confirm`	No	Required to write the change to the file. Without it the tool returns a preview - the changed lines against the current ones, and the character count - and writes nothing.
`history`	No	Whether the agent sees conversation history
`workspace`	No	Path to (or inside) the agent workspace. Defaults to CPS_WORKSPACE or the current directory.
`displayName`	No
`capabilities`	No	Capability toggles; only the ones you pass are changed
`instructions`	No	Replace the instructions
`modelNameHint`	No	Model hint, e.g. GPT5Chat
`historyMessages`	No	How many past user messages to include (with history: conversation)
`contentModeration`	No
`useModelKnowledge`	No	Whether the model may answer from its own general knowledge as well as the knowledge sources
`appendInstructions`	No	Add a paragraph to the instructions
`defaultResponseMode`	No	Response mode: Auto, ThinkDeeper (more reasoning, slower) or QuickResponse
`conversationStarters`	No
`responseInstructions`	No	How answers should be worded and formatted (Settings > Responses > Response formatting in the portal), separate from the main instructions. Capped at 500 characters.
`isFileAnalysisEnabled`	No
`addConversationStarters`	No
`isSemanticSearchEnabled`	No
`appendResponseInstructions`	No	Add a line to the response formatting, within the same 500 characters

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.7Sep 15, 2026

addedInput schema / properties / appendResponseInstructions / description

Added value: +"Add a line to the response formatting, within the same 500 characters"

addedInput schema / properties / confirm

Added value: +{
+  "description": "Required to write the change to the file. Without it the tool returns a preview - the changed lines against the current ones, and the character count - and writes nothing.",
+  "type": "boolean"
+}

changedInput schema / properties / responseInstructions / description

Previous value: -"How answers should be worded and formatted (the portal's response instructions), separate from the main instructions"New value: +"How answers should be worded and formatted (Settings > Responses > Response formatting in the portal), separate from the main instructions. Capped at 500 characters."

First observedv0.1.5Sep 11, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With zero annotations, the description carries full behavioral burden and delivers: it discloses the two-phase commit (first call writes nothing and returns a diff preview with character count against the 8000 limit; second call with confirm: true writes), local file scope, and harness-dependent file location. This is exactly the non-obvious mutation behavior an agent must know before calling.

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

Conciseness4/5

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

Every sentence earns its place and the critical confirm-flow is front-loaded ahead of the settings list. The first sentence is an overlong run-on enumeration and the harness note is buried at the end, but for an 18-param tool the density is justified.

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

Completeness4/5

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

For a high-complexity mutation tool with no annotations and no output schema, the description covers the essential non-obvious behavior: preview/confirm semantics, the character limit, local-file scope, and the harness variant. Minor gaps remain in sibling differentiation and full return-value specification.

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

Parameters3/5

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

Schema coverage is 67%, and the prose partially compensates by naming content moderation, file analysis, and semantic search in the overview. But the description mostly restates groupings the schema already provides and does not systematically clarify the six undocumented parameters (displayName, contentModeration, isFileAnalysisEnabled, conversationStarters, addConversationStarters, isSemanticSearchEnabled).

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

Purpose5/5

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

States a precise verb+resource ('Edit agent.mcs.yml') and enumerates the complete scope of editable settings, from instructions to capability toggles to content moderation. The specificity makes it distinguishable from sibling create/clone/review tools even without naming them.

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

Usage Guidelines3/5

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

Offers one genuine usage context — the standard harness vs GitHub Copilot harness distinction (settings.mcs.yml) and the cs_push workflow note. However, it never states when to prefer this over siblings like cs_update_settings or cs_create_agent, and gives no exclusions or prerequisites.

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

Deploy Server

Update the agent's settings

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools