Skip to main content
Glama
jgt87

Copilot Studio MCP

by jgt87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Update the agent's settings

cs_update_agent

Edit agent.mcs.yml to update Copilot Studio agent instructions, responses, capabilities, and moderation; preview changes, then confirm to write locally before cs_push.

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
NameRequiredDescriptionDefault
confirmNoRequired to write the change to the file. Without it the tool returns a preview - the changed lines against the current ones, and the character count - and writes nothing.
historyNoWhether the agent sees conversation history
workspaceNoPath to (or inside) the agent workspace. Defaults to CPS_WORKSPACE or the current directory.
displayNameNo
capabilitiesNoCapability toggles; only the ones you pass are changed
instructionsNoReplace the instructions
modelNameHintNoModel hint, e.g. GPT5Chat
historyMessagesNoHow many past user messages to include (with history: conversation)
contentModerationNo
useModelKnowledgeNoWhether the model may answer from its own general knowledge as well as the knowledge sources
appendInstructionsNoAdd a paragraph to the instructions
defaultResponseModeNoResponse mode: Auto, ThinkDeeper (more reasoning, slower) or QuickResponse
conversationStartersNo
responseInstructionsNoHow answers should be worded and formatted (Settings > Responses > Response formatting in the portal), separate from the main instructions. Capped at 500 characters.
isFileAnalysisEnabledNo
addConversationStartersNo
isSemanticSearchEnabledNo
appendResponseInstructionsNoAdd a line to the response formatting, within the same 500 characters

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.8
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / addConversationStarters / items / additionalProperties
      Removed value: -false
    • removedInput schema / properties / capabilities / additionalProperties
      Removed value: -false
    • removedInput schema / properties / conversationStarters / items / additionalProperties
      Removed value: -false
  2. Changed3 schema fields changedv0.1.7
    • 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."
  3. First observedv0.1.5

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the dry-run/preview semantics, the 8000-character instruction cap and 500-character response-instruction cap, that changes are local to the file, and the harness-dependent target file. It omits some behavioral detail (e.g. what happens on partial/unknown fields), but is substantially informative.

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?

Dense but front-loaded, leading with the file and field list before the preview/confirm mechanics. Slightly run-on and long for one paragraph, but every clause is load-bearing given 18 params.

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 an 18-parameter, no-output-schema, no-annotation mutation tool, the description covers the critical mechanics: preview vs write, limits, target file, and push requirement. It leaves a few lower-priority params (semantic search, file analysis, moderation levels) to the schema, which is acceptable.

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

Parameters4/5

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

Adds real meaning beyond the 67%-covered schema: it maps fields to portal locations (responses, generative AI), explains the difference between instructions/appendInstructions and responseInstructions/appendResponseInstructions, and calls out the 500-char cap. Some params (contentModeration levels, historyMessages interaction, isSemanticSearchEnabled) lack added detail.

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

Purpose5/5

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

States a specific verb and resource (edit agent.mcs.yml) and enumerates exactly which settings it touches. It also names the harness variant (cli-copilot → settings.mcs.yml) and the downstream sibling (cs_push), so an agent can distinguish it from generic settings tools.

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

Usage Guidelines4/5

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

Explains the two-call flow clearly: first call is a preview, writing requires confirm: true. It also says cs_push applies the change. It does not explicitly contrast with cs_update_settings or say when not to use it, which keeps it from a 5.

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

Deploy Server

Other Tools