From Human-Readable to Machine-Usable: The New API Stack

Ben Lorica

Sagar Batchu on Tool Calling, MCP Servers, and the Future of Agentic Workflows.

Subscribe: Apple • Spotify • Overcast • Pocket Casts • AntennaPod • Podcast Addict • Amazon •  RSS.

Sagar Batchu, CEO of Speakeasy, joins the podcast to discuss the critical shift in API development as AI agents become primary consumers. He breaks down the rise of the Model Context Protocol (MCP) as the standard for enabling LLMs to use external tools and services. Sagar offers practical insights for technical teams on how to design, secure, and host effective MCP servers to power the next generation of AI applications.

Subscribe to the Gradient Flow Newsletter

Interview highlights – key sections from the video version:

Related content:

Support our work by subscribing to our newsletter📩

Transcript

Below is a heavily edited excerpt, in Question & Answer format.

Understanding Speakeasy and the Modern API Landscape

What problem does Speakeasy solve for engineering teams?

Speakeasy aims to make building, developing, and releasing APIs easy for companies, whether internal or external. The goal is to help teams achieve “Stripe-level” API quality without building a homegrown toolchain. This has become even more critical as API consumers are no longer just humans, but also AI agents and LLMs. The platform provides a modern, developer-centric solution that fits naturally into existing development workflows, working with standards like OpenAPI and integrating seamlessly with CI/CD pipelines.

What were the common pain points for API development teams before Speakeasy?

Before modern toolchains, teams relied on a mix of homegrown experiences, duct-taped solutions, and inconsistent open-source tools. While companies like MuleSoft and SmartBear existed, their products were designed for top-down, enterprise “API-first transformations” rather than organic, developer-led adoption. This meant most teams needed significant investment in custom tooling and often required a designated “API guru” or platform team. Doing this at scale across organizations with competing priorities and multiple APIs was a major challenge involving collaboration, design, and runtime infrastructure problems.

The Rise of AI and the Model Context Protocol (MCP)

How has AI fundamentally changed the landscape for APIs?

AI has become a massive accelerant for API adoption. For an LLM to be truly useful in an organization, it needs access to key data and services through APIs – otherwise it’s just a smart system without context. We’ve evolved from fine-tuning and basic RAG to giving LLMs controlled access to real-time data and functions via APIs. This has created huge demand for more APIs that are well-designed, reliable, and high-throughput. AI is becoming the biggest consumer of APIs, dramatically expanding the total addressable market and raising the quality bar.

What is the Model Context Protocol (MCP) and why is it gaining traction?

MCP is an open protocol, initially developed by Anthropic, that standardizes how LLMs discover and interact with external tools (which are essentially APIs). At its core, it’s a client-server relationship that defines expectations for how API operations are described and structured for LLM consumption. It’s gaining massive traction because it provides a common, open standard for “tool calling” that any company can implement to expose services in a way that any compliant LLM client or agent can understand and use.

How does MCP’s approach differ from OpenAI’s function calling?

While both solve the tool calling problem, the key difference is openness. OpenAI’s function calling is a feature within their ecosystem that requires using their SDK – it’s not an open specification. MCP is an open standard published on GitHub, meaning anyone can build a server that adheres to the standard and any client can connect to it. This open approach fosters a broader ecosystem, similar to how OpenAPI drove massive adoption for REST APIs by providing a common language anyone could build towards.

What are the three waves of MCP adoption you’ve observed?

Wave one was initial excitement where everyone started building MCP servers locally, but quickly realized requiring users to run local servers was impractical. Wave two shifted to remote MCP servers hosted by the companies providing the APIs – similar to how companies provide official documentation sites. Wave three, happening now, involves platforms and products that help aggregate, discover, and interact with MCP servers – creating a real ecosystem around the protocol with proper tooling for production use.

Is it concerning that Anthropic controls the MCP standard?

Having a main company driving an open protocol actually ensures quality and clear direction, preventing the standard from languishing without ownership. The history of OpenAPI shows that lack of a singular, committed owner can slow progress. The beauty of an open protocol is that development happens publicly on GitHub. The true test will be how Anthropic incorporates community feedback. So far, they’ve done a great job balancing open development with clear leadership.

Building and Managing MCP Servers in Practice

What’s the process for transforming an existing REST API into an MCP server using Speakeasy?

The process involves three main steps: creation, curation, and hosting. Speakeasy ingests your existing API specification (like OpenAPI) and automatically generates the boilerplate code for your MCP server. During curation, you design the MCP experience – you might not want one-to-one API exposure. You can select endpoint subsets, combine multiple APIs, or create new tool combinations optimized for LLM interaction. Finally, hosting involves deploying on managed infrastructure with rate-limiting, telemetry, OAuth, and versioning built in. This entire process can take minutes instead of weeks.

What design considerations are critical when creating MCP servers for LLMs?

LLMs don’t perform well with raw API endpoint lists. Key considerations include:

  • Tool count limitations: Current models handle 30-40 tools before performance degrades
  • Tool composition: Combining multiple API calls into single, intuitive tools
  • Clear descriptions: How tools are described significantly impacts LLM success rates
  • Pagination handling: Current models struggle with standard pagination patterns

For example, instead of exposing three separate calls to get a company, its projects, and API specs, it’s better to create one tool called “get_all_specs_for_a_company” that handles all operations internally. This curation dramatically reduces friction and failure rates.

What advantages does using a platform like Speakeasy provide over building MCP servers from scratch?

Beyond time-to-value (creating a public-ready MCP server in minutes), platforms provide crucial lifecycle management tools. This includes telemetry to understand usage patterns, evaluation systems to measure tool-call success rates, and AI-powered analysis of failures to suggest improvements. For instance, if 50% of tool calls are failing, Speakeasy can analyze the failures and suggest new, more effective tool designs. This continuous improvement cycle is difficult to build and maintain independently.

Should developers bypass traditional APIs and build MCP servers directly?

No. Developer-led integrations aren’t disappearing. There will be a long coexistence period between developer and AI-led integrations. For system-critical, high-throughput use cases, traditional developer integrations remain essential. The recommendation is to do both: provide excellent SDKs and documentation for developers today while launching MCP servers to prepare for agentic workflows. MCP expands your API’s total addressable market by making it accessible to non-developers through chat interfaces.

Does MCP replace the need for traditional API documentation?

Not at all. In fact, teams are creating MCP servers specifically for their documentation. Developers can query a “docs MCP” from their IDE to ask questions like “How does this feature work?” without leaving their development context. The MCP can be backed by RAG to pull information from READMEs, knowledge bases, and other content. So MCP isn’t just for API function interaction – it’s also a way to enable in-context learning about APIs.

Security, Governance, and Best Practices

What are the key security considerations when building MCP servers?

MCP security fundamentally relies on good API security – that’s the critical first step. The standard security model emerging for MCP is OAuth. Since MCP servers can aggregate multiple APIs, you need to handle authentication carefully – authenticate users once, then manage downstream authentication with different underlying APIs. This resembles how API aggregators work today. Because prompts can be used for injection attacks, there’s a higher security burden requiring monitoring and prompt-layer defenses.

Are cybersecurity companies developing MCP-specific security tools?

We’re still in early days. Teams are just beginning to understand how to run evaluations and measure MCP usage impact. Security concerns like prompt injection create unique challenges. There’s significant opportunity for security-focused tooling including penetration testing, load testing, and protection against prompt-based attacks. Expect a new wave of security tools tailored specifically to tool calling and agentic interactions.

Future Outlook and Practical Considerations

What limitations in foundation models currently block large-scale agent adoption?

Current models have significant limitations that developers must work around:

  • Tool quantity: Performance degrades after 30-40 tools in context
  • Reliability: Tool calls fail ~50% of the time without extra scaffolding
  • Pagination: Models struggle with common API patterns for large datasets
  • Tool selection: Poor reasoning about which tools to use and in what sequence

Foundation model builders can differentiate by improving native tool calling capabilities, allowing larger or dynamic tool sets, and exposing telemetry hooks for platforms to fine-tune behavior automatically.

What are the most promising use cases for MCP beyond text interactions?

Voice interactions present huge opportunities. Think about early voice assistants like Siri that struggled with taking action. Now, powerful voice models combined with MCP can enable experiences like saying “I’m running five minutes late to my next meeting. Could you email Ben and let him know?” with the entire interaction powered by tool calls. The same applies to multimodal models – video and audio interactions are essentially tool interactions, and MCP provides the framework.

How will MCP adoption impact API usage patterns and traffic?

MCP shifts APIs upstream in the development lifecycle, making them accessible to more people for more use cases. Traffic patterns will likely differ from traditional APIs, resembling Google search patterns (based on when people are awake and querying) rather than specific website interaction spikes. This means APIs need to be prepared for different load patterns and potentially higher, more distributed traffic as non-developers begin accessing services through conversational interfaces.

What tooling gaps still exist for developers building with MCP?

Key gaps include:

  • Hosting infrastructure (which Speakeasy addresses)
  • Usage analytics and insights for understanding interaction patterns
  • Tools for converting common prompts into new tool designs
  • Versioning and deployment management specific to MCP servers
  • Robust security and authentication solutions for agentic access
  • Evaluation frameworks for measuring and improving tool calling success rates

The ecosystem is rapidly evolving to fill these gaps, but teams building production MCP servers today need to consider these requirements carefully.