Text-free illustration of an MCP approval turnstile: named badges with checkmarks queue on the left, a policy clipboard with an empty default row on the right, and an unlabeled orange token slipping under the gate

Microsoft Agent Framework 1.24.0 MCP Approvals: We Tested Tools and Prompts

Microsoft Agent Framework 1.24.0 adds MCP approval defaults. We tested tools and prompts: unlisted names stay never_require until you set default.

Updated November 5, 2026. Lab run on agent-framework-core 1.24.0 with mcp 2.3.0 on Python 3.13.5 (Linux).

Microsoft Agent Framework python-1.24.0 , dated October 30, 2026, adds an explicit default key for local Model Context Protocol (MCP) tool and prompt approvals, and emits a FutureWarning when never_require_approval leaves that default implicit. On November 5 we installed the package, connected a three-tool and two-prompt MCP server, and read each FunctionTool.approval_mode after connect.

The practical finding is blunt: an approval map that only lists safe tools under never_require_approval still leaves every unlisted tool and every unlisted prompt on never_require today. A delete tool and a wipe prompt both skipped approval in that configuration. Setting default: "always_require" flipped the unlisted names without changing the safe list.

TL;DR

  • python-1.24.0 adds default for local MCP approval_mode and warns when never_require_approval omits it.
  • Resolution order is always_require_approval, then never_require_approval, then default; with no match the framework still uses never_require.
  • MCP prompts load as FunctionTool entries beside tools when load_prompts=True, so the same silent default covers prompts.
  • Hosted MCP tools do not read default (MCPSpecificApproval docstring). Invalid default values raise ValueError.
  • Fix: set default: "always_require" whenever you maintain a never_require allowlist of safe tools.

What python-1.24.0 Changed for MCP Approvals

The 1.24.0 changelog entry for agent-framework-core says the release adds “an explicit default approval mode for local MCP tools and prompts outside the per-tool approval lists, and warn when never_require_approval leaves the default implicit while preserving the existing fallback” (PR #9828). The same cut also ships experimental AgentTriggeredCompactionStrategy and UnloadSkillsCompactionStrategy, which we imported but did not load-test.

Microsoft agent-framework python CHANGELOG.md showing the 1.24.0 Added bullet for explicit default approval mode on local MCP tools and prompts
Changelog entry for python-1.24.0 on GitHub. Image: Microsoft agent-framework repository.

Microsoft Learn: Using MCP Tools documents the same policy for Python local MCP transports. For a specific approval policy, always_require_approval takes precedence, then never_require_approval, then default. Without default, unmatched tools and prompts do not require approval. A policy that sets never_require_approval without an explicit default emits a FutureWarning.

Microsoft Learn local MCP tools page section Select tools by unambiguous name with approval_mode default example
Learn docs for local MCP approval_mode including default. Image: Microsoft Learn.

How We Tested It

We installed agent-framework-core==1.24.0 plus mcp==2.3.0 and tenacity into a fresh virtualenv on Linux. The MCP server used the mcp 2.x MCPServer API (FastMCP was renamed in mcp 2.x) and exposed three tools (read_note, search_notes, delete_note) plus two prompts (draft_summary, wipe_workspace). Each case constructed an MCPStdioTool, entered it, and read approval_mode on every object in functions.

We did not run a live LLM loop. The measurement matches what Agent Framework attaches at connect time, which is what the host will enforce on the next tool or prompt call. Environment: Python 3.13.5, agent-framework-core 1.24.0, mcp 2.3.0, date November 5, 2026 IST.

Lab Results: Tools and Prompts Share the Silent Default

Across seven approval maps, every prompt appeared in functions as a FunctionTool beside the tools when load_prompts=True. That matters for AgentOps teams who treat prompts as lower risk than tools. In Case B, both the unlisted delete tool and the unlisted wipe prompt stayed on never_require.

Table of seven MCP approval_mode cases showing delete_note and wipe_workspace approval values with FutureWarning flags on agent-framework-core 1.24.0
Lab matrix: Case B leaves delete_note and wipe_workspace on never_require; Case C with default always_require flips both.
  • A (None): every tool and prompt is never_require. No FutureWarning.
  • B (never_require_approval for the two reads only): delete_note, draft_summary, and wipe_workspace are still never_require. FutureWarning fires.
  • C (B plus default always_require): reads stay never_require; delete_note, draft_summary, and wipe_workspace become always_require. Warning gone.
  • D (always_require_approval for delete_note only): delete_note requires approval; both prompts and the other tools stay never_require. No warning (never list absent).
  • E (delete_note in both always and never lists): always wins. FutureWarning still fires because never is set without default.
  • G (default always_require alone): every tool and prompt requires approval.
  • H (always wipe+delete, never reads+draft, default always): named lists win; default covers anything new.
Terminal-style lab transcript showing FutureWarning text and Case B versus Case C approval_mode values for tools and prompts
Lab transcript excerpt: Case B FutureWarning and Case C after setting default.

Exact Warning, Invalid Default, and the Hosted Gap

The warning string is fixed in agent_framework._mcp._MCP_APPROVAL_DEFAULT_WARNING. Our Case B emitted:

approval_mode sets `never_require_approval` without `default`. Tools and prompts named in neither list use "never_require" today, and this fallback may change in a future release. Set `default` to "never_require" to keep the current behavior or to "always_require" to require approval for them.

Passing default: "sometimes" raised immediately: ValueError: approval_mode `default` must be 'always_require' or 'never_require', got 'sometimes'. Only those two strings are accepted.

One enterprise gotcha that changelog briefs skip: the MCPSpecificApproval docstring states that Hosted MCP tools do not read default. A policy you tune for MCPStdioTool or MCPStreamableHTTPTool does not automatically translate to hosted MCP tool configuration. Confirm hosted approval lists separately.

Four-step diagram of local MCP approval resolution: always_require_approval, never_require_approval, default, then silent never_require fallback
Resolution order for local MCP tools and prompts in agent-framework-core 1.24.0.

What To Change in Production Configs

If your local MCP connector uses a never_require allowlist of read-only tools, add an explicit default. The shape Microsoft Learn shows matches what fixed Case B in our lab:

mcp_server = MCPStdioTool(
    name="operations",
    command="uvx",
    args=["your-mcp-server"],
    approval_mode={
        "always_require_approval": ["delete_note", "wipe_workspace"],
        "never_require_approval": ["read_note", "search_notes", "draft_summary"],
        "default": "always_require",
    },
)

Then print [(f.name, f.approval_mode) for f in mcp_server.functions] after connect. Do this whenever a server advertises new tools through tools/list_changed, because newly discovered names also fall through to default (per PR #9828 notes; we did not re-simulate list_changed in this run). Pair the policy with the rest of your MCP server inventory and your AI agent security controls so gateway kills and runtime policies are not the only line of defense.

For teams wiring Google or other hosted MCP surfaces, revisit how discovery is gated after Google opened Gemini and AI Mode to MCP servers. Local default does not substitute for hosted approval configuration.

How This Differs From Other Writeups

A November 4 Japanese walkthrough on Zenn reproduced Cases A through E for three tools and reached the same delete_note conclusion we saw. Our lab extends that work in four places that matter for AgentOps reviews: prompts are measured, the English FutureWarning is quoted in full, an invalid default is shown to raise ValueError, and the Hosted MCP docstring gap is called out. Agentic Horizon summarized the changelog on November 1 and stated it had not independently tested the behavior.

If you already patched configs from the Zenn article, re-check prompt names. A server that exposes destructive prompts under load_prompts=True inherits the same silent fallback those tool-only tables never showed.

AgentOps Checklist for MCP Approvals

Treat local MCP approval_mode as part of your change control, not a one-time SDK setting:

  • Inventory every MCP server your agents start (stdio and streamable HTTP), including shadow servers developers add in personal configs.
  • For each server, print name and approval_mode after connect in CI, and fail the job if any always-destructive name is never_require.
  • Require default: "always_require" in policy reviews whenever never_require_approval is non-empty.
  • Separate hosted MCP approval configuration from local maps; do not assume default carries over.
  • On server upgrades, re-run the printer because new tools inherit default, and a missing default still means never_require.

Gateway-level kills remain useful when a model already has a live session. They do not replace connect-time approval maps. Yesterday’s CrowdStrike AI Kill Switch lab showed what a gateway block stops and what it misses; pair that control with an explicit MCP default so unlisted tools never reach the gateway unapproved.

What This Release Does Not Fix

The FutureWarning is a heads-up, not a behavior change. Case B still auto-approves unlisted destructive tools and prompts on 1.24.0. Compaction strategies are experimental and separate from approval. Python 3.10 remains installable but unsupported; Microsoft marks 3.11+ as the baseline and plans to drop 3.10 install eligibility next. Redis context users still need a manual index rebuild after the scope-identity break.

Frequently Asked Questions

Does Agent Framework 1.24.0 require approval for unlisted MCP tools by default?

No. Without an explicit default, unmatched local MCP tools and prompts use never_require today. The release adds the default key and a FutureWarning; it does not flip the fallback yet.

Do MCP prompts follow the same approval_mode rules as tools?

Yes in our lab. With load_prompts=True, prompts appeared in functions as FunctionTool objects and took always_require or never_require from the same map, including the silent fallback and the default key.

When does the FutureWarning fire?

When approval_mode sets never_require_approval and omits default. Case E still warned even though always_require won for the overlapping name, because the never list was present without default.

Does default apply to Hosted MCP tools?

No. The MCPSpecificApproval docstring says Hosted MCP tools do not read default. Configure hosted approval lists on their own terms and verify with the hosted API types.

What is the safe default for a mixed read and write MCP server?

Set default to always_require, put trusted read-only tools and prompts in never_require_approval, and put destructive names in always_require_approval. Re-print approval_mode after every server upgrade.

Sources

Tags