Thanks — you’re asking whether MCP tool calls have a built-in retry mechanism and, if not, how to add retries. I’ll address both parts and give practical options you can use right away. Short answer • There is no documented built-in retry mechanism for MCP tool calls. • You can implement retries yourself either at the client/agent layer, with a proxy/gateway in front of the MCP server, or by providing a custom function tool that implements retry logic. How you can implement retries (three practical approaches) 1) Add retry logic in your agent/client when calling MCP • Wrap the HTTP calls to the MCP server in a retry-capable HTTP client (exponential backoff, jitter, and max attempts). This is the simplest if you control the agent implementation that does the MCP requests. • Example patterns/libraries: ◦ Python:

tenacity

or

aiohttp

with custom retry/backoff ◦ Go:

hashicorp/go-retryablehttp

(already used elsewhere in the system for other HTTP retries) • Retry strategy suggestions: ◦ Exponential backoff with jitter ◦ 3–5 attempts by default ◦ Retry only on transient errors (network errors, 5xx responses); do not retry on 4xx client errors unless they are transient. 2) Put a retrying proxy/gateway in front of the MCP server • Deploy an HTTP proxy that forwards requests to the MCP server and adds robust retry/backoff behavior. • Useful when you cannot or prefer not to change each agent instance. • Keeps retry behavior centralized and easier to tune. 3) Implement a custom function tool that performs the MCP action with retries • Instead of relying solely on the auto-discovered MCP tool, register a custom function tool that wraps the MCP call and includes retries. • This gives you full control from within the tool execution path that the LLM invokes. Implementation example (Python + tenacity)

from tenacity import retry, stop_after_attempt, wait_exponential
import aiohttp

@retry(stop=stop_after_attempt(4), wait=wait_exponential(multiplier=1, max=10))
async def call_mcp_with_retry(mcp_url, payload, session: aiohttp.ClientSession):
    async with <http://session.post|session.post>(mcp_url, json=payload) as resp:
        resp.raise_for_status()
        return await resp.json()

Additional recommendations • Log each attempt and final failure so you can monitor frequency and root causes. • Add idempotency when possible (so retries are safe). • Use health checks and alerts on the MCP server to detect systemic failures rather than just retrying forever. • If you control the MCP server, add server-side retryable behaviors for transient internal errors where appropriate. If you want, I can: • Suggest a concrete retry policy (attempts, backoff, which status codes to retry) tailored to your environment. • Provide a specific code snippet for your stack (Node/Go/Python) or an example proxy configuration. Which language or integration are you using for the agent (Python, Go, Node)? That will help me give an exact code example or configuration. Sources: Tool definition and use | LiveKit Documentation | MCP Agent | LiveKit Documentation | Agent Builder | LiveKit Documentation | livekit/livekit_composite | DeepWiki | server-sdk-go | livekit/livekit_composite | DeepWiki