get_account_summaries and other tools hang indefinitely when using user OAuth (ADC) credentials on Python 3.14

[yoship90]

Environment:

• analytics-mcp v0.2.0
• Python 3.14.3
• Claude Code (stdio MCP client)
• Windows 11
• Credentials: authorized_user type via gcloud auth application-default login --client-id-file

Describe the bug:
When using Application Default Credentials (user OAuth / authorized_user type), any tool call hangs indefinitely and never returns a response. The MCP server starts successfully and responds to initialize and tools/list, but tool calls like get_account_summaries produce no response.

Root cause (suspected):
utils.py calls google.auth.default(scopes=[...]) which returns synchronous google.oauth2.credentials.Credentials. These are passed to async gRPC clients (AnalyticsAdminServiceAsyncClient). When the client attempts to refresh the access token, the synchronous HTTP call blocks the asyncio event loop, causing the hang.

Workaround:
Using a service account JSON key (service_account type credentials) instead of user OAuth resolves the issue immediately.

Steps to reproduce:

1. Run gcloud auth application-default login --client-id-file=<client.json> --scopes=https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform
2. Set GOOGLE_APPLICATION_CREDENTIALS to the resulting ADC file
3. Call get_account_summaries via Claude Code or any MCP client
4. Tool hangs indefinitely

Expected: Tool returns account summaries

Actual: No response, infinite hang

[mianaliasjad]

same issue here.

[robbleece]

Tool calls deadlock on Windows: gRPC client constructed in worker thread under mcp.server.stdio

Package version: analytics-mcp 0.2.0
Platform: Windows 11, Python 3.12 (pipx install)
MCP runtime: any client that uses mcp.server.stdio.stdio_server (reproduces with hand-driven subprocess.Popen, Claude Code, and others)

Summary

Every tools/call request that goes through a sync gRPC client hangs forever on Windows. tools/list and initialize work. The hang is in the constructor of the gRPC client (AnalyticsAdminServiceClient(...) / BetaAnalyticsDataClient(...)), not in the network call itself.

Root cause: each tool function (e.g. analytics_mcp.tools.admin.info.get_account_summaries) calls create_admin_api_client() per invocation. Under mcp.server.stdio.stdio_server, the tool coroutine runs on the asyncio event loop while anyio bridges stdio in worker threads. The sync gRPC client constructor needs to bring up gRPC core's background machinery (channels, completion queues, native threads). When this happens off the main thread while the main thread is blocked in the Windows IOCP wait used by anyio's stdio bridge, the construction never completes.

The # Sync clients are used instead of async (grpc.aio) clients ... comment in tools/utils.py:54-57 documents an earlier attempt at the same workaround — but switching from grpc.aio to sync clients only moved the deadlock; it didn't eliminate it. As long as the first construction of each client happens in an anyio-dispatched coroutine, it deadlocks.

Reproduction

Self-contained driver — no Claude Code, no MCP client, just subprocess.Popen against the installed binary:

# test_mcp.py
import json, subprocess, sys, threading, time

EXE = r"C:\Users\<you>\.local\bin\google-analytics-mcp.exe"

proc = subprocess.Popen(
    [EXE], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
    bufsize=0,
)

def send(obj):
    proc.stdin.write((json.dumps(obj) + "\n").encode("utf-8"))
    proc.stdin.flush()

def recv(timeout):
    holder = [None]; done = threading.Event()
    threading.Thread(target=lambda: (holder.__setitem__(0, proc.stdout.readline()), done.set()), daemon=True).start()
    return holder[0] if done.wait(timeout) else None

send({"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"r","version":"0"}}})
print("init:", recv(30))
send({"jsonrpc":"2.0","method":"notifications/initialized"})
send({"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_account_summaries","arguments":{}}})
print("call:", recv(60))   # hangs forever; receives None
proc.kill()

initialize returns in ~2s. tools/call never returns.

The same machine, same ADC credentials, calling get_account_summaries() directly via Python (no MCP, no asyncio) returns in ~3s. The same ADK FunctionTool(get_account_summaries).run_async(args={}, tool_context=None) driven by plain asyncio.run(...) (no mcp.server.stdio) also returns in ~4s. The hang appears only when both mcp's stdio loop and the gRPC client construction are on the same event loop.

Where it hangs

Adding stderr instrumentation to analytics_mcp/coordinator.py and tools/admin/info.py shows the call enters call_mcp_tool, enters the function body, dispatches to a worker thread via anyio.to_thread.run_sync (or asyncio.to_thread), the worker thread enters create_admin_api_client(), and never returns from the AnalyticsAdminServiceClient(...) constructor.

If the client is pre-created on the main thread at module load and reused, the same call returns in 843ms — confirming it is specifically construction-on-worker-thread that deadlocks, not the API call.

Proposed fix

Two changes:

1. analytics_mcp/tools/utils.py — cache clients as singletons + expose a warmup hook

_admin_client = None
_data_client = None
_admin_alpha_client = None
_client_lock = threading.Lock()


def create_admin_api_client():
    global _admin_client
    if _admin_client is None:
        with _client_lock:
            if _admin_client is None:
                _admin_client = admin_v1beta.AnalyticsAdminServiceClient(
                    client_info=_CLIENT_INFO, credentials=_create_credentials(),
                )
    return _admin_client


# (same pattern for create_data_api_client and create_admin_alpha_api_client)


def warmup_clients() -> None:
    """Force gRPC client construction on the calling thread."""
    create_admin_api_client()
    create_data_api_client()
    create_admin_alpha_api_client()

2. analytics_mcp/coordinator.py — call warmup_clients() at module load

This module is imported by server.py before mcp.server.stdio.stdio_server() runs, so warmup happens on the main thread before the event loop starts.

from analytics_mcp.tools.utils import warmup_clients
# ... existing module body ...
warmup_clients()  # at the bottom of the module

3. (Recommended) Wrap sync gRPC calls in asyncio.to_thread

Even with construction off the critical path, the sync gRPC calls (and pager iteration) still block the event loop during the request, freezing the stdio bridge. Wrap them:

async def get_account_summaries() -> List[Dict[str, Any]]:
    """Retrieves information about the user's Google Analytics accounts and properties."""
    def _sync():
        pager = create_admin_api_client().list_account_summaries()
        return [proto_to_dict(p) for p in pager]
    return await asyncio.to_thread(_sync)

Apply the same pattern in tools/admin/info.py, tools/reporting/core.py, tools/reporting/realtime.py, tools/reporting/metadata.py.

Unrelated bugs found while debugging

These should be fixed in the same release:

1. server.py:30, 60, 63 and coordinator.py:107 call print(...) without redirecting to stderr. MCP's stdio uses stdout for JSON-RPC framing — any print() to stdout corrupts the protocol stream. The startup banner print("Starting MCP Stdio Server: ...") is already corrupting the stream; some clients tolerate leading garbage but it's invalid. The error-path print(f"MCP Server: Error executing ADK tool '{name}': {e}") corrupts mid-conversation. All of these should pass file=sys.stderr.

2. server.py:54 does asyncio.run(run_server()) where run_server() is itself a sync wrapper that does asyncio.run(run_server_async()). This nests two asyncio.run calls; the outer one is a no-op for any awaitable but trips a TypeError: An asyncio.Future, a coroutine or an awaitable is required in some environments. Should be run_server() directly.

Validation

After applying changes 1+2+3 locally, the reproduction script above completes in:

• initialize: 5.8s (one-time gRPC warmup cost moved here)
• get_account_summaries (first call): 811ms
• get_account_summaries (cached): 188ms
• get_property_details: 280ms

stderr is clean (only the benign [EXPERIMENTAL] FeatureName.PLUGGABLE_AUTH warning from google-adk).

Workaround for users blocked on this today

Patch the installed package files in your venv directly:

<pipx_venv>/Lib/site-packages/analytics_mcp/tools/utils.py
<pipx_venv>/Lib/site-packages/analytics_mcp/coordinator.py
<pipx_venv>/Lib/site-packages/analytics_mcp/tools/admin/info.py
<pipx_venv>/Lib/site-packages/analytics_mcp/tools/reporting/core.py
<pipx_venv>/Lib/site-packages/analytics_mcp/tools/reporting/realtime.py
<pipx_venv>/Lib/site-packages/analytics_mcp/tools/reporting/metadata.py

Apply the changes above. The patched files will persist until you reinstall or upgrade the package.

[ZLeventer]

PR #139 by @gitrishiom addresses this — the fix replaces the async gRPC clients with sync clients wrapped in asyncio.to_thread(), which avoids the event loop collision between grpc.aio, google.auth, and the MCP server's stdio transport.

I reviewed that PR and the approach is sound. The core issue is that grpc.aio and the Google auth library both try to manage their own event loops, and on Windows (and apparently Python 3.14) this creates deadlocks. Moving gRPC to a background thread is a pragmatic workaround that keeps the MCP async interface intact.

[mahdihasan99]

Gemini in Antigravity fixed this:

Subject: [Fixed] Indefinite hang on Windows when using ADC (User OAuth)

I've successfully resolved the hang issue on Windows 11 / Python 3.14 by implementing a "Credential Warm-up" in server.py.

The Root Cause: As suspected, google.auth.default() returns synchronous credentials. When the async client triggers a refresh, it blocks the asyncio event loop on Windows.

The Solution:

Modify server.py:

Force a synchronous token refresh before the asyncio.run(run_server_async()) call. This ensures a valid token is cached in memory before the async loop takes over.

Modify utils.py:

Convert the _create_credentials() function into a singleton to ensure the warmed-up credentials are shared across all API clients.

Code Changes applied:

python

server.py

def run_server():
try:
from analytics_mcp.tools.utils import _create_credentials
import google.auth.transport.requests
creds = _create_credentials()
if not creds.valid:
creds.refresh(google.auth.transport.requests.Request())
except Exception as e:
pass # Handle accordingly
asyncio.run(run_server_async())

python

utils.py

_credentials = None
def _create_credentials():
global _credentials
if _credentials is None:
_credentials, _ = google.auth.default(scopes=[_READ_ONLY_ANALYTICS_SCOPE])
return _credentials

This fix makes the MCP server responsive again on Windows without requiring a Service Account.