The next bottleneck for agent builders is not finding another model or another tool wrapper. It is getting tool access into production without turning every release into a tenant admin scramble, a permission mismatch, or a silent capability drift. Microsoft Agent 365's tooling documentation is useful because it exposes the shape of this problem in plain operational terms: discover MCP servers, write a tooling manifest, get OAuth2 permissions applied by an administrator, register the tools in the agent runtime, then test the whole path with a mock server before touching real external systems. That is not a vendor feature story. It is a signal that agent tooling is moving from improvised integration code to release-managed infrastructure.
Key Takeaways
- MCP server adoption is becoming a lifecycle problem: discovery, manifest generation, consent, runtime registration, and invocation all need to be tracked as separate steps.
- A tooling manifest is not the same as permission. Builders should design checks that detect when a tool is configured locally but not granted in the deployed blueprint.
- Identity strategy matters early. Agentic authentication and On-Behalf-Of user delegation create different blast radii, audit trails, and failure modes.
- Mock tooling servers are not just convenience for offline work. They are a way to build deterministic tests for tool routing, schema handling, and recovery behavior.
- Enterprise agent teams should treat tools like production dependencies, with version review, permission review, contract tests, and rollback plans.
Source Card
Add and manage toolsThe Microsoft Learn page describes how the Microsoft Agent 365 SDK uses MCP servers as external tools, including CLI discovery, ToolingManifest.json generation, admin consent for OAuth2 permissions, identity setup, and a mock tooling server. The important builder signal is the separation between local configuration and tenant-level authorization.
Microsoft Learn
The real shift: tools are now deployable infrastructure
Many agent prototypes still treat tools as a list of callable functions inside an orchestrator. That works until the agent needs enterprise mail, files, calendar, tickets, CRM, or internal data systems. At that point the tool is no longer a helper function. It is a dependency with identity, permission, network behavior, audit requirements, and failure semantics. The Agent 365 flow makes this explicit through a manifest-driven process. The CLI can discover and add MCP servers, but the generated manifest is only one artifact. A separate setup step applies permissions to the agent blueprint, and that step requires a Global Administrator. This split is the part builders should pay attention to, because it mirrors how production organizations actually fail: code says a tool exists, the runtime attempts to use it, but the tenant has not granted the permission, or the permission was granted for a different project path, environment, or blueprint.
| Signal | Why it matters |
|---|---|
| MCP servers are discovered and added through a CLI | Tool selection becomes repeatable, but only if teams commit the manifest, review changes, and stop treating local tool additions as invisible developer state. |
| ToolingManifest.json is generated in the project folder | The manifest can become the contract between engineering, security, and operations. It should be reviewed like infrastructure configuration, not ignored like a temporary build artifact. |
| Admin consent is separate from adding servers | This creates a predictable gate for tenant permissions, but it also creates a deployment gap that must be checked before release. |
| A mock tooling server can simulate tool calls | Teams can test routing, argument formation, error handling, and edge cases without sending live requests to production systems. |
The manifest is a contract, not a magic switch
The most practical lesson in the source is the warning that adding an MCP server updates the manifest but does not grant permissions to the blueprint. For builders, this is the difference between a configuration file and an operational entitlement. If you blur that line, your agent will pass local checks and fail in production with authorization errors, missing tool visibility, or inconsistent behavior across tenants. The safer pattern is to make the manifest the input to a release workflow. A pull request that changes the manifest should trigger a security review. The deployment process should verify that the blueprint has the expected permissions after admin consent. Runtime startup should validate that required tools are registered and reachable. The orchestrator should distinguish between tool absence, permission denial, input validation errors, and downstream service failure. Those are different incidents. They need different remediation paths. A permission problem should not look like a model reasoning problem in your telemetry.
Builder note
Add a preflight gate before each environment promotion. Compare the committed tooling manifest against the permissions visible to the deployed agent blueprint, then fail the promotion if a required MCP server is configured but not authorized. This is boring plumbing, but it prevents the worst class of agent demos: the model chooses the right action, the orchestrator calls the right tool, and the platform refuses the request because consent never caught up with configuration.
Identity choice is an architecture decision
The Microsoft page points to two paths: agentic authentication, where an agent identity is registered and can access tools through that identity, and On-Behalf-Of authentication, where the agent exchanges a delegated user token to act for the user. Builders should not pick between these based only on which sample is easier to run. Agentic identity is attractive for autonomous or scheduled work, because the agent can have its own audit footprint and permissions. It also raises hard questions about scope creep and standing access. OBO is attractive when user context should constrain the action, such as reading a mailbox or updating a document only when the user could have done so. It can reduce overbroad agent privileges, but it ties behavior to token lifetime, user consent, and the permissions of whoever is in the loop. A serious agent platform may need both patterns, with policy deciding which tools can run under agent identity and which require delegated user context.
- Classify each tool by authority: read-only lookup, user-scoped action, tenant-scoped action, financial or destructive action, and external write.
- Decide whether the tool should run under agent identity, delegated user identity, or a step-up approval path.
- Record the required OAuth2 scopes next to the MCP server entry, not in a separate tribal-knowledge document.
- Create a local mock response set for common success, denial, malformed input, rate limit, and downstream outage cases.
- Write contract tests that assert the orchestrator sends the expected arguments to each tool and handles structured errors without retry storms.
- Log tool selection, identity mode, permission outcome, and downstream status as separate fields so operators can separate reasoning defects from infrastructure defects.
- Plan removal as carefully as addition. Removing an MCP server should trigger tests for fallback behavior, not just delete an entry from the manifest.
The new agent ops failure mode is not that the model cannot decide what to do. It is that the model decides correctly, then the tool plane is misconfigured, overpermissioned, untested, or missing.
The mock tooling server detail is easy to underrate. It is actually one of the strongest pieces of builder infrastructure in the flow. Agents are hard to test because the model is probabilistic and the outside world is messy. Mock servers let teams isolate the tool plane from live systems and make at least part of the stack deterministic. That means you can test whether the agent asks for the right tool, whether the orchestrator translates the request into valid arguments, whether the response parser survives unexpected shapes, and whether fallback logic works when a tool is unavailable. The risk is false confidence. A mock server that only returns happy paths will train the team to ship fragile agents. The useful version includes hostile fixtures: permission denied, partial data, slow responses, duplicate records, stale tokens, ambiguous results, empty search returns, and payloads that are valid but semantically unhelpful.
For adoption, start with a small set of MCP servers and a strict promotion path. Put the tooling manifest under version control. Require review for every new tool. Use the mock server in CI for deterministic tests. Keep a tenant admin runbook for permission setup, including which project folder and manifest are the source of truth. Add startup validation so the agent reports missing tools before a user asks for work. Most importantly, design the user experience for tool uncertainty. If a permission is missing, the agent should say it cannot access that capability and route to remediation. If a tool times out, it should not invent a result. If a tool returns more authority than the task requires, the orchestrator should still apply local policy before acting. Tooling turns agents into operators. Operators need controls.
- Microsoft Learn, Add and manage tools, https://learn.microsoft.com/en-us/microsoft-agent-365/developer/tooling