From Prototype to Product: The MCP Gap

▶ Watch (2:00)

MCP servers started as competitive advantages. Clients asked how to use them. Today, clients look at you weird if you don’t have one. Derks’s first MCP server was a shallow wrapper around existing API endpoints and SDKs. He added standard IO and made it available to an MCP client. The real work was just getting the agent to call the tools instead of saying “I’m not able to help you.” Tool descriptions matter. Generic tools cause models to fail.

Tool Design: Two Strategies for Predictable Outputs

▶ Watch (11:05)

Open API to MCP creates problems. Six endpoints with get, put, and delete methods become 30 tools. That bloats the context window. Derks outlined two solutions. First, design for specific use cases. A “refund customer by email” tool condenses three tool calls into one. Second, use a layered design with discovery, planning, and execution phases. Give the model three tools instead of hundreds. The MCP server handles the rest.

Productizing MCP: Testing, Consistency, and GA

▶ Watch (17:31)

Baghel listed hard-learned lessons for taking MCP to market. A solid API testing strategy is required. Manual testing leaves gaps. Folder structures and programming language choices matter in enterprise environments. A Java shop should not write MCP servers in JavaScript. Implement tools first. Resources and sampling take time for MCP clients to support. Enable telemetry to track success and errors. Eval is critical but easier said than done.

Release Strategy: Remote vs. Local

▶ Watch (20:48)

GA for MCP servers differs from traditional SaaS. You depend on MCP clients. Baghel suggested the release cadence might flip. The remote version becomes the stable long-term support release. Local binaries or community versions can host experimental features and prompt engineering strategies. Tweaking tool descriptions after GA is acceptable. Removing tools after GA is an anti-pattern.

Notable Quotes

I think you need a a very solid like robust API testing strategy. I think uh manually testing a lot of these tools are fine but we still had gaps in uh you can’t test all the tools all the time when you have new engineers kind of coming on your team like when your leadership kind of starts taking this stuff seriously. Gautam Baghel · ▶ Watch (17:38)

So design for use cases or outcomes if you’ve identified some instead of leaving it up to the large language model to to decide. Roy Derks · ▶ Watch (13:08)

if you’re a Java shop or if you’re a Goline shop and if you’re writing an MCP server in JavaScript or or TypeScript or or or Golang like it’s not going to be picked up like later on by whoever ever is going to manage this long term, right? Gautam Baghel · ▶ Watch (18:23)

Key Takeaways

  • Design MCP tools for specific customer outcomes, not generic API endpoints.
  • Use a layered tool pattern with discovery, planning, and execution phases.
  • Standardize folder structures and programming languages for enterprise maintainability.
  • Release remote versions as stable and local versions for experimentation.

About the Speaker(s)

Roy Derks is a lifelong software developer, author and public speaker from the Netherlands. Currently chasing his dreams in Silicon Valley, California. Roy’s mission is to make the world a better place through technology by inspiring developers all over the world, more specifically…

Gautam Baghel is a passionate technologist who thrives on solving DevOps puzzles and building meaningful solutions. He’s all about automating stuff, streamlining workflows, and building scalable systems. Through his talks, Gautam shares practical insights and inspires others to dive into…