ZeroGPU connection issue via MCP

Beginners
1

I’m getting an “Anthropic proxy: MCP server connection lost” or “Model not loaded” while trying to connect and use a model via ZeroGPU (pro account). Not a quota issue, is anyone else having connection issues with this?

2

It looks like similar issues have been reported:

Yes, there are recent public reports that are close to this—particularly on the Anthropic MCP connector side. However, I could not find a public incident report or maintainer confirmation showing that this exact combination is one confirmed ZeroGPU outage.

The closest match I found is the still-open Anthropic issue anthropics/claude-ai-mcp#469. It includes the exact error:

Anthropic proxy: MCP server connection lost

The reporter compared Claude.ai with MCP Inspector against the same MCP endpoint and token. According to that report, Inspector received valid responses while the Claude.ai connector sometimes failed, terminated the session, or replaced the server’s useful error with a generic message.

That makes the Anthropic connector/proxy/session path a credible possibility here. However, #469 is a user-filed bug report, not an Anthropic root-cause analysis, and it does not prove that your ZeroGPU call has the same cause.

I would also treat these as two separate symptoms until logs show that they are connected:

That example does not mean your Space has the same problem; it only shows that the wording alone does not identify which platform layer produced it.

Recommended first check

The fastest practical split would be to run the same input, close together in time, through:

  1. The normal logged-in Hugging Face Space UI
  2. The same endpoint using MCP Inspector
  3. If available, the Space’s direct Gradio API with an explicit HF token
Result More likely area
HF UI and direct API also fail Target Space, model initialization, ZeroGPU allocation, or another HF-side path
Inspector/direct API work, but Claude fails Anthropic connector, proxy, session, or Claude-surface-specific behavior
Tool discovery works, but execution disconnects after waiting GPU queue, cold start/model loading, long-request timeout, or session loss during execution
Explicit authenticated API gets Pro priority, while MCP behaves anonymously HF token/account identity propagation through the MCP path
Only one Space or model fails Space/model-specific issue becomes more likely
Multiple unrelated Spaces fail in several clients during the same UTC window Shared HF infrastructure becomes more plausible

The most useful missing details would be:

  • the Space URL;
  • which Claude surface was used: Claude.ai web connector, mobile, Desktop, or Claude Code;
  • whether it fails while connecting/discovering tools, or only after invoking the GPU tool;
  • approximately how long it waits before failing;
  • the UTC timestamp;
  • any redacted request_id, ofid, or Space log correlation ID.

The actual HF token should not be posted.

Why the visible error alone is not enough

There are several independent boundaries in this path:

  1. Claude client/surface
  2. Anthropic connector or broker
  3. MCP initialization and session handling
  4. Streamable HTTP transport
  5. HF Spaces Proxy/routing
  6. HF authentication and account attribution
  7. Gradio MCP adapter and queue
  8. ZeroGPU scheduler and worker
  9. Space model initialization and inference
  10. Response delivery back through the connector

A lower-layer failure can be replaced with a different message by a higher layer. Two separate attempts can also fail at different boundaries and produce two unrelated errors.

This matters because issue #469 reports cases where the server logs showed HTTP 200 and a valid JSON-RPC response, while Claude still presented the call as failed. The issue also reports generic error replacement and unrecoverable Session terminated states.

Therefore:

  • connection lost does not necessarily prove that the MCP server crashed;
  • a timeout does not necessarily prove that no HTTP error was returned;
  • a successful tool listing does not prove that a long-running tool call will remain connected;
  • a successful HF UI test does not prove that the MCP adapter and Claude connector path are healthy.

The most useful evidence is the first boundary where the same request stops appearing in logs.

Authentication, Pro status, and ZeroGPU identity

A Pro account with remaining quota and a request that is actually attributed to that Pro account are related but separate facts.

The current HF Spaces as MCP servers documentation says that MCP tools require a valid Hugging Face token with READ permission. The Gradio MCP guide also says that a token must be supplied when using a private Space or when using your own ZeroGPU quota.

The current ZeroGPU documentation says that Pro users receive:

  • eight times more daily quota;
  • the highest priority in ZeroGPU queues;
  • the ability to continue with prepaid credits after the daily quota.

Those benefits depend on the request being associated with the correct account.

A manually configured Gradio MCP endpoint normally has a shape similar to:

{
  "mcpServers": {
    "gradio": {
      "url": "https://<SPACE_SUBDOMAIN>.hf.space/gradio_api/mcp/",
      "headers": {
        "Authorization": "Bearer <HF_READ_TOKEN>"
      }
    }
  }
}

The exact configuration depends on the client and on whether it was generated through HF’s MCP settings, so the generated HF instructions should take precedence.

There is also a nearby HF Forum report, API GPU acquisition failure—perpetually stuck at “Waiting for a GPU to become available”, in which a paid, reportedly authenticated user received a guest-oriented priority message after waiting for a GPU.

That report has no confirmed maintainer diagnosis, so it should not be treated as the cause here. It does show why checking request identity propagation, rather than only the quota page, may be worthwhile.

Timeouts, queues, cold starts, and progress

A ZeroGPU tool call can encounter several different timers:

  • GPU allocation waiting time;
  • worker startup;
  • model initialization or transfer;
  • the Space function’s configured duration;
  • the Gradio queue;
  • the MCP client’s request timeout;
  • an Anthropic connector/proxy timeout;
  • the lifetime of the MCP session.

The MCP lifecycle specification recommends timeouts for sent requests. It permits implementations to reset a timer after receiving progress notifications, but also recommends enforcing an overall maximum timeout.

Gradio’s MCP guide notes that queue=False may reduce latency, but disables progress notifications and is therefore not recommended for long-running events. The Gradio MCP integration normally uses the queue to send progress updates.

This creates a plausible—but not yet proven—failure pattern:

  1. MCP connection and tool discovery succeed.
  2. The ZeroGPU tool is invoked.
  3. The request waits for GPU allocation or model readiness.
  4. One client, proxy, or session timeout expires before a useful result is returned.

A useful control is to compare a very short CPU-only MCP tool with the ZeroGPU tool in the same client:

  • If both fail before the server sees the request, investigate the connector/proxy/auth path.
  • If the CPU tool succeeds and only the GPU tool fails after a delay, investigate allocation, model loading, progress handling, and long-call timeouts.
  • If the GPU tool succeeds after the Space has been warmed but fails after an idle period, cold-start behavior becomes more relevant.
  • If inference finishes in the Space logs but Claude still reports failure, response forwarding or session handling becomes more relevant.
Recent platform incidents: relevant context, but not proof

There has been recent platform instability, but it should be separated from the exact root cause of this report.

Anthropic’s public status history includes a July 8 incident titled “Issues authorizing to MCP Servers”, described as users being unable to send authorized requests to MCP servers. It was marked resolved.

On the HF side, a July 8–10 Forum thread reported Space-to-Space requests to *.hf.space returning 503 from awselb. An HF contributor acknowledged the problem, said the infrastructure team was investigating it, and later reported that it was fixed.

That incident is useful because it shows that a narrow Spaces routing problem can exist even when there is no obvious broad outage. However, its affected route was Space-to-Space traffic, which is not necessarily the same route used by a Claude MCP connector.

The HF status page can help identify declared broad incidents, but a green status page does not exclude:

  • one Space or model failing;
  • a narrow routing path failing;
  • regional or account-specific behavior;
  • ZeroGPU queue saturation;
  • authentication attribution problems;
  • a client-specific MCP failure.

So the current evidence supports:

“There have been recent related incidents and similar public reports.”

It does not yet support:

“This was definitely caused by the recent HF maintenance/outage.”

If you own the Space

If this is your Space, a few explicit log markers would make the report much easier to classify.

For one test request, record whether execution reaches:

  1. the MCP/HTTP endpoint;
  2. the Gradio callback;
  3. the @spaces.GPU function;
  4. the model-ready check;
  5. inference start;
  6. inference completion;
  7. response serialization and return.
Last confirmed boundary Main area to inspect
No request reaches the Space Claude connector/proxy, auth before dispatch, routing
Discovery reaches the Space but no tool call arrives Claude tool dispatch or conversation/session state
Callback starts but GPU function does not Gradio adapter, queue, or pre-GPU application logic
GPU function starts but model is absent Space initialization, model access, or application state
Inference finishes but the client fails Serialization, streaming, proxy forwarding, or session lifetime

It would also help to preserve:

  • Space revision/commit;
  • Gradio version;
  • Python and PyTorch versions;
  • model revision;
  • whether the same revision works in the normal UI;
  • elapsed time at each boundary.

The ZeroGPU documentation explicitly notes that ZeroGPU may have more limited compatibility than a standard GPU Space and that unexpected issues may occur. Therefore, success on a normal GPU Space or locally is useful evidence, but is not a complete reproduction of the ZeroGPU execution model.

What users can determine, and what requires HF or Anthropic

Public testing can usually identify the failing boundary, but some internal facts are only available to the platform operators.

A user or Space owner can usually determine:

  • whether the normal Space UI works;
  • whether MCP tool discovery works;
  • whether the request reaches the Space;
  • whether an explicit HF token changes the outcome;
  • whether MCP Inspector succeeds while Claude fails;
  • whether the problem is specific to one Space, one GPU function, or one Claude surface;
  • whether the model initialization failed in Space logs.

HF would be better positioned to confirm:

  • which account and priority tier the request was assigned to;
  • ZeroGPU scheduling and allocation decisions;
  • worker startup or teardown failures;
  • Spaces Proxy/load-balancer behavior;
  • internal correlation between the MCP request, Gradio queue, and GPU worker.

Anthropic would be better positioned to confirm:

  • whether the connector dispatched the tool call;
  • whether the upstream response was received;
  • whether it timed out, was cancelled, or was replaced;
  • connector/session state for the conversation;
  • differences between Claude web, mobile, Desktop, and Code.

A useful escalation bundle would contain:

  • Space URL and revision;
  • exact MCP endpoint;
  • Claude surface/client;
  • UTC timestamp;
  • redacted request/correlation ID;
  • whether discovery succeeded;
  • elapsed time before failure;
  • same-time HF UI, Inspector, and direct API results;
  • relevant Space log lines with secrets removed.

One caution about retries: a single timestamped retry can help identify an intermittent issue, and #469 reports that retries sometimes succeed. Repeated blind retries are not a reliable fix, though. They may consume ZeroGPU quota or duplicate a side-effecting tool operation.

My current read is therefore:

  • There is a close, still-open Anthropic-side report containing the exact proxy error.
  • There are also recent HF Spaces/ZeroGPU-related reports and a recently acknowledged HF routing incident.
  • None of the public evidence confirms that they share the same root cause as this case.
  • Anthropic proxy: MCP server connection lost and Model not loaded should remain separate until logs connect them.
  • The highest-value next comparison is the same Space/input through HF UI, MCP Inspector, and the direct authenticated Gradio API.

With the Space URL, Claude surface, failure stage, UTC timestamp, and a redacted request ID, this should become much easier for HF staff, Anthropic, or another user to classify without guessing.