mcp-server-fetch pagination returns isError:false when start_index exceeds content — agents loop forever

Reproduction

Server: mcp-server-fetch v1.27.2 via uvx mcp-server-fetch Transport: stdio, no auth

Fetch https://example.com with max_length=100 and incrementing start_index:

start_index=0   → isError:false  text: "Contents of…\n<error>Content truncated…start_index of 100…</error>"
start_index=100 → isError:false  text: "Contents of…\n.\n\n[Learn more]…"  (remaining content, no error)
start_index=200 → isError:false  text: "Contents of…\n<error>No more content available.</error>"
start_index=300 → isError:false  text: "Contents of…\n<error>No more content available.</error>"
start_index=999999 → isError:false  text: same

Every call past the end returns isError: false with an <error>No more content available.</error> tag buried in the text body.

Impact

An agent implementing pagination by checking MCP's isError field will never see a termination signal — every response "succeeds." The stop condition is an <error> XML tag inside the response text, which the agent must regex-parse to detect.

This is an in-band/out-of-band mismatch: the MCP protocol's structured isError field says "success" while the actual content says "error." Agents that follow the MCP contract (check isError, use text if false) will:

1. Loop forever past end-of-content
2. Accumulate <error> tags as if they were real content
3. Feed error messages into downstream processing as valid data

Workaround

Agents must check for <error>No more content available.</error> in the response text, not rely on isError.

Question

How do you handle end-of-pagination detection when using mcp-server-fetch for content that exceeds max_length? Is there a convention for agents to reliably detect the stop condition without parsing XML tags from the response body?