Python: Skip MCP prompt loading when unsupported

[karimbaidar]

Motivation and Context

Fixes #5360.

MCP servers can advertise tools without supporting prompts. The client was still calling prompts/list whenever prompt loading was enabled, so tool-only servers could fail during connect.

Description

Stores the server capabilities returned by MCP initialization and skips prompt discovery when the server does not advertise the prompts capability. If capabilities are unavailable, the existing behavior is preserved.

Adds a focused core MCP regression test for a tool-only server that would otherwise raise Method 'prompts/list' is not available.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the Contribution Guidelines
• All unit tests pass, and I have added new tests where possible
• Is this a breaking change? No

Update

This now generalizes the negotiated MCP capability handling for tools, prompts, and logging while keeping the constructor load flags as caller intent. After initialization, missing or unadvertised capabilities are treated as unsupported, so unsupported tools/list, prompts/list, and set_logging_level calls are skipped.

Ping support is handled separately as session-scoped probed state, since it is not part of ServerCapabilities. Paginated tool/prompt loading also reconnects once on ClosedResourceError for servers where ping is unavailable.

[karimbaidar]

@microsoft-github-policy-service agree

[moonbox3]

Python Test Coverage Report •

File	Stmts	Miss	Cover	Missing
packages/core/agent_framework
_mcp.py	752	58	92%	153, 172, 317, 377–378, 507, 569, 582, 606–607, 626–629, 631–632, 636, 690–692, 694, 747–749, 804–805, 988, 1025–1026, 1039, 1042, 1050–1051, 1056–1057, 1063, 1107–1108, 1122–1123, 1131–1132, 1137–1138, 1144, 1201, 1204, 1231, 1254–1258, 1363, 1415–1416, 1419, 1890
TOTAL	35106	4104	88%

Python Unit Test Overview

Tests	Skipped	Failures	Errors	Time
6959	30 💤	0 ❌	0 🔥	1m 45s ⏱️

[Copilot]

Pull request overview

This PR fixes MCP client connections to tool-only servers by honoring negotiated server capabilities from MCP initialization, avoiding prompt discovery calls when the server does not support prompts.

Changes:

• Cache MCP initialize() capabilities on MCPTool and use them to detect prompt support.
• Skip prompts/list discovery when the server does not advertise the prompts capability (preserving existing behavior when capabilities are unavailable).
• Add a regression test ensuring prompt discovery is skipped for tool-only servers.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
python/packages/core/agent_framework/_mcp.py	Store negotiated server capabilities and gate prompt loading on prompts capability support.
python/packages/core/tests/core/test_mcp.py	Add regression coverage for connecting to a server that supports tools but not prompts.

[giles17]

Automated Code Review

Reviewers: 4 | Confidence: 89% | Result: All clear

Reviewed: Correctness, Security Reliability, Test Coverage, Design Approach

---

Automated review by giles17's agents

[giles17]

@karimbaidar looks good. One thing to flag:
When _ping_available is False, _ensure_connected() returns immediately without any liveness check. That's fine for call_tool()/get_prompt() since they have their own ClosedResourceError retry loops but load_tools() and load_prompts() don't. They rely entirely on _ensure_connected() for reconnection during pagination. So if the transport drops on a ping-less server, list_tools()/list_prompts() will raise an unhandled ClosedResourceError.

[karimbaidar]

Thanks for the review @giles17. I just Removed the constant, added _supports_logging, made missing capabilities unsupported after init, and added reconnect handling for ping-less paginated loads. Could you please take another look?

[karimbaidar]

Hi @giles17 i fixed the pyright checks. If possible, can you please approve this PR ? Thank you!

[giles17]

Hey @karimbaidar thanks! There's a little merge conflict to be resolved

[karimbaidar]

@giles17 thanks! just resolved the merge conflict but I think github requires your approval again :)

[karimbaidar]

@eavanvalkenburg can you please also check and approve so that this PR could be merged successfully. Because we need at least two approvers for this PR to be merged successfully. thank you!

[eavanvalkenburg]

small nit, otherwise looks good

[karimbaidar]

@giles17 @eavanvalkenburg all Set :), waiting for the final Approval and thanks a lot for your review. It helped a lot to improve this PR further. Truly appreciate that.