Last year we thought that turning an OpenAPI spec into an MCP server was a shaky default. We’ve sort of changed our mind:

We were against the OpenAPI <> MCP server path for two reasons: 1. Tool definitions ate the context window: a large API meant hundreds of schemas in the prompt before the model even read the request 2. A REST operation is not a task: APIs are built around resources, but agents were trying to finish jobs

Things have evolved since 2025. First, MCP clients do progressive tool discovery now - they search a catalog, inspect only the tools they need, then execute. This solves our first objection - or better said, selection and composition are now client problems

Our second objection (mapping every endpoint 1:1 to a tool) still stands. A REST call is still a poor agent tool. Progressive discovery can find every endpoint, it cannot turn those endpoints into a job. If the agent has to rediscover everything on every run, it burns tokens and makes the same mistakes.

The thing is, we already invented something that solves this - SDKs. They give you the raw endpoints together with methods that bundle the common paths. And coding agents make building SDKs much cheaper than ever before (aside token costs, of course). Agent tools can work the same way: - The server decides what is available - The client decides how to discover and run it.

From this principle, we’ve built @neon/tools - It turns the Neon SDK into typed agent tools - Generated schemas stay in sync with the API - A reviewed layer adds polling and workflows - Tools wrap that layer - You pick the methods the agent needs

That same catalog now sits behind Neon MCP. The hosted server now exposes 82 API tools from @neon/tools (68 of them new) next to the hand-written SQL, migration, and docs tools.

We also built a native adapter for @mastra @neon/tools/mastra exposes all Neon Management API tools for Mastra agents

We also built a native adapters at @neon/tools/eve for @eve agents to quickly take advantage of Neon Management API tools

@eve If you’re building agentic platforms or a personal agent, @neon/tools plus the Eve and Mastra adapters are for you. We share the full story in this blog post:

the reversal is interesting: what changed your mind most, schema fidelity or the generated server’s handling of auth and errors?

The failure mode we hit was not the generation, it was granularity. One tool per endpoint gives the model forty verbs and no opinion about which to use. Eighteen hand-picked ones beat a faithful translation of the API every time.

the reversal on OpenAPI-to-MCP is interesting; was the deciding factor generated server quality or the maintenance savings over hand-built integrations?