mcp 2.x compatibility for splunklib.ai

Roadmap question: mcp 2.x compatibility for splunklib.ai (ToolRegistry still relies on the 1.x Server.list_tools / Server.call_tool decorators)

Disclosure: this issue was researched and drafted with AI assistance (Claude Code) and is opened on behalf of Guilhem Marchand, TrackMe Limited, who reviewed and approved its content. TrackMe is a Splunk application that builds its AI Advisor features on splunklib.ai (splunk-sdk 3.0.0).

Summary

splunk-sdk 3.0.0 and 3.0.1 are only compatible with mcp 1.x, and there is no public signal about whether or when splunklib.ai will support mcp 2.x. This is a roadmap question, not a bug report: we would like to know the intended direction so that downstream apps can plan their own pins.

What we verified

• splunklib/ai/registry.py is byte-identical between tags 3.0.0 and 3.0.1. ToolRegistry builds its in-process tool server on mcp.server.lowlevel.Server and registers handlers with @self._server.list_tools() and @self._server.call_tool(validate_input=True).
• mcp 2.0.0 (2026-07-28) removed those decorators. In 2.1.1 the low-level server takes on_list_tools= / on_call_tool= constructor callbacks (or Server.add_request_handler(method, params_type, handler)), and handlers receive (ctx, params) rather than the 1.x signatures. The public package layout also changed (mcp/types.py in 1.x, mcp/types/ package in 2.x). So the migration is a small but real rewrite of the registration path, not a version bump.
• #829 (merged, shipped in 3.0.1) caps the ai extra at mcp>=1.28.1,<2.0.0, citing the mcp project's statement that 1.x is in maintenance mode and will receive security fixes. The mcp 1.x line is indeed still moving (1.29.1 on 2026-08-24, after 2.0.0).
• Dependabot PR #838 (2026-09-01) proposes mcp 2.1.0 with no accompanying code change, so as it stands it cannot merge.
• The client side in splunklib/ai/tools.py (ClientSession, stdio_client, streamable_http_client, mcp.types models) would also need re-validation under 2.x; the 2.1 release notes mention behaviour changes around outputSchema / structuredContent for tool results and around handler exception logging.

Why it matters downstream

Splunk apps bundle their Python dependencies at build time (ucc-gen pip-installs requirements.txt into the app's lib/), so an app that uses splunklib.ai must ship a concrete mcp version and keep it consistent with whatever the SDK expects. After #826 we cap mcp<2; after this week's review we also pin splunk-sdk==3.0.0 exactly, because the two constraints must move in lockstep: an SDK release that adopts mcp 2 would break an app still bundling mcp 1.x at import time, and vice versa. That is manageable as long as the direction is known in advance.

Questions

1. Is a migration of splunklib.ai to the mcp 2.x server API planned, and if so for which release line (3.1 / 4.0)?
2. Will that release be dual-compatible (accept mcp>=1.28.1,<3 with a runtime branch on the low-level API), or a hard cut to mcp>=2? A dual-compatible window, even one minor release long, would let downstream apps bump the SDK and mcp in two steps rather than one.
3. If no migration is planned until the mcp 1.x maintenance line ends, could that be stated in the splunklib/ai README next to the version requirements, so consumers can rely on it?
4. Would you accept a contribution for the registration-path migration? We are happy to test pre-release builds against a real deployment: six advisor agents, local stdio tools plus the remote Splunk MCP Server path, on Python 3.13.

Environment

• splunk-sdk 3.0.0 (PyPI), also reviewed tag 3.0.1
• mcp 1.29.1 (bundled), mcp 2.1.1 (inspected)
• Python 3.13, Splunk Enterprise 10.x / Splunk Cloud

Start by reading splunklib/ai/registry.py and splunklib/ai/tools.py, then compare their current mcp 1.x usage with the 2.x APIs described in the issue. Validate both local stdio and remote streamable HTTP paths under Python 3.13. The issue is complete only when maintainers decide the target release and compatibility policy, then define an accepted migration scope.