This presentation introduces the Microservice Communication Protocol (MCP), a new standard enabling Large Language Models (LLMs) to interface with real-world applications. David from Neon, a serverless Postgres provider, highlights MCP's rapid adoption by major LLM platforms and explains the core components of an MCP server, primarily "tools" representing actions. The presentation then focuses on the critical pitfalls of automatically generating MCP servers from existing OpenAPI specifications. David details four main problems: APIs are too extensive for LLMs, descriptions are not optimized for LLM comprehension, APIs focus on low-level resource management while LLMs need task-oriented actions, and auto-generation misses opportunities for creating specialized, multi-step LLM-centric workflows (illustrated with a database migration example). The presentation concludes by advocating for a hybrid approach: starting with auto-generation but rigorously culling unnecessary tools, refining descriptions, and developing specific LLM-focused functionalities, all backed by comprehensive testing.
Summarizing the Transcript: Building Effective MCP Servers for LLMs
0:00 Introduction to MCP Protocol: David from Neon introduces MCP (Microservice Communication Protocol), a new (6-7 months old) open protocol by Anthropic that standardizes how LLMs (Large Language Models) interact with real-world applications and services.
0:09 Rapid Adoption of MCP: Major LLMs like Windows Co-pilot, Google Gemini (newly announced), OpenAI's ChatGPT, and Anthropic's Claude already support or will soon support MCP, making it crucial for applications to build MCP servers to integrate with LLMs.
0:57 Core Components of an MCP Server: MCP servers expose "tools," "resources," and "prompts" to LLM clients. "Tools" are the most critical, representing actions an LLM might want to perform (e.g., creating a Postgres database for Neon).
3:10 Real-World Application Example: Neon's MCP server allows an LLM client (like Cursor) to provision a Neon Postgres database and build a functional application within minutes from a simple natural language prompt.
4:11 The Challenge of MCP Server Creation: While MCP is powerful, building an MCP server is complex (Neon's is ~500 lines of code). Many companies rush to auto-generate them from existing OpenAPI specifications using third-party services.
5:30 Problem 1: Excessive Tools Confuse LLMs: Auto-generating from OpenAPI specs typically exposes too many API endpoints as MCP tools. LLMs struggle with extensive lists of options and perform better with a reduced context size, leading
Error: Column.new() missing 6 required positional arguments: 'cid', 'name', 'type', 'notnull', 'default_value', and 'is_pk'. Tools should be meticulously described (e.g., Neon uses XML for highly organized, contextual descriptions) and rigorously tested via "evals" (AI-specific tests).
8:47 Problem 3: Misaligned API Design Philosophies: Traditional APIs are designed for low-level resource management and automation, whereas LLMs need task-oriented actions and tools to achieve specific goals, necessitating a different design approach for MCP tools.
9:54 Problem 4: Missed Opportunities for Advanced LLM Workflows: Auto-generation prevents the creation of custom, multi-step LLM-centric tools. For instance, Neon developed specialized prepare database migration and complete database migration tools to guide LLMs through a safe, staged migration process on a temporary branch, a workflow not typically found in standard REST APIs but highly beneficial for LLMs.
12:44 Recommended Hybrid Approach: David advises against full auto-generation. Instead, he suggests a hybrid method: auto-generate an initial MCP server from an OpenAPI schema, then critically "cut down" unnecessary tools, refine and optimize descriptions for LLMs, and design new, interesting LLM-specific tools and workflows, all validated with continuous "evals" (tests).