splunklib.ai broken by mcp 2.0.0 — 'ai' extra needs an mcp<2 cap (Server.list_tools removed)

[guilhemmarchand]

Summary

mcp 2.0.0 (released on PyPI 2026-07-28) is a major rework of the MCP Python SDK that removes the list_tools / call_tool decorator API from mcp.server.lowlevel.Server (replaced by add_request_handler; see their 2.0.0 release notes). splunklib.ai registers its tool handlers through those decorators, and the ai extra declares mcp>=1.27.1 with no upper bound — so any fresh pip install "splunk-sdk[ai]" since 2026-07-28 resolves mcp 2.0.0 and the AI module is unusable.

Reproduction

pip install "splunk-sdk[ai]"   # resolves mcp 2.0.0 as of 2026-07-28
python -c "from splunklib.ai.registry import ToolRegistry; ToolRegistry()"

  File ".../splunklib/ai/registry.py", line 239, in __init__
    self._register_handlers()
  File ".../splunklib/ai/registry.py", line 242, in _register_handlers
    @self._server.list_tools()
     ^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'Server' object has no attribute 'list_tools'

Anything importing splunklib.ai (e.g. from splunklib.ai import Agent) hits the same class of failure via splunklib/ai/tools.py's mcp imports.

Verified against both lines in clean venvs:

• mcp==2.0.0: mcp.server.lowlevel.Server has neither list_tools nor call_tool (handler registration moved to add_request_handler; mcp/types also changed from a module to a package).
• mcp==1.29.0 (released the same day on the maintained 1.x branch): both decorators present, ToolRegistry() instantiates fine.

Impact

• splunk-sdk 3.0.0 (current release) with the ai extra: broken on any fresh install/build since 2026-07-28.
• Downstream applications that bundle dependencies at build time inherit the breakage silently — we (TrackMe for Splunk) shipped a production build with mcp 2.0.0 pulled in before pinning mcp<2 on our side.

Suggested fix

Cap the ai extra to the API line the code is written against:

ai = ["httpx==0.28.1", "langchain>=1.2.18", "mcp>=1.27.1,<2", "pydantic>=2.13.4"]

and treat mcp 2.x support as a separate, deliberate migration (the upstream 2.0.0 release notes describe substantial API changes beyond the low-level server: unified Client, FastMCP → MCPServer, etc.). Upstream maintains 1.x with critical fixes on a separate branch, so a <2 cap remains healthy in the meantime.

Happy to provide more detail if useful.