mcp(chore[pytest]): Stop hiding our own deprecation warnings

[tony]

Closes #111.

filterwarnings silenced DeprecationWarning for libtmux.*, libtmux_mcp.*, and tests. Those look like they filter dependency noise. They do the opposite.

A deprecation is attributed to the frame the raising library points stacklevel at, which by convention is the caller — so the warning that says "this line uses a deprecated API" is attributed to libtmux_mcp.something or to the test body that exercised it. The three filters matched precisely those, while a warning from an unrelated package sailed through. FastMCPDeprecationWarning subclasses DeprecationWarning, so FastMCP's own deprecations were caught too.

Evidence

A/B probe under the repo's real config — two tests, one run, one warning emitted from each namespace:

Warning attributed to	Result
libtmux_mcp.server	suppressed, absent from the warnings summary
some_other_package.thing	surfaces normally

And the MRO, since it's what makes the category filters reach FastMCP:

FastMCPDeprecationWarning.__mro__ -> (FastMCPDeprecationWarning, DeprecationWarning, Warning, ...)

What was hidden

Exactly one thing, and it is real. Removing the filters surfaced asyncio.iscoroutinefunction at tests/test_wait_for_tools.py:57-58 — "deprecated and slated for removal in Python 3.16; use inspect.iscoroutinefunction() instead". Fixed here.

Nothing else warns. The suppression bought no quiet; it cost one signal, and that signal was a scheduled standard-library removal.

Why now

SEP-2596 obliges Tier 1 SDKs to emit a runtime DeprecationWarning when a deprecated feature is exercised, once that feature enters the Deprecated state. Three things land imminently: spec revision 2026-07-28 (which deprecates Roots, Sampling, and Logging via SEP-2577), mcp 2.0.0 targeted for the same date, and fastmcp v4 already in alpha against the <4.0.0 ceiling here.

There is real exposure waiting behind that: 13 .inputSchema reads across the history tests, mcp.types imports in middleware.py (the submodule becomes a standalone package in 2.x), and _client_label() reading client identity off the initialize handshake that 2026-07-28 removes. None of it can break today — fastmcp 3.4.4 pins mcp<2.0, so 2.x cannot resolve into this environment — but warnings are how that transition is meant to announce itself, and the suite was configured not to listen.

What this does not do

It does not escalate DeprecationWarning to an error. This project pins two fast-moving pre-2.0 dependencies; making warnings fatal hands upstream the ability to turn CI red on its own release schedule, with no local change. Visible-but-not-fatal restores the signal without that coupling. Worth revisiting once mcp 2.x and fastmcp v4 have settled.

The message-scoped docutils filter is untouched — that one is correctly shaped, filtering a specific known message rather than a category across a module.

Verification

ruff check, ruff format --check, mypy (65 files), pytest --reruns 0 (801 passed, 0 warnings), just build-docs clean.

Independent of #110, which is also open — that one migrates wait_for_text off the deprecated MCP Logging capability. No overlapping files.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.13%. Comparing base (ab82ad9) to head (0f6d53e).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #112   +/-   ##
=======================================
  Coverage   86.13%   86.13%           
=======================================
  Files          46       46           
  Lines        3593     3593           
  Branches      516      516           
=======================================
  Hits         3095     3095           
  Misses        354      354           
  Partials      144      144           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.