Python: MCP tools with execution.taskSupport "optional" are skipped, although they can be called without Tasks #9675

Activity

1. github-project-automation

   added this to Agent Frameworkon Oct 24, 2026
2. agent-framework-automation

   added

   pythonUsage: [Issues, PRs], Target: PythonUsage: [Issues, PRs], Target: Python

   triageUsage: [Issues], Target: All issues that still need to be triagedUsage: [Issues], Target: All issues that still need to be triaged

   on Oct 24, 2026
3. Sainath-Reddy7 commented on Oct 25, 2026

   

   B Sainath Reddy (Sainath-Reddy7)

   on Oct 25, 2026

   More actions

   Reproduced on agent-framework-core 1.23.0 + mcp 2.3.0 — thanks for the clear report.

   Minimal repro (mirroring the mock-session pattern from tests/core/test_mcp.py): a session exposing two tools, one plain and one with execution.task_support="optional", produces

   Skipping MCP tool 'optional_task_tool' because it (might) require the Tasks extension, which MCP Python SDK 2.2 does not implement.
   

   and only the plain tool ends up in tool._functions.

   Root cause is the membership test at python/packages/core/agent_framework/_mcp.py (~line 3110): if task_support in ["required", "optional"] skips both. Per the Tasks-extension semantics, "optional" means the tool works without the extension (it may use it when available), so only "required" warrants skipping — which would also let the warning message drop the "(might)" hedge.

   Proposed direction: skip only when task_support == "required", load "optional" tools normally, and add a regression test with both variants.

   Following the AI-assisted contributions policy: this analysis and repro were prepared with an AI coding agent at my direction and reviewed by me; happy to implement once a maintainer adds ready-for-implementation or agrees with the direction.
4. Eduard van Valkenburg (eavanvalkenburg)

   assigned

   Jose Alvarez (jpalvarezl)

   on Oct 26, 2026
5. eavanvalkenburg commented on Oct 26, 2026

   

   Eduard van Valkenburg (eavanvalkenburg)

   on Oct 26, 2026

   Member

   More actions

   Jose Alvarez (@jpalvarezl) could you take a look and comment on whether task-optional MCP tools should be callable through the ordinary tools/call path while task-required tools remain excluded?

   Current tests and ADR 0045 exclude both, so we need your view on the intended compatibility boundary before settling the direction. This would not add Tasks-extension support. Related PR: #9690.

   👍React with 👍1Reacted by Jose Alvarez
6. pamelafox commented on Oct 26, 2026

   

   Pamela Fox (pamelafox)

   on Oct 26, 2026

   Member

   More actions

   Written with GitHub Copilot + Claude Opus 5.5.

   This also affects Azure AI Search knowledge base MCP endpoints used directly with MCPStreamableHTTPTool, not only via Foundry Toolbox. The server marks the tool "optional" but never declares a tasks capability:

   ← initialize: {"protocolVersion":"2025-11-25","capabilities":{"logging":{},"tools":{"listChanged":true}}}
   ← tools/list: {"name":"knowledge_base_retrieve", ..., "execution":{"taskSupport":"optional"}}
   

   On the compatibility-boundary question, the 2025-11-25 spec gates this before taskSupport is even considered:

   If a server's capabilities do not include tasks.requests.tools.call, then clients MUST NOT attempt to use task augmentation on that server's tools, regardless of the execution.taskSupport value.

   So for servers like this, the tool should simply be called normally. Suggestion: only evaluate taskSupport when the server declares tasks.requests.tools.call, and even then skip only "required" (as #9690 does).

   👍React with 👍1Reacted by Jose Alvarez
7. pm25coder commented on Oct 27, 2026

   

   pm25coder

   on Oct 27, 2026

   More actions

   On the boundary question: the client can't currently draw it on the peer, because it never holds the peer's Tasks answer.

   On main (1168c00) the skip at python/packages/core/agent_framework/_mcp.py:3114-3121 reads one field from each tools/list entry — execution.task_support — and tests it against the literal pair ["required", "optional"]. The capabilities the client does cache are three flags at :2280-2282 (tools, prompts, logging); there is no fourth for tasks anywhere in that file. So a peer announcing tasks.requests.tools.call and a peer announcing nothing at all take the same branch.

   I measured that rather than reading it off the source. With 1.23.0 from PyPI and mcp 2.3.0, a mock session exposing four tools (plain / optional / required / forbidden), run once presenting a tasks capability and once presenting none: both runs loaded ['plain', 'forbidden'] and skipped optional and required with the same "(might) require" warning, and nothing in the client read a capability attribute off the session during load_tools(). Applying #9690's change to the same install and re-running gave, in both arms, ['plain', 'optional', 'forbidden'], only required skipped, and the optional tool invoking through the ordinary path and returning content.

   For settling the direction, two things already in the repo say the narrow rule is the intended one. python/packages/core/AGENTS.md:244 states it outright: tools advertising execution.taskSupport == "required" are skipped with a warning, while optional and task-free tools continue through ordinary tools/call. And tests/core/test_mcp.py:596 is what holds the code to the other reading — it asserts ['forbidden', 'ordinary'], which reads as correct at a glance because loading forbidden is correct; the only wrong row is optional, and it's the test's name that encodes the rule.

   ADR 0045:185 ("Tools that may require Tasks are not presented as ordinary supported calls") turns, for optional, on whether this client would ever attempt augmentation — and it can't, since a plain call is the only call it makes. That's the reading under which the ADR agrees with AGENTS.md instead of contradicting it.

   If you'd rather make the peer's capability the gate, as Pamela Fox (@pamelafox) suggests, it isn't there to reuse: it would be that fourth flag at :2280-2282, and its one visible effect would be on required tools from peers that declare no tasks — where today's message blames the SDK's missing runtime rather than the peer's capabilities.
8. Jose Alvarez (jpalvarezl)

   added

   ready-for-implementationMaintainers agree the problem and direction are ready for implementation.Maintainers agree the problem and direction are ready for implementation.

   on Oct 27, 2026
9. jpalvarezl commented on Oct 27, 2026

   

   Jose Alvarez (jpalvarezl)

   on Oct 27, 2026

   Last edited by jpalvarezl

   Member

   More actions

   Agreed. I have opened a PR with the fix that is similar to the one you linked Pamela Fox (@pamelafox) , but also contains documentation updates. Thank you for reporting the issue.
10. Jose Alvarez (jpalvarezl)

    closed this as completedin #9746on Oct 27, 2026
11. github-project-automation

    moved this to Done in Agent Frameworkon Oct 27, 2026