Skip to main content
Glama
jgt87

Copilot Studio MCP

by jgt87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Edit a topic

cs_edit_topic

Update an existing Copilot Studio topic by changing its name, description, trigger phrases, priority, or nodes. Get a diff preview first, then confirm to apply changes.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicYesTopic 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.
priorityNonull removes the priority
workspaceNoPath to (or inside) the agent workspace. Defaults to CPS_WORKSPACE or the current directory.
descriptionNo
appendActionsNo
insertActionsNo
removeActionIdsNoids of top-level nodes (see cs_describe_workspace or the file)
addTriggerPhrasesNo
setTriggerPhrasesNo
removeTriggerPhrasesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. First observedv0.1.5

TDQS

A4.3/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it delivers: the most dangerous trait — 'The first call changes nothing: it returns the files it would write... Call it again with the same arguments plus confirm: true to write them' — is prominently disclosed. It also reveals the post-write validation and comment-header preservation, all non-obvious behaviors 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?

Four sentences with purpose front-loaded, then operation inventory, then the critical two-phase confirm flow. Every sentence earns its place; for a 12-parameter tool with nested oneOfs this is appropriately dense without bloat.

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?

Given the tool's complexity (12 params, deeply nested action oneOf, no output schema) the description covers the core usage well: all operation classes plus the confirm semantics, with a sensible deferral of the node spec to cs_add_topic. The remaining gaps — exact diff/return format and per-parameter syntax — are real but minor against the well-covered critical path.

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 description coverage is only 42%, so the description should compensate, and it partially does by mapping operations to parameters (rename, description, trigger set/add/remove, priority, node append/insert/remove-by-id). However, it adds no syntax or format detail for the undocumented params and defers the entire recursive action spec to a sibling pointer rather than enriching it here.

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?

The description opens with a specific verb and resource ('Change an existing topic in place') and enumerates the exact operations: rename, description, trigger phrases (set/add/remove), priority, append/insert nodes, and remove nodes by id. It explicitly contrasts with cs_add_topic via 'keeping its comment header' and 'existing topic', so an agent can reliably tell edit-from-add without inspecting schemas.

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?

Clear that this applies to modifying an existing topic in place, distinct from creation. It names the sibling (cs_add_topic) as the source of the node spec, which routes the agent correctly. It stops short of explicit when-not/alternative exclusions for edge cases, but context is unambiguous enough.

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