Skip to main content
Glama
jgt87

Copilot Studio MCP

by jgt87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Generate agent instructions with an AI Builder prompt

cs_generate_instructions

Generate precise system prompts and agent instructions for your Copilot Studio agents. Specify purpose, audience, and tone to define how the agent answers and behaves.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toneNo
applyNoWrite the result into the agent instructions (needs confirm: true as well)
refineNoRevise the workspace's current instructions using changeRequest
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.
modelIdNo
purposeNoWhat the agent is for; required unless refining
audienceNo
examplesNo
languageNo
inputModeNo
modelNameNoFull or partial AI Builder model / prompt name
workspaceNoPath to (or inside) the agent workspace. Defaults to CPS_WORKSPACE or the current directory.
boundariesNo
environmentNoEnvironment id or URL. Defaults to the active pac auth profile.
capabilitiesNoDefault: derived from the workspace (topics, knowledge, tools)
changeRequestNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.8
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed2 schema fields changedv0.1.7
    • changedInput schema / properties / apply / description
      Previous value: -"Write the result into the agent instructions"New value: +"Write the result into the agent instructions (needs confirm: true as well)"
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Required to write the change to the file. Without it the tool returns a preview - the changed lines against the current ones, and the character count - and writes nothing.",
+  "type": "boolean"
+}
  3. First observedv0.1.5

TDQS

A4.7/5.0
Behavior5/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 so: it names the exact files written (agent.mcs.yml, settings.mcs.yml for cli-copilot), the confirm gate that prevents writes, and the precise no-write behavior (changed lines plus character count). This is exactly the destructive-action context an agent needs.

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

Conciseness4/5

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

Front-loads the core purpose and keeps every sentence substantive, but the second sentence is a long run-on bundling build, send, write, and revise modes together. Splitting it would improve scannability without adding content.

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?

No output schema and no annotations, so the description must carry behavior on its own; it covers the write/preview contract and the model-selection prerequisite well. It stops short of explaining the remaining generation-shaping parameters (tone, language, examples, inputMode), which leaves some gaps for a 16-parameter tool.

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

Parameters4/5

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

Schema coverage is only 50% across 16 params, and several (tone, audience, language, examples, boundaries, modelId, inputMode) have no description anywhere; the description partially compensates by naming the brief components it derives from and by spelling out the apply/confirm/refine interplay. Minor flaw: it references currentInstructions, which is not present in the input schema.

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?

Starts with a concrete verb and resource ('Write the agent's instructions … the system prompt'), then explains the build-and-generate pipeline. An agent can distinguish this from cs_update_agent or cs_add_topic without opening any other schema.

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

Usage Guidelines5/5

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

Gives explicit conditions: use cs_list_prompts to pick an AI Builder prompt/model, set apply:true plus confirm:true to write, omit confirm to preview, or pass changeRequest/refine:true to revise existing instructions. The alternative path (refine vs. fresh generation) is named, not implied.

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