Skip to main content
Glama
jgt87

Copilot Studio MCP

by jgt87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Add a topic

cs_add_topic

Create a Copilot Studio topic from a declarative spec with trigger phrases and actions, previewing file changes for approval before writing them.

Instructions

Create topics/.topic.mcs.yml from a declarative spec: trigger phrases (or a system trigger) plus message / question / condition / redirect / setVariable / searchKnowledge / http / invokeFlow / end / raw nodes. Validates the result. Push to apply. 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
nameYes
actionsYes
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.
priorityNo
overwriteNo
workspaceNoPath to (or inside) the agent workspace. Defaults to CPS_WORKSPACE or the current directory.
descriptionNo
triggerKindNoSystem trigger instead of phrases
triggerPhrasesNoUser phrases that start the topic (OnRecognizedIntent)

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.1/5.0
Behavior5/5

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

With no annotations to carry safety information, the description explicitly discloses the most important behavior: the first call writes nothing, returns a diff for approval, and only a confirm:true call performs the write. It also states validation and push-to-apply semantics, which is strong behavioral disclosure for a mutation tool.

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

Conciseness5/5

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

The entire workflow is compressed into four sentences with no filler; the file path and side-effect warning are front-loaded. Every sentence adds operational information an agent cannot get from the schema alone.

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 complex 9-parameter, no-output-schema tool, the description covers the key workflow, return shape (diff), side-effect boundary, and follow-up confirm call. It is not exhaustive—overwrite behavior, priority, and some valid action types are absent—but the main call path is complete enough for an agent to invoke it safely.

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 only 44%, so the description must compensate; it adds meaning to name (file path) and clarifies triggerKind vs triggerPhrases and the confirm flow. However, it leaves priority, overwrite, description, and the full actions structure under-explained, and its list of action node types omits card, transfer, and endConversation, so it only partially compensates for the schema gaps.

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?

The description names a concrete deliverable ('topics/<name>.topic.mcs.yml') and an explicit action ('Create'), and it summarizes the declarative action kinds, so an agent can tell this is the topic-creation tool. It does not explicitly contrast itself with sibling cs_edit_topic or other add-tools, so it stops short of full sibling differentiation.

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?

It clearly signals when to use it (creating a topic from a declarative spec) and gives the required two-call preview/confirm workflow, plus the push-to-apply step. It does not state when not to use it or name alternatives such as cs_edit_topic, but the context is clear 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