MCP instability when connecting Google Calendar (native MCP vs Zapier MCP) – execution succeeds but tool response fails

API Bugs
1

Hello everyone,

I’m sharing this experience in case it helps others and also to understand whether this is a known or expected limitation of the current MCP ecosystem.

I’m building an assistant using OpenAI Platform – Agent Builder, whose purpose is to consult (read-only) a Google Calendar availability calendar and return availability information to clients. No bookings, no modifications, only availability checks.

1. Native Google Calendar MCP (OpenAI Platform)

My first attempt was using the native Google Calendar MCP inside Agent Builder.

  • Authentication and permissions were correctly set.

  • The assistant was able to authenticate, but calendar selection and consistency were problematic, especially when working with multiple calendars (primary vs availability calendar).

  • Results were unreliable or empty in some cases, even when the calendar clearly had busy periods.

2. Zapier MCP as an alternative

To improve reliability, I switched to Zapier MCP, using:

  • Google Calendar → Find Busy Periods in Calendar

  • A shared availability calendar

  • A simplified setup focused only on detecting busy periods

Here’s the important part:

  • Zapier executes the action correctly

  • The Google Calendar query returns valid data (confirmed in Zapier logs)

  • Example output returned by Zapier includes correct start/end times and busy periods

However…

3. MCP response failure in OpenAI

Despite the successful execution in Zapier, OpenAI Agent Builder intermittently logs an MCP error (503 Service Unavailable / MCP protocol error).

  • The tool execution clearly succeeds on the Zapier side

  • The failure happens when the MCP tries to return the result to OpenAI

  • As a result, the agent receives an empty or failed tool response and cannot produce a final answer

I will attach screenshots showing:

  • Successful Zapier execution with valid output

  • OpenAI Agent Builder logs showing MCP 503 errors

  • The agent behaving correctly by refusing to hallucinate when no tool output is received

4. Conclusion / Question to the community

From my testing, this appears to be an MCP transport / stability issue, not a configuration, permission, or prompt problem. It also seems consistent with other reports of MCP instability across different tools.

Questions for the community / OpenAI team:

  • Is MCP currently considered production-stable for tool-based integrations like Google Calendar?

  • Are intermittent 503 / protocol errors expected behavior at this stage?

  • Is there a recommended pattern (proxy, retries, intermediate services) to mitigate this?

  • Are there plans to improve MCP reliability or observability?

Happy to provide more technical details if helpful. I’m sharing this in good faith to improve the ecosystem and help others facing similar issues.

Thanks in advance.

image
image390×593 32.3 KB

2

What you’re seeing is unlikely to be a permissions problem or an issue with the calendar logic. It more likely reflects a transport or protocol reliability issue inside the current MCP pipeline, especially at the point where results are returned to Agent Builder. In many cases MCP can still be unstable under load or when responses are slow or slightly larger, which explains the intermittent 503 or protocol failures even though Zapier completes the action successfully. A practical workaround is to add a thin proxy layer or webhook that receives the Zapier output, normalizes it, applies retries and timeouts, and then exposes a simple deterministic tool to the agent. This gives better observability and reduces failure points. Until reliability improves, I would treat MCP as early-stage production and design around retries, idempotent operations, and fallbacks

1 Like
3

Hi @OsamaEid

Sorry do not reply before :folded_hands:

Thanks a lot for your brilliant reply, 100% in order with you.

Have a nice day! :slightly_smiling_face: