Mastering Extensibility: Agent 365 Tools Registry & BYO MCP

If you’ve been building and evaluating agents recently, you’ve likely noticed a significant shift in the Agent 365 experience: the new Tools menu in the Microsoft 365 admin center. It’s quietly changing how we orchestrate agentic automation. We’re moving from rigid, predefined bot logic to flexible, LLM-driven execution — agents are handed a robust set of governed tools and the autonomy to decide when to use them.

At the center of this shift is the Model Context Protocol (MCP). Microsoft ships a catalog of first-party servers (Outlook, Teams, SharePoint & OneDrive, Word, Dataverse, Copilot Search, and more), and third-party partners are adding their own. But the real power for builders is the Bring Your Own (BYO) MCP server capability and the emerging Copilot Cowork plugins ecosystem.

This is a deep dive into how these features work, how to deploy them step by step, and the governance model you need to put in place before you do. Where it helps, I’ve included the actual commands, a working manifest, and the gotchas I hit so you don’t have to.

TL;DR — what you’ll walk away with

• Two ways to give an agent tools: add a first-party/catalog server, or register your own remote MCP server (BYO).
• A prerequisites checklist so registration doesn’t fail on step one.
• A real register-external-mcp-server command plus a working JSON manifest.
• The admin approval + Entra permission flow, and how to verify it worked.
• Where the observability lives (hint: Microsoft Defender), and a governance checklist you can adopt today.

1. The Centralized Tools Registry and the Agent 365 SDK

Think of the Tools registry as the single pane of glass for your organization’s AI tool inventory — the same way the Agent Registry is the source of truth for the agents themselves. You’ll find it in the Microsoft 365 admin center under Agents > Tools, split into two tabs:

• Registry — every tool/MCP server available in your tenant, with columns for Name, Status (Available / Blocked), Type (e.g., MCP Server), and Publisher (Microsoft or third-party). You can filter by status or publisher, and Block / Unblock any tool from here.
• Requests — pending tool registrations from your developers, waiting for an admin to review and approve.

Having a centralized repository for every MCP server dramatically accelerates code-centric agent development. When you build with the Agent 365 SDK, you no longer hand-wire external API calls or manage raw token exchange for every new service. You reference a registered server’s tool, the runtime pulls the tool definitions, handles routing through the Agent 365 Tooling Gateway, and equips your agent to invoke it under tenant governance.

The catalog path, end to end (first-party / Microsoft-managed servers):

# 1. Discover the servers available to your tenant
a365 develop list-available

# 2. Add one (or more) to your agent — this only updates ToolingManifest.json
a365 develop add-mcp-servers mcp_MailTools

# 3. Verify what's configured locally
a365 develop list-configured

That second command is the part people misread: add-mcp-servers does not grant any permissions. It only writes the server into a local ToolingManifest.json in your project folder. Permissions are a separate, admin-driven step:

# First-time setup creates the blueprint AND applies MCP permissions
a365 setup all

# If the blueprint already exists, a Global Administrator runs this instead
a365 setup permissions mcp

Only after that consent does the server’s tools light up for your agent. From there, your code loads the manifest, registers the tools with your orchestrator, and invokes them during execution. Conceptually:

list-available  →  add-mcp-servers  →  ToolingManifest.json
                                            │
                        a365 setup all / setup permissions mcp  (admin consent)
                                            │
                 load manifest in code  →  register tools  →  agent invokes tools

2. Deploying a BYO MCP Server via CLI

You aren’t limited to the curated catalog. With BYO MCP server, you can route a custom, internally hosted MCP server through the same governance and observability plane. The problem it solves is real: enterprises already run internal MCP servers, but those typically sit outside any governance boundary — no admin visibility into exposed tools, no policy enforcement, no telemetry for security teams. BYO fixes that by putting your server behind the Agent 365 Tooling Gateway.

A running example I’ll use throughout: a custom “Insights Kit” server that powers an automated weekly newsletter, giving an agent read access to internal reporting systems.

Prerequisites (check these first — registration fails fast if you skip them)

• Agent 365 CLI version 1.1.165-preview or greater (a365 --version to check).
• .NET 8.0 SDK or higher installed.
• The Agent 365 service principal provisioned in your tenant. If you can’t find a service principal for appId ea9ffc3e-8a23-4a7d-836d-234d7c7565c1, it isn’t provisioned yet — a Global Administrator runs the one-time New-Agent365ToolsServicePrincipalProdPublic.ps1 setup script to create it.
• A publicly reachable MCP server endpoint (streamable HTTP, the URL typically ends in /mcp).
• The server configured with one of the supported authentication types: NoAuth, APIKey (header or query), ExternalOAuth, or EntraOAuth.

Register the server

Unlike the catalog flow, BYO uses the develop-mcp command group. You can pass everything inline, or — cleaner and source-controllable — point it at a JSON file:

a365 develop-mcp register-external-mcp-server -f insights-kit-manifest.json

Here’s a complete, working manifest for the Insights Kit example. This is the anatomy of your tools the LLM reasons over — note how much weight the descriptions carry, since they’re the only signal the model has for when to call each tool:

{
  "serverName": "ext_InsightsKit",
  "serverUrl": "https://insights.contoso.com/mcp",
  "authType": "EntraOAuth",
  "description": "Internal reporting tools that power the weekly Insights newsletter.",
  "publisherName": "Contoso",
  "tools": [
    {
      "name": "get_weekly_metrics",
      "description": "Return key business metrics (revenue, active users, NPS) for a given ISO week. Read-only."
    },
    {
      "name": "list_report_sources",
      "description": "List the internal report datasets the newsletter can draw from, with last-refresh timestamps."
    }
  ],
  "remoteScopes": "api://contoso-insights/.default",
  "externalOAuth": null,
  "apiKey": null
}

Swap authType and the matching block depending on how your server authenticates:

What happens under the hood:

• The CLI parses the manifest and summarizes the tools and auth routing.
• It creates the Microsoft Entra app registrations the platform needs and wires them to Agent 365.
• It pushes the server definition into the Agent 365 control plane and submits it for admin review — where it surfaces on the Requests tab.

3. The Admin Center Governance & Approval Workflow

Security is paramount once you let an LLM execute code and change state. So a developer running the CLI does not make the tool available organization-wide. Registration only creates a request.

The request lands on the Requests tab in the Microsoft 365 admin center, where an admin with rights to manage agent tools (typically a Global Administrator) reviews:

• The server details and the declared tools (names + descriptions) being exposed.
• The remote URL of the MCP server.
• The Entra application generated during registration and the permissions it’s requesting.

The approval step is where the Microsoft Entra permissions for the server are actually granted and mapped to the Agent 365 application. Only upon explicit approval can agents bind to the server and invoke its tools. (Note: the old develop-mcp approve and develop-mcp block CLI commands have been retired — approval and blocking now happen only in the admin center.)

How to verify it worked:

1. In the admin center, confirm the server moved from Requests to Registry with Status: Available.
2. Confirm the Entra permissions were consented on the Agent 365 app.
3. Bind to the server from a supported surface (next section) and make a real tool call against the live endpoint.

4. Where you can actually use it (supported surfaces)

This is an easy detail to miss and a frustrating one to discover late. An approved BYO server works on a specific set of client surfaces today:

• ✅ Copilot Studio
• ✅ Visual Studio Code
• ✅ Claude Code
• ✅ GitHub Copilot CLI
• ❌ Azure AI Foundry — not yet supported
• ❌ Microsoft 365 Declarative Agents — not yet supported

If your target runtime is Foundry or a declarative agent, hold off on the BYO path for that workload until support lands.

5. Copilot Cowork Plugins: Bundling Skills in a Managed Architecture

Alongside BYO servers, a Plugins tab has appeared in the registry. These began showing up around the general availability of Microsoft 365 Copilot Cowork (GA’d in June 2026).

Plugins act as logical bundles of MCP servers and specific skills. What’s architecturally interesting is where they live: not in a dedicated Cowork section, but directly inside the Agent 365 registry.

That placement is a deliberate signal about cross-agent reusability. Copilot Cowork runs as a managed service inside a Linux-containerized service boundary — it’s not a customizable local environment. By surfacing these plugins at the Agent 365 control-plane level, Microsoft is paving the way for builders to drop pre-packaged skill bundles directly into their own custom agents, cutting the time it takes to assemble complex, multi-step orchestration.

6. Security, Permissions, and Default Behaviors

As agents gain autonomy, the shift from hardcoded logic to LLM-driven execution demands strict governance. Two things deserve your attention.

Know which authorization model your agent uses. It’s not a single story:

• On-Behalf-Of (OBO) / delegated — the agent acts as the signed-in user. It can only do what that user is already permitted to do (so an admin action still requires the user to hold the admin role). This is the right default for user-scoped tasks like reading the user’s calendar or sending mail as them.
• Service-to-service (S2S) / application — the agent acts as its own identity with application permissions, independent of any signed-in user. Use this for unattended, tenant-wide work — and treat it with far more caution, because the user-as-a-safety-net assumption no longer holds.

Mind the high-impact administrative servers. The catalog includes governance-relevant servers such as the Admin tools MCP server for the Microsoft 365 admin center, the Windows 365 for Agents MCP server, the Dataverse MCP server, and the preview Microsoft MCP management server. These don’t just run Get requests — they expose Set, Update, and deep configuration capabilities. Even when an administrator is the one prompting, the risk of an LLM hallucinating a parameter during an automated state change is non-zero. Scope access to these deliberately.

The registry’s default posture — and why you should tighten it

The two paths have different default postures, and it’s worth being precise:

• Catalog (Microsoft + third-party) servers lean toward opt-out: they can become available, and your lever is the Block action plus the setting that controls whether agents can discover new integrations without explicit approval. Left unattended, broad access can accrue.
• BYO servers are opt-in by design: nothing is usable until it’s registered, reviewed, and explicitly approved with consented Entra permissions.

Make it observable

“Fully observable” only counts if you know where to look. Because BYO servers route through the Tooling Gateway, your security team can monitor MCP server activity and individual tool invocations through Microsoft Defender advanced hunting — the place to build queries for compliance reporting and anomaly detection on what your agents are actually doing.

Quick reference: catalog vs. BYO

Future Outlook

The expansion of multi-use plugins and skill bundles will sharply accelerate developer velocity, and the lines between Cowork, Agent 365, and custom agents will keep blurring as those bundles become reusable building blocks. As the frameworks mature, expect deeper integration with autonomous-execution scenarios (for example, Microsoft Scout) leaning directly on this Tools registry as their capability layer.

Two things will separate teams that scale cleanly from teams that firefight: getting the CLI deployment and Entra integration right, and putting per-agent, least-privilege governance in place before the catalog fills up. Master those now — while BYO is still in preview and the blast radius is small — and your enterprise automation stays secure, scalable, and genuinely observable as it grows.

Note: BYO MCP server is a preview capability delivered through the Microsoft 365 Frontier program and requires a Microsoft 365 Copilot license. Commands, version numbers, and supported surfaces reflect the state of the platform as of June 2026 and will evolve — always confirm against current Microsoft Learn documentation before deploying.