Skip to main content
Glama
jgt87

Copilot Studio MCP

by jgt87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Sign in (MSAL)

cs_login

Acquire a Microsoft Entra token so Copilot Studio cloud tools can run. Use it to sign in interactively via browser or with a device code before calling evaluation, environment, agent, publish, chat, or drift tools.

Instructions

Acquire a Microsoft Entra token for the cloud tools (evaluations, environments, agents, publish, chat, drift). mode 'interactive' (default) starts a browser sign-in and returns within waitSeconds: status 'ok' when it completed, otherwise status 'pending' with the sign-in URL. If no browser opened, show the user that URL to open on the machine running this server; the page redirects to localhost and the login completes in the background (check cs_login_status or call any cloud tool). mode 'device_code' returns a code to enter at microsoft.com/devicelogin (some tenants block this flow). Not needed for pac commands, which use 'pac auth create'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoDefault interactive
scopeNoWhich resource to pre-authorise. Default powerplatform (evaluations); 'flow' is the Power Automate service used by the flow-run tools; 'graph' reads the Microsoft 365 agent catalogue and 'graph_write' also blocks and reassigns. Others are acquired silently later when possible.
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.
workspaceNoPath to (or inside) the agent workspace. Defaults to CPS_WORKSPACE or the current directory.
openBrowserNointeractive: try to open the browser from the server (default true). Set false when the server runs where no browser can appear.
waitSecondsNointeractive: how long to wait for the sign-in before returning 'pending' (default 15; keep it below the client's tool timeout)
dataverseUrlNoRequired when scope is dataverse, e.g. https://org.crm.dynamics.com

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

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

With no annotations and no output schema, the description carries the full behavioral burden and does so well. It explains what interactive mode returns ('ok' or 'pending' with sign-in URL), the localhost redirect and background completion, the fallback of showing the URL to the user, device code behavior and tenant restrictions, and how to check progress via cs_login_status or any cloud tool.

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?

The description is front-loaded with purpose and mode behavior, and most sentences add practical value. It is somewhat dense and run-on across parentheticals, but the length is justified by the complexity of an auth flow with two modes and a redirect fallback.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema and the eight optional parameters, the description provides the missing context an agent needs: authentication purpose, mode behaviors, return statuses, browser/device-code outcomes, and sibling routing. Nothing critical for correct invocation is omitted.

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 description coverage is 100%, so the baseline is 3. The description adds useful meaning beyond the schema for mode and waitSeconds — specifying interactive default behavior and the returned status — but leaves details for scope, clientId, tenantId, workspace, openBrowser, and dataverseUrl largely to the schema.

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 states a precise verb and resource — 'Acquire a Microsoft Entra token' — and names the cloud tools it unlocks (evaluations, environments, agents, publish, chat, drift). It also explicitly distinguishes itself from pac commands, which use 'pac auth create', so an agent can tell when this tool applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It establishes when to use the tool (cloud operations requiring an Entra token), gives mode-specific guidance for interactive versus device_code flows, and states an exclusion: 'Not needed for pac commands, which use pac auth create.' That covers when, when-not, and the relevant alternative.

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