Microsoft caps agent tool discovery and separates workflow users Microsoft caps agent tool discovery and separates workflow users

Discovery gets a stopping point

The Model Context Protocol lets an agent discover the tools and prompts a connected server offers. Those catalogs can arrive across many pages. Microsoft now places defaults on both the page count and the total items collected, making discovery a bounded operation. A server offering a larger catalog can therefore require an explicit configuration change after an upgrade. Developers can raise either limit, and trusted servers can have those limits disabled. This changes the contract between an application and a tool server: discovering everything is no longer an open-ended task by default.

A failed refresh keeps the old catalog

The catalog update is atomic. If a refresh fails, the framework retains the previous complete snapshot, including the tool annotations used for security labels. This avoids replacing a usable catalog with an incomplete collection from a failed fetch. Framework-created clients also receive a thirty-second default request timeout. Clients supplied by the application retain their own transport and timeout rules. These are distinct controls: the catalog limits bound discovery size, while request timing limits individual waits. The release notes also distinguish separate admission and recovery budgets from a single deadline for the entire operation.

A new workflow can still share old state

A separate change addresses live workflow ownership in AG-UI endpoints, which connect an agent backend to a user interface. Microsoft's implementation notes describe how a shared executor retains conversation history, pending approvals and standing approval rules between runs. Building a new workflow around that same executor can carry the earlier caller's state into another authorization scope. The new guard binds executors and their sessions to one scope. A conflicting call stops before reaching the model. Microsoft recommends factories that create fresh workflows, executors and sessions together, rather than reusing a builder that retains those objects.

Migration reaches beyond a version pin

The Python package release also removes installation eligibility for Python 3.10. Its predecessor had already identified Python 3.11 as the supported baseline while leaving older installations possible. Version 1.25 turns that warning into a package requirement. Integration-specific upper version bounds still apply, so selecting the newest Python interpreter is a separate compatibility decision. AG-UI also rejects workflow agents exposed through its workflow-as-tool interface. Together, these changes affect environment setup, object construction and endpoint behavior. An upgrade can fail at installation or produce a new scope-conflict error even when the application's model choice stays unchanged.

Permissions follow the running objects

The practical distinction is between a fresh wrapper and fresh state. A workflow factory provides isolation only when the objects holding history and approvals are created within the intended boundary. Microsoft's change makes that boundary explicit for live sessions. It also makes discovery limits visible at the integration layer, where an application decides which servers to trust. These controls move decisions that were easy to leave implicit into configuration and runtime checks. They give developers specific failures to handle instead of allowing the same object graph to keep serving unrelated callers.