MCP C# Task Polling: Stop Infinite input_required Loops

MCP Tasks let a tool finish asynchronously, but they also introduce a failure mode that a normal request timeout does not describe well: the task is alive, yet every poll returns the same input_required

request. For MCP C# task polling, I want a bounded definition of “no progress,” not an endless loop or a user prompt that appears again and again.

The stable C# Tasks extension already provides that guard. The key is to set maxConsecutiveStuckPolls

deliberately and test what happens when a server never advances.

In the MCP 2026-07-28

Tasks extension, a tool call can return a task instead of its final tool result. The client then uses tasks/get

until the task completes, fails, is cancelled, or asks for input.

An input_required

result contains keyed requests. A simplified response looks like this:

{
  "taskId": "task-1",
  "status": "input_required",
  "pollInterval": 1,
  "inputRequests": {
    "approval": {
      "method": "elicitation/create"
    }
  }
}

The key matters. If the next poll returns approval

again, it is not a new question. Presenting it twice can produce duplicate confirmations or conflicting responses. Polling forever is not better; it hides a server that has stopped making useful progress.

The official C# SDK Tasks guide says CallToolWithPollingAsync

deduplicates input-request keys. It also detects repeated input_required

polls that contain no new keys, makes a best-effort tasks/cancel

call, and throws McpException

. The default stuck-poll threshold is 60.

The extension method keeps the policy close to the call:

try
{
    CallToolResult result = await client.CallToolWithPollingAsync(
        new CallToolRequestParams { Name = "long-running-tool" },
        maxConsecutiveStuckPolls: 3,
        cancellationToken: cancellationToken);

    // Consume the completed tool result.
}
catch (McpException exception)
{
    logger.LogWarning(exception, "MCP task stopped making progress");
}

I use 3

in a fast verifier, not as a universal production value. The practical time bound is approximately the threshold multiplied by the server's poll interval. A task polled every second and a task polled every 30 seconds should not automatically share the same threshold.

This guard complements the caller's CancellationToken

. Caller cancellation answers “does my operation still need this result?” The stuck-poll guard answers “is the server returning any new work or state?” Those are different decisions, and keeping both makes the failure easier to diagnose.

My complete sample on main uses

ModelContextProtocol.Extensions.Tasks

2.2.0 and an in-memory transport. It advertises MCP 2026-07-28

, returns a task from tools/call

, and then returns the same approval

request key on every tasks/get

call.The elicitation handler declines the request and counts how often it runs:

Handlers = new McpClientHandlers
{
    ElicitationHandler = (request, cancellationToken) =>
    {
        elicitationCalls++;
        return ValueTask.FromResult(
            new ElicitResult { Action = "decline" });
    },
};

With a stuck limit of three, the observed contract is precise:

approval

key.tasks/update

containing approval: decline

for task-1

.tasks/get

calls: one that introduces the key, then three with no new key.tasks/cancel

for task-1

.McpException

instead of polling again.The verifier runs twice and compares the output byte for byte. It requires no MCP host, model account, credentials, clock, random values, or runtime network access. The merged pull request also records the exact restore, format, build, run, package, and vulnerability-audit commands.

The package used here is the stable ModelContextProtocol.Extensions.Tasks 2.2.0 release. Tasks are part of the final MCP 2026-07-28

extension model; the official release notes explain the poll-based lifecycle.

A low threshold is useful in a unit test because it turns a potential hang into a quick deterministic failure. In production, the same value could cancel a healthy task while a person is considering an approval prompt. I would choose it from the expected poll interval, normal response latency, and the cost of leaving remote work active.

Cancellation is cooperative and eventually consistent. A successful tasks/cancel

response does not prove that remote work stopped at that exact instant, so callers must tolerate a late state transition and avoid assuming rollback.

This pattern is also not a replacement for an overall deadline, retry policy, or server-side task expiry. It specifically protects the polling loop when input_required

repeats without a new key. Log task IDs and state transitions for diagnosis, but keep elicitation answers and credentials out of logs.

What stuck-poll threshold fits your server's poll interval and expected human response time?

Happy coding!

source & further reading

dev.to — original article Guard Rail AI Why your agent says it finished when it didn't The Phishing Site Tried to Talk to My AI. That Became the Evidence.