Introduction
While working on a chat-based automation prototype, I got the opportunity to explore integrating a Zapier MCP server into a chat-based system. The goal was to allow users to trigger real-world actions directly from chat without writing custom workflows for every use case.
This post explains how I approached the integration, the architecture I followed, how I designed the UI, and the problems I faced while working with Zapier MCP.
Understanding the architecture
Before writing any code, I focused on understanding the core components involved:
- Tools: Actions such as sending emails, updating spreadsheets, or creating tasks.
- MCP server: A server that exposes tools in a standardized way. In my case, this was Zapier MCP.
- MCP client: The LLM (Claude) that can discover and call available tools.
- MCP host: The application that connects user input, the LLM, and the MCP server.
Once these roles were clear, the overall system design became easier to reason about. MCP works as a bridge between LLMs and external tools, avoiding the need for manual integrations.
Overall flow
The flow I followed in the system was straightforward:
- The user provides input
- The LLM discovers relevant tools
- The LLM maps the user intent to tool instructions
- Tools are executed via Zapier MCP
- The LLM formats the final response
This can be summarized as:
User intent → tool discovery → tool execution → formatted response
Tool discovery and execution
In practice, the process looked like this:
- Available tools and user input are sent to Claude
- Claude returns a list of relevant tools
- The discovered tools are sent back to Claude to map instructions
- Zapier MCP executes the instructions
- Claude formats the tool responses into a final output
This approach required multiple LLM calls, which later became one of the main drawbacks.
Setting up Zapier MCP
Setting up Zapier MCP was relatively simple.
I created a Zapier account, selected the tools I needed, enabled the Zapier MCP server, and copied the MCP server URL and API key. This MCP endpoint was then connected to Claude using the Anthropic Messages API.
Once connected, I could query the system to discover available tools, and Zapier MCP handled the execution layer reliably.
UI design
The UI was intentionally minimal.
It consisted of a chat input, a panel showing active tool execution states, and a final section displaying completed results. The goal was to make tool usage transparent so users could see what was running and when execution was complete.
This helped reduce the feeling of a black box system.
What worked well
Zapier MCP was easy to integrate and worked well for quick experimentation. It removed the need to manually connect multiple APIs and allowed the LLM to focus on intent and orchestration.
For fast iteration and prototyping, this setup was effective. I briefly tried n8n as well, but it felt heavier for quick experiments, so Zapier was a better fit for my workflow.
Limitations and frustrations
There were a few clear limitations.
Multiple LLM calls
To produce a single clean response, the system required separate LLM calls for tool discovery, instruction mapping, and response formatting. Reducing these steps without adding extra glue code would improve the developer experience.
Closed source nature
Zapier is closed source, which limits visibility into internal execution. Debugging and customization beyond the exposed interface are restricted.
Limited control
While the abstraction is useful for speed, it also means giving up fine-grained control over execution logic, which can be an issue for complex workflows.
Conclusion
Integrating Zapier MCP into a chat system was a solid experience overall.
It works well for rapid development, experimentation, and proof-of-concept builds. However, for advanced workflows that require deep control and visibility, additional layers or alternative approaches may be needed.
This experiment helped me better understand how LLM-driven tool orchestration can be built using MCP-based systems.
Top comments (0)