Skip to main content
Glama
jgt87

Copilot Studio MCP

by jgt87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Read tenant settings

cs_admin_list_tenant_settings

List tenant-wide Power Platform settings for governance, sharing, support, and licensing, and optionally save them as JSON for source control reference.

Instructions

The tenant-wide Power Platform settings (governance, sharing, support, licensing). With settingsFile, pac writes them as JSON to that path; that file is the reference copy to keep in source control. Runs 'pac admin list-tenant-settings' with the active pac auth profile.

Input Schema

NameRequiredDescriptionDefault
cwdNoWorking directory for pac (for project commands: the solution project folder)
profileNopac auth profile to run as: the admin account for tenant commands. Defaults to CPS_ADMIN_PROFILE for admin commands and CPS_PAC_PROFILE otherwise, then the active profile. cs_init lists the profiles.
backgroundNoRun in the background and return a jobId immediately, for a command that takes longer than the client will wait. Poll cs_job_status.
settingsFileNoWrite the settings to this .json file
timeoutSecondsNoDefault 600

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.8
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv0.1.5

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden. It discloses the side effect of writing JSON to settingsFile, the source-control purpose of that file, and that it runs with the active pac auth profile — useful behavioral context. It does not state read-only/non-destructive guarantees explicitly (implied by 'list') or permission requirements.

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?

Three tightly packed sentences, front-loaded with the resource and scope, then the settingsFile behavior, then the underlying command. No filler; every sentence contributes.

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 read tool with no annotations and no output schema, the description covers purpose and the file-output path well. It does not explain what is returned when settingsFile is omitted, which is the remaining gap given the absence of an output schema.

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 100%, so the baseline is 3. The description adds meaning beyond the schema for settingsFile by explaining that pac writes JSON there and that the file is the reference copy for source control — more than the schema's terse 'Write the settings to this .json file'.

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/resource ('tenant-wide Power Platform settings') and enumerates the covered categories (governance, sharing, support, licensing), plus names the underlying command 'pac admin list-tenant-settings'. An agent can distinguish this read tool from the write counterpart cs_admin_update_tenant_settings.

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?

Implies usage through the settingsFile note (keep the file in source control), which gives context for a common workflow, but never states when to use this vs. cs_admin_update_tenant_settings or other admin listing tools. Usage is inferred rather than prescribed.

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