Microsoft 365 Agents Toolkit: building Teams apps

Three front ends over one set of capabilities

The Microsoft 365 Agents Toolkit exists to cover the end to end development journey for building agents or apps for Microsoft 365 Copilot, Microsoft Teams, and Microsoft 365. The README describes it as the best way to start creating, building, debugging, testing, and deploying, whether you are new or a seasoned developer.

The same capability set is offered through three front ends, and the choice is about how you like to work rather than about what you can build.

For JavaScript and TypeScript developers there is the extension for Visual Studio Code, which lets you scaffold, run, debug, and deploy custom Teams apps directly from the editor, with all the features of the command line tool integrated into the IDE plus easier access to samples, docs and tools.

For .NET developers there is the extension for Visual Studio.

For command line users, and for CI, there is the CLI, and the README is explicit about its audience: whether you prefer keyboard-centric developer operations, or you are automating your CI/CD pipeline, the CLI tool offers the same features as the IDE extensions. That equivalence is the point. A pipeline should not need a different toolkit from the one a developer uses locally, and the CLI is what makes the two the same thing.

The CLI is installed globally through npm, with `npm install -g @microsoft/m365agentstoolkit-cli`.

The feature list behind all three front ends is what defines the scope. It covers the Microsoft 365 platform extensibility surfaces, including Copilot for Microsoft 365, agent and chatbot experiences, tabs and message extensions for Microsoft Teams, and Office add-ins. It integrates with the Microsoft Agents SDK for building self-hosted agents, and with the Microsoft Teams SDK for building an intelligent chatbot in Microsoft Teams. It provides scaffolds for the extensibility interfaces and for common scenarios, rapid iteration with full stack debugging, hot reload, secure tunnelling and the Microsoft 365 Agents Playground, simplified single sign-on authentication, integrated support for hosting, data storage and serverless functions, and CI/CD actions for GitHub and Azure DevOps.

Seven packages, and the split between SDK, API and core

The repository table of packages explains the architecture better than any description of features could, because it shows which parts of the toolkit are yours to depend on and which parts are the implementation.

The Visual Studio Code extension is the IDE front end. The CLI is the command line front end. The SDK is described as the main code library encapsulating simple authentication for both client and server-side code tailored for Teams developers, which is the piece your application actually imports.

The API package is a collection of contracts supported by the IDE extensions and the CLI, and it exists so you can write plugins to extend the toolkit with new capabilities. That is a plugin boundary, in the same sense that an editor plugin boundary is: someone else can add a capability that the IDE and the CLI both pick up, without either of them having to know about it in advance.

The Core package centralizes the implementation of capabilities shared by the IDE extensions and the CLI, which is the other half of that design. If the API is the contract and Core is the implementation, then the two front ends stay thin and behave identically, and a plugin written against the API works the same in the editor and on the command line.

The Azure Functions support package covers the server-side case. It helps developers include server-side code in a Teams application backed by Azure Functions, and it adds support to simplify the integration of an authentication-aware Azure Function into the app, which is the part that is fiddly when the function has to call back into Microsoft 365 with the user's identity.

And there is a Spec Parser package, whose entry in the table is cut off in the copy available here, so the safest description is that the repository contains one more package whose purpose is not shown.

The separation matters for a team deciding what to depend on. A build pipeline that only needs the CLI depends on nothing of the toolkit's internals, and an application that needs authentication depends on the SDK, and a team extending the tooling depends on the API.

The repository is a pnpm workspace with strict engine floors

The root package.json is small, and the two things it does declare are worth reading closely, because they are the constraints a contributor works under.

The engines field sets Node 22.12.0 or newer and pnpm 8 or newer, and the packageManager field pins pnpm at 8.6.12.

  "engines": {
    "node": ">=22.12.0",
    "pnpm": ">=8"
  },
  "packageManager": "[email protected]",

The scripts show the shape of a monorepo build. The setup script installs and builds everything, and there are per-target setup scripts that build only the templates plus the packages a given target needs, one for the end to end tests, one for the CLI, and one for the Visual Studio Code extension. The build script runs the recursive build with a workspace concurrency of eight, and the watch script runs the watch task in parallel across workspaces.

  "scripts": {
    "setup": "pnpm install && pnpm run build",
    "setup:e2e": "pnpm install && pnpm --filter templates --filter @microsoft/teamsfx-test... build",
    "build": "pnpm -r --workspace-concurrency=8 run build",
    "precommit": "lint-staged",
  },

The tooling is a mix of a workspace manager and a release manager. pnpm provides the workspace and the filtering, lerna is in the dev dependencies for release orchestration, husky installs the git hooks, commitlint and its conventional config enforce the commit message format, and lint-staged runs on precommit. The overrides block in the manifest is the other thing that catches the eye, since it pins a long list of transitive dependencies, among them hono, axios, minimatch, lodash, form-data, handlebars, js-yaml, and glob, to specific versions.

That override list is a security practice rather than a style choice. It forces the versions of the dependencies that the templates and the tooling pull in, so a build of the toolkit does not silently change behaviour when a transitive package publishes a new release.

Local development, the Agents Playground, and the deployment path

The part of the toolkit that is hardest to build yourself is the loop between editing the app and seeing it running inside the Microsoft 365 surface, and that is what the feature list leans on.

Rapid iteration comes with full stack debugging, hot reload, secure tunnelling, and the Microsoft 365 Agents Playground, which the README links as the tool for testing a Teams app. The tunnelling piece is the practical enabler: without a public endpoint, a locally running tab or a bot callback cannot be reached by the Microsoft 365 host, and the alternative, a fixed public address, is not something you want in a development loop.

The rest of the journey is covered by the scaffolding for the extensibility interfaces and common scenarios, the simplified single sign-on authentication, and the integrated support for hosting, data storage and serverless functions. The Azure Functions package is the concrete form of the serverless half, since it handles the authentication-aware function integration rather than leaving you to hand the identity across the boundary.

For delivery, the toolkit publishes CI/CD actions for GitHub and Azure DevOps, and the CLI is explicitly described as the tool to use when automating a pipeline, which is the same feature set as the editor but scriptable. A team that develops in Visual Studio Code and deploys from GitHub Actions is using the same toolkit on both sides, and the CLI is the piece that makes that consistent rather than two parallel toolchains.

The tests are a separate concern in the repository, with an evals directory and per-target setup scripts that build the templates together with the test package before the end to end run, which is what you would expect from a project whose output is a set of scaffolds: the test has to check that the scaffold actually builds.

Support, licensing, and a release stream that is mostly automated

Three administrative facts are worth reading, because they tell you what kind of dependency this is.

The support policy is stated in one line: the toolkit products will follow the Modern Lifecycle Policy and extended support as described in the lifecycle and support document. That is a Microsoft-wide commitment rather than a guarantee about this repository, and the README links the policy rather than restating the terms.

The licence is the one that needs reading rather than assuming. The repository is classified as having a custom licence that GitHub cannot classify automatically, and there is a LICENSE file at the root, alongside a separate LICENSE-TEAMS-APP-TEST-TOOL file, which suggests that the test tool component is under different terms from the rest.

The release stream is what tells you about the pace. The default branch is dev, and the recent releases are named after the pipeline rather than after a version number of the product, for example npm-packages-39234577699-1 from 2026-10-19, templates-v4 at 6.19.2026101507 from 2026-10-15, and npm-packages-38717451891-1 from 2026-10-15. So the individual packages are published from the monorepo automatically as they change, and the release names are generated identifiers rather than semantic versions.

That is consistent with the roadmap section, which says the toolkit for Visual Studio, Visual Studio Code, and the CLI will be updated regularly with new features and bug fixes. The README also points at two changelogs, a Changelog and a Prerelease Changelog, which is the detail to act on: there is a pre-release channel, and the scaffolding and the capabilities in it can change before they land in the stable changelog.

For feedback there are four routes, and they are worth noting because they are all live: a Stack Overflow tag for the toolkit, a feature request issue template, a bug report issue template, an email address for the product team, and a separate path for security issues through the Microsoft Security Response Center.

Editorial conclusion

The Microsoft 365 Agents Toolkit fits a team building a Teams tab, a message extension, a Copilot agent, or an Office add-in who wants the scaffolding, the authentication plumbing, and the deployment path in one place rather than assembled from separate documentation. It does not fit a team that has already standardised on a different toolchain for those surfaces, since the toolkit exists to make the Microsoft supported path fast. Verify first that the surfaces you need are supported, since the feature list is specific about which ones they are, that your environment meets the tool requirements the repository declares, Node 22.12 or newer and pnpm 8 or newer, and that you read the prerelease changelog as well as the stable one, because the extension ships pre-release builds that can change the scaffolding your team depends on.

Frequently asked questions

Official sources

1. Issues
2. OfficeDev/microsoft-365-agents-toolkit on GitHub
3. README
4. Releases