Why Standard APIs Fail Agents — and How Webflow Redesigned Its MCP Server

When Webflow started building for Model Context Protocol (MCP) in early 2025, the team discovered a counterintuitive problem: wrapping existing APIs as MCP tools wasn't enough. Developer-facing APIs are designed with the assumption that humans can read documentation, research options, compose sequences of granular operations, and manually recover from failures. Agents, by contrast, operate with far less contextual knowledge and depend on the API surface itself to guide decision-making and execution recovery.

The consequences were stark. Straightforward tasks turned into unnecessarily complex chains of API calls. A simple request to update a website's homepage hero image might require fetching page lists, identifying the correct page, retrieving its content structure, locating the hero section, and then applying changes—all while the agent had to preserve intermediate state, disambiguate results, and decide whether failures were recoverable.

Why Agents Need Different API Design#

Early attempts to expose low-level developer APIs directly as MCP tools created several failure modes. Each additional tool invocation consumed more tokens, increased latency, added context pressure, and raised the overall probability of execution breakdown. The model had to:

• Preserve intermediate resource identifiers across multiple calls
• Select the correct resource when results were ambiguous
• Interpret generic or incomplete API responses
• Sequence dependent operations while maintaining state
• Judge whether failures merited retrying or represented terminal problems

Even when technically feasible, the agent spent too much of its computational budget navigating the API rather than accomplishing the user's actual goal.

The solution seemed obvious: move to task-level tools that matched user intent directly. Instead of chaining multiple low-level calls, an agent could invoke a single unified operation—something like update_page_section({ page: "home", section: "hero", changes: { heading: "..." } }). This approach collapsed complex workflows into declarative requests, letting the platform handle internal orchestration while the agent focused on the goal.

The Scaling Challenge: Avoiding Tool Explosion#

But this created a new problem at Webflow's scale. Supporting every conceivable user workflow as a separate standalone tool would result in hundreds of overlapping capabilities that agents would struggle to navigate efficiently.

Webflow responded with two complementary strategies: