Skip to main content
Glama
jgt87

Copilot Studio MCP

by jgt87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Edit a tool

cs_edit_tool

Edit an existing Copilot Studio tool file to update its name, description, routing metadata, connection mode, outputs, and inputs. Preview the diff first, then confirm to write changes.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolYesTool name, file stem or path
renameNo
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.
addInputsNo
setInputsNo
workspaceNoPath to (or inside) the agent workspace. Defaults to CPS_WORKSPACE or the current directory.
outputModeNo
descriptionNo
operationIdNo
removeInputsNopropertyNames to drop
connectionModeNo
modelDescriptionNo
modelDisplayNameNo
connectionReferenceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.8
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / addInputs / items / $ref
      Removed value: -"#/properties/setInputs/items"
    • addedInput schema / properties / addInputs / items / anyOf
      Added value: +[
+  {
+    "properties": {
+      "description": {
+        "type": "string"
+      },
+      "entity": {
+        "type": "string"
+      },
+      "kind": {
+        "const": "automatic",
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "shouldPromptUser": {
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "kind",
+      "name",
+      "description"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "kind": {
+        "const": "manual",
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "value": {
+        "description": "Literal or Power Fx (=System.User.Email)",
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "name",
+      "value"
+    ],
+    "type": "object"
+  }
+]
    • changedInput schema / properties / setInputs / items / anyOf
      Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "description": {
-        "type": "string"
-      },
-      "entity": {
-        "type": "string"
-      },
-      "kind": {
-        "const": "automatic",
-        "type": "string"
-      },
-      "name": {
-        "type": "string"
-      },
-      "shouldPromptUser": {
-        "type": "boolean"
-      }
-    },
-    "required": [
-      "kind",
-      "name",
-      "description"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "kind": {
-        "const": "manual",
-        "type": "string"
-      },
-      "name": {
-        "type": "string"
-      },
-      "value": {
-        "description": "Literal or Power Fx (=System.User.Email)",
-        "type": "string"
-      }
-    },
-    "required": [
-      "kind",
-      "name",
-      "value"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "properties": {
+      "description": {
+        "type": "string"
+      },
+      "entity": {
+        "type": "string"
+      },
+      "kind": {
+        "const": "automatic",
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "shouldPromptUser": {
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "kind",
+      "name",
+      "description"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "kind": {
+        "const": "manual",
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "value": {
+        "description": "Literal or Power Fx (=System.User.Email)",
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "name",
+      "value"
+    ],
+    "type": "object"
+  }
+]
  2. Changed1 schema field changedv0.1.7
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Required to write the change to the file. Without it the tool returns a preview - the changed lines against the current ones, and the character count - and writes nothing.",
+  "type": "boolean"
+}
  3. First observedv0.1.5

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations to lean on, the description carries the burden well: it discloses the two-phase commit (first call is a no-op dry run returning a diff, second call with confirm:true writes), that validation runs afterward, and that user approval is expected. It omits any mention of auth/permission requirements or reversibility, but the mutation safety profile is unusually well explained.

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

Conciseness4/5

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

Front-loaded with the resource being changed, then the field list, then the two-phase confirm workflow. The parenthetical about orchestrator routing earns its place. Slightly dense but no filler sentences.

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 14-parameter mutation tool with no annotations and no output schema, the description covers the essential behavioral contract (what changes, the preview/confirm flow, validation) that the schema cannot. Minor gaps remain around workspace targeting and how rename/removeInputs interact, but the definition is serviceable for correct invocation.

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 low (29%), so the description must compensate, and it largely does: it maps the changeable attributes (name via rename, description, modelDescription/modelDisplayName, operationId, connectionMode/connectionReference, outputMode, and input set/add/remove) and clarifies that modelDescription/modelDisplayName drive routing and that inputs have set/add/remove variants. It adds genuine meaning beyond the bare schema, though workspace and confirm semantics come mostly from the schema.

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

Purpose4/5

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

States a specific verb and resource ('Change an existing tool file') and enumerates the mutable fields, including what modelDescription/modelDisplayName control (orchestrator routing). It implies the distinction from cs_add_tool (create) but never names a sibling to route the agent explicitly.

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?

Usage is implied rather than stated: the agent can infer this is for modifying an existing tool, since it says 'existing tool file.' However, no alternatives are named (e.g., cs_add_tool for new tools, cs_set_tool_preset for presets), so the when-to-use-vs-siblings dimension is left to inference.

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