CLI for Microsoft 365 for coding agents

When a coding agent needs information from an organization's Microsoft 365 environment, called a tenant, while working in a terminal, CLI for Microsoft 365 provides commands for services such as Teams, SharePoint, Planner, Outlook, and Microsoft Entra ID. The command is m365. It returns results as JSON, a structured text format. The agent can use JMESPath, a query language for selecting fields from JSON, to choose which data to use.

The CLI runs on different operating systems and manages Microsoft 365 settings and SharePoint Framework projects. One read-only task is to check Microsoft 365 service health and return the results as JSON. The CLI for Microsoft 365 documentation covers installation and sign-in, and it has a page for each command.

Install and sign in

The CLI needs Node.js. Install it globally with npm, as the installation guide shows:

npm install -g @pnp/cli-microsoft365

The package provides the m365 command. To sign in, the CLI needs a Microsoft Entra app registration in your tenant. The m365 setup command can create one and store its app ID and tenant in the CLI configuration. After that, sign in from the shell:

m365 setup
m365 login

m365 login uses the device code flow by default. It shows a code that you enter at a Microsoft sign-in page in your browser. The sign-in guide also covers certificate and other non-interactive sign-in methods. The app that m365 setup creates can have a wide set of permissions. For a production tenant, the guide to using your own identity explains how to register an app with only the permissions you need.

Sign-in connects the CLI to Microsoft 365 through an account, using the permissions available to that account. Do not put passwords, access tokens, or other credentials in the agent's prompt. An operator should sign in in the environment where the agent runs and check that the account has the permissions the command needs. Each command’s documentation page has a permissions section.

Installing the CLI and signing in happen locally, but signing in gives the CLI access to a Microsoft 365 tenant. Commands that retrieve tenant information send network requests to Microsoft services.

Check service health

tenant serviceannouncement health list gets the health report of all subscribed services for the tenant. Its command page lists the Microsoft Graph permission ServiceHealth.Read.All. Run it with JSON output:

m365 tenant serviceannouncement health list --output json

This command contacts Microsoft 365 and returns service-health information that the signed-in account can access. It reads service status and does not change tenant settings. The response depends on the tenant and current service data, so have the agent inspect the JSON instead of assuming which incidents or fields it contains. Add --issues to include the issues reported for each service, which the command returns only in JSON mode.

The --output option accepts json, text, csv and md, as the output mode guide shows. JSON is the default. The interactive preset of m365 setup changes the default to text, so keep --output json in commands for the agent. The CLI's --query option uses JMESPath, a language for selecting data from JSON. Have the agent request the full JSON result first and inspect its field names. It can then build a query for the fields it needs. Do not ask it to filter using guessed property names, because each command's response determines which fields are available.

Give the agent a bounded task

A coding agent can run the service-health command, then save a local report summarizing the returned services or incidents. The command reads tenant data over the network. When the agent saves a report, it changes only the local workspace. If the agent proposes a tenant update, review the command’s documentation before approving the change, and confirm which tenant the CLI is signed in to.

A practical prompt is:

Run m365 tenant serviceannouncement health list --output json using the existing signed-in account. Summarize the returned service status in service-health.md. Do not run commands that change Microsoft 365 settings. If the command fails, report the error without attempting another sign-in.

The prompt names the command, limits the work to reading data and writing a local report, and tells the agent what to do on failure. It does not provide credentials.

Know what the CLI can access

A coding agent with shell access can run any command that its environment and signed-in account allow. The prompt alone does not limit the account’s Microsoft 365 permissions. Keep credentials and tenant access the agent does not need out of its environment, and check each command’s permission requirements before granting access.

The agent runs CLI for Microsoft 365 as a command-line program. The project also documents a separate CLI for Microsoft 365 MCP Server, which lets an assistant call CLI commands through the Model Context Protocol (MCP). That server does not sign in for you. It uses the session from m365 login. You do not need it for the example above. For other developer tools, see the Awesome CLI directory.