Python: Add MCP as a hard dep in Foundry Hosting

[TaoChenOSU]

Motivation & Context

Foundry toolbox integration requires MCP thus we need to take a dependency on the MCP package.

Description & Review Guide

• What are the major changes?
  Add a new dependency to the Foundry Hosting package.

• What is the impact of these changes?
  An extra dependency may increase install time.

• What do you want reviewers to focus on?

Why not an optional dep? Because we'd rather guarantee the toolbox related feature always works for foundry hosting (rather than depend on the user also installing the MCP extra), keeping mcp as a hard dependency would be the safer call. The optional dep (lazy import) approach trades that guarantee only for a lighter default install.

Related Issue

Foundry hosting agent samples no longer need to install mcp separately.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

Pull request overview

This PR makes the Python Foundry Hosting package (agent-framework-foundry-hosting) depend on the mcp Python package by default, aligning the distribution metadata with the package’s existing direct mcp imports used for Foundry toolbox/MCP integration.

Changes:

• Add mcp>=1.24.0,<2 to agent-framework-foundry-hosting runtime dependencies.

[github-actions]

Python Test Coverage Report •

File	Stmts	Miss	Cover	Missing
packages/core/agent_framework
_mcp.py	1181	92	92%	306, 325, 523, 583–584, 716, 778, 791, 815–816, 835–838, 840–841, 845, 871, 905–907, 909, 962–964, 1023–1024, 1293, 1334–1335, 1348, 1351, 1360–1361, 1366–1367, 1373, 1421–1422, 1438–1439, 1448–1449, 1454–1455, 1461, 1536, 1539, 1566, 1589–1593, 1616–1618, 1623, 1627–1628, 1730, 1737, 1739, 1752, 1758, 1820, 1835–1836, 1843–1844, 1849–1850, 1855, 1859, 1874, 1936, 2119, 2121, 2143, 2145–2148, 2161–2162, 2206, 2268, 2667–2668, 2890–2891, 2909
packages/durabletask/agent_framework_durabletask
_executors.py	139	21	84%	125, 325, 331, 358, 360–361, 367, 369–370, 374, 424–426, 428, 431, 433–434, 438, 463, 467–468
_worker.py	94	16	82%	222, 236–237, 241–242, 244–246, 283, 285, 290, 305, 309–310, 314–315
packages/durabletask/agent_framework_durabletask/_workflows
dt_context.py	54	23	57%	34–35, 41, 45, 52, 56, 61–64, 67, 72, 75, 80, 83, 88, 91, 95–97, 100–102
TOTAL	40680	4626	88%

Python Unit Test Overview

Tests	Skipped	Failures	Errors	Time
8117	34 💤	0 ❌	0 🔥	1m 51s ⏱️

[github-actions]

Automated Code Review

Reviewers: 5 | Confidence: 63%

✓ Correctness

No actionable issues found in this dimension.

✓ Security Reliability

No actionable issues found in this dimension.

✓ Test Coverage

No actionable issues found in this dimension.

✓ Failure Modes

No actionable issues found in this dimension.

✓ Design Approach

The repo’s Python dependency-management guidance explicitly prefers targeted uv lock --upgrade-package <dependency-name> updates for runtime changes, so this lockfile-wide churn is broader than the documented approach. I did not find a correctness problem in the dependency choice itself, but the lockfile regeneration approach appears broader than necessary.

Suggestions

• Regenerate python/uv.lock with a targeted dependency update (e.g., uv lock --upgrade-package mcp) so the PR only carries MCP-related resolution changes; the repo guidance explicitly prefers targeted lock updates to reduce merge conflicts (python/DEV_SETUP.md:236, python/.github/skills/python-package-management/SKILL.md:70).

---

Automated review by TaoChenOSU's agents