AI
MCP Adoption Is Accelerating Fast
MCP is six or seven months old. Windows Copilot, Gemini, OpenAI, and Claude have all committed to it. Some of those announcements landed the same week as this talk. That adoption curve has one practical consequence: if you want LLMs to use your service, you need an MCP server. The Neon MCP server live demo, Cursor builds a to-do app with a real Postgres database (03:17) shows the pattern: a Cursor user types “Build me a to-do list app, use Neon postgres, and use Neon auth,” Cursor calls the MCP server, and a provisioned Postgres database appears in minutes.
Tool Count Is the First Failure Mode
Neon’s API has 75 to 100 endpoints. Autogenerating an MCP server from that OpenAPI spec dumps every one of them into the tool list. LLMs are bad at choosing from long lists, and bigger context windows don’t fix this. Performance drops as context grows, not the other way around.
“LLMs perform much better with a reduced context size.” — David Gomes
Fewer tools produce better results. That is the first cut any MCP server needs before it goes anywhere near an agent.
API Descriptions Are Written for Humans, Not Agents
Existing API documentation assumes a developer who can search for missing context and reason through ambiguity. LLMs need the opposite: direct instructions, explicit examples, and no gaps. Neon writes its tool descriptions in XML with structured context about each tool and when to use it. A standard API spec never contains that.
Then they run evals, 100 or 1,000 or 10,000 times, to verify that the right tool gets called for the right job. LLMs are nondeterministic, so one passing run proves nothing. Iterating on descriptions until evals consistently pass is what reliability actually looks like.
APIs Model Resources; Agents Need Tasks
REST APIs exist so developers can automate low-level resource management. That is not what an agent needs. An LLM doesn’t want to “create a branch,” “modify a table,” and “apply a diff” as three separate calls. It wants to complete a task.
“LLMs need tasks. They need actions and tools.” — David Gomes
Anthropic built MCP because OpenAPI schemas were never designed for goal-oriented interactions. Tools should map to outcomes, not CRUD operations. That design shift is the whole point of the protocol.
Purpose-Built MCP Tools Outperform Generic SQL
A generic “Run SQL” tool covers database migrations, but Neon built two purpose-built replacements. Prepare Database Migration stages changes on a temporary Neon branch, then returns an instruction: test the migration before committing. Complete Database Migration finalizes it against the main branch. LLMs are not strong at SQL, so the two-step flow adds a checkpoint the REST API never offered.
“The worst thing you can give an LLM is too much choice.” — David Gomes
The practical path: autogenerate from your OpenAPI spec, strip non-essential tools, rewrite descriptions for LLMs, add purpose-built tools, then write evals.
Notable Quotes
LLMs perform much better with a reduced context size. David Gomes · ▶ 6:39
LLMs need tasks. They need actions and tools. David Gomes · ▶ 9:12
The worst thing you can give an LLM is too much choice. David Gomes · ▶ 13:22
Key Takeaways
- Autogenerating an MCP server from an OpenAPI spec gives LLMs too many tools and degrades accuracy.
- Tool descriptions need XML structure, explicit context, and evals run thousands of times to hold up.
- Purpose-built tools that model tasks, not resources, unlock capabilities no REST API would expose.