🚀 MCP Design: Your MCP Needs a ‘Run API’ Tool Unlike workflow automation tools where a ‘Run API’ block comes with real trade-offs, in a Model Context Protocol (MCP) setup, it’s almost all upside. Each week I review how agents use the “all_monday_api” tool in our MCP and analyze 👉 “Why did the agent choose this tool instead of a predefined one?” That question turns into a product goldmine. When I see patterns, I promote those use cases into native tools—and watch adoption shift naturally. But first, what is this ‘Run API’ thing? Both Make and Zapier offer a special kind of action: an API call endpoint. It lets you send free-form API requests, bypassing the limits of prebuilt connectors. Hugely powerful, but not without its challenges. ✅ The Benefits in Automation Tools 1️⃣ Fills the gaps: Handles long-tail use cases not yet covered by connectors. 2️⃣ Future & past ready: Use unreleased or legacy API features. 3️⃣ Custom flexibility: Control headers, params, and payloads however you like. ⚠️ The Drawbacks in Automation Tools 1️⃣ Maintenance burden: You own the upkeep when APIs change. 2️⃣ Technical barrier: Requires comfort with APIs, auth, and formatting. 3️⃣ Debugging headaches: Fewer guardrails, harder to troubleshoot. 💡 Why It’s Different in MCP Here’s where it gets exciting: in MCP, you get the same benefits without many of the drawbacks. 1️⃣ No maintenance burden → The agent writes calls dynamically, upgrading as your API evolves. 2️⃣ No technical barrier → The agent handles the API knowledge for you. 3️⃣ Simpler debugging → Fewer abstractions means the difference between this tool and others is pretty minor Exposing such a tool gives you a huge leap forward: Consumers of your MCP instantly become 10x more capable, and you gain clear insights into what native tools to build next. 🚨 The Downside Not all agents are equal. The more complex your API—or the less documented it is—the more likely they are to get calls wrong. In my experience, Claude is the standout performer here. For GraphQL in particular, things get tricky. We had to expose our schema through three supporting tools: get_graphql_schema → Lists available queries, mutations, and types. get_type_details → Shows full structure for any type, arguments, and fields. all_monday_api → Executes the crafted GraphQL query/mutation. ⚠️ And here’s the part I can’t stress enough: The all API tool is often extremely dangerous. By design, it gives the agent the power to do anything your API allows. That’s incredible flexibility—but it also means a mis-written prompt can accidentally cause unintended consequences. 👉 My Take “Run API” tools are a fantastic escape hatch for advanced use cases. In MCP, they evolve into something even more valuable: a feedback loop that guides what you should productize next. Interested in good MCP design? Check out some of my other posts in the first comment. #MCP #AI #ProductManagement #APIDesign #DevEx
ever watch your MCP go off the rails in the middle of an action, and desperately try to cancel it before it finishes and wrecks your data? 🙋♂️
Yeah the part you stressed at the end - about how with great power comes great responsibility is spot on. You could start by leaving out PUT, PATCH and DELETE; understand the specific use cases users are trying to achieve with the freeform API tool call, and then build that tool with better guardrails.
Interesting. So predefined tools resolve to specific REST or GraphQL API calls? And this handles unanticipated use cases, right? I’ve seen MCP servers that are very curated and those rhat mirror specific endpoints just from an OpenAPI doc (the latter makes it easy to just regenerate when the underlying API changes)
Daniel Hai great insights there. Yu-Sheng Kuo is building a tool set for agents (and people) that can add a few layers of protection/control to your MCP executions. Check out Datagen.dev
MCP | API | AI Product Manager @ monday.com
3wInterested in MCP design? here are some additional things I wrote about Article: Three Principles That Changed How We Design Our MCP Tools @ monday.com https://www.linkedin.com/pulse/three-principles-changed-how-we-design-our-mcp-tools-mondaycom-hai-smacc/ Post: MCP Tool Design: The Hidden Cost of Token Waste https://www.linkedin.com/posts/daniel-hai_mcp-ai-productmanagement-activity-7377243004304007168-W1Xw Post: The Future of MCP: Introducing MCP UI https://www.linkedin.com/posts/daniel-hai_ai-futureofwork-aiinnovation-activity-7378755488949198848-KZaY