Skip to main content
Glama
jgt87

Copilot Studio MCP

by jgt87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Back up the tenant configuration to files

cs_backup_tenant

Capture a tenant's Power Platform configuration to local files for reference, diffing and source control, including environments, DLP policies, agents and backups, without changing tenant settings.

Instructions

Write the tenant's Power Platform configuration to local files for reference, diffing and source control: tenant settings, environments, DLP policies, environment groups, service principals, registered applications and app templates, plus per environment its details, solutions, agents, connections, security roles and platform backups. Read-only for the tenant; it only writes files. Runs as the admin account: pass 'profile' or set CPS_ADMIN_PROFILE. Each capture is independent, so a command the account cannot run is reported in 'skipped' and the rest still completes.

Input Schema

NameRequiredDescriptionDefault
dirYesFolder to write the backup into (created; existing files with the same names are overwritten)
profileNopac auth profile of the admin account; default CPS_ADMIN_PROFILE, then the active profile
clientIdNoEntra app (client) id for MSAL. Defaults to CPS_CLIENT_ID, then the first-party VS Code id.
tenantIdNoEntra tenant id. Defaults to the workspace sync metadata, then CPS_TENANT_ID.
environmentsNoEnvironments to detail; default: every environment 'pac admin list' returns
includeRolesNoDefault true: the security roles of each environment
includeBackupsNoDefault true: the platform backups of each environment
maxEnvironmentsNoDefault 50
includeDataverseNoDefault true: flows, connection references, environment variables and agents per environment, when a Dataverse sign-in is cached (cs_login)
includeEnvironmentsNoDefault true; false captures tenant level only

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.8
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / environments / items / additionalProperties
      Removed value: -false
  2. First observedv0.1.5

TDQS

A4.1/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 declares the tenant is never mutated, that only local files are written, that it runs as the admin account (profile/CPS_ADMIN_PROFILE), and that failures are isolated per capture and surfaced in 'skipped'. Missing only secondary traits like runtime or rate limiting.

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 action and keeps to four sentences. The long artifact enumeration in sentence one is dense but earns its place by defining capture scope; nothing is obviously padding, though the list could be trimmed.

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 10-parameter tool with full schema coverage and no output schema, the description covers purpose, safety profile, auth prerequisite and partial-failure semantics adequately. It stops short of explaining the on-disk output layout an agent might want when chaining into a diff or source-control step.

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 100%, so the schema already documents every parameter including defaults and the 'created/overwritten' behavior of 'dir'. The description adds little beyond restating the profile handling, so the baseline of 3 applies.

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 ('Write the tenant's Power Platform configuration to local files') and enumerates the captured artifacts down to per-environment details, solutions, agents and backups. This clearly separates it from siblings like cs_snapshot_environment or cs_admin_backup_environment, which act on a single environment.

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?

Gives concrete usage context ('for reference, diffing and source control') and clarifies scope (tenant-wide, read-only for the tenant). It does not, however, explicitly say when to prefer this over cs_snapshot_environment/cs_admin_backup_environment, so the agent must infer the boundary.

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