10:36Nate Herk | AI Automation · Listicle
I Tried 100+ GitHub Repos for Claude. These 6 Are the Best
A talking-head rundown of ten Claude Code tools the creator uses daily, from scriptable video editing to security testing and SEO.
October 11thThe argument in one line.
As MCP clients take over tool discovery (progressive discovery) and tool composition (code mode), servers should stop exposing one tool per API endpoint and instead bundle common multi-call workflows into single, ergonomic tools, the same way an SDK wraps raw endpoints.
Read if. Skip if.
READ IF YOU ARE…
- You're building or maintaining an MCP server and are deciding whether one-to-one API-to-tool mapping is still the right call.
- You're an AI agent developer weighing server-side tool curation against letting the client handle discovery and composition.
- You maintain a large or multi-step API and want a token-efficient way to expose it to LLM agents.
SKIP IF…
- You're brand new to MCP and haven't built or used a tool server yet — this assumes you already know what MCP tools are.
- You want a general AI-agent tutorial rather than a specific discussion of MCP tool-design architecture.
The full version, fast.
MCP clients are now handling tool selection through progressive discovery and tool composition through programmatic tool calling (code mode), which used to be problems servers solved on their own. That doesn't mean servers should go back to mapping every API endpoint to its own tool. Common multi-step workflows, like Neon's three-call branch creation, still waste tokens if an agent has to rediscover the chain every session. The fix mirrors how SDKs work: keep a raw-endpoint layer generated from the API spec, add a thinner ergonomic layer for bundled workflows like createWithCompute, and expose both as tool calls through a standalone package so it can power the MCP server and other agent-framework adapters alike.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 00:32
01 · Why MCP server design is changing
States the thesis: as agent usage of MCP grows, clients are taking over responsibilities that used to belong to the server.
00:32 – 01:04
02 · One-to-one API tools and context bloat
Mapping every API endpoint to its own tool gives full API coverage but bloats the context window and can confuse tool selection once endpoints look similar.
01:04 – 01:35
03 · Server-side layered tool discovery
Servers respond by collapsing hundreds of tools into a small layered set: search endpoints, inspect a definition, execute the request.
01:35 – 02:06
04 · Progressive tool discovery on MCP clients
The same layered pattern is now being implemented inside MCP clients themselves, a shift the industry calls progressive tool discovery.
02:06 – 02:38
05 · Programmatic tool calling (code mode)
Agents like Codex and Claude Code write scripts that chain tool calls together inside a sandbox, returning only the final result to the model.
02:38 – 03:11
06 · Why workflow tools still beat raw endpoints
Even with smarter clients, common multi-call workflows still waste tokens if an agent has to rediscover the same chain of calls every time.
03:11 – 04:13
07 · Neon createWithCompute: 3 API calls, one tool
Neon's branch creation is really three API calls; the SDK bundles create branch, attach compute, and get connection string into one createWithCompute method.
04:13 – 04:44
08 · SDK, neon-tools, and the Neon MCP server
Neon generates a full SDK from its OpenAPI spec, then adds a thinner ergonomic layer, and converts both into tool calls via the Neon Tools package.
04:44 – 05:14
09 · Framework adapters and tool categories
Because the tools live in a standalone package, they power the official MCP server and can be adapted for other agent frameworks like Mastra and Eve, organized into scopeable categories.
05:14 – 05:56
10 · Server owns tools; client owns discovery
Recaps the big idea and closes with an open-source pointer and a prompt for viewers to share their own MCP server approach.
Lines worth screenshotting.
- Mapping every API endpoint to its own MCP tool works, but a large API turns into hundreds of tools loaded into the context window before the session even starts.
- When the tool list gets crowded with similar-looking options, an agent can pick the wrong one for reasons that have nothing to do with the API itself.
- The layered tool call pattern replaces hundreds of tools with three: search endpoints, inspect a definition, execute the request.
- Progressive tool discovery, once a server-side pattern, is now being built directly into MCP clients like popular coding agents.
- In programmatic tool calling (code mode), the agent writes a script that chains tools together inside a sandbox, and only the final result returns to the model.
- Clients now handle both tool selection (progressive discovery) and tool composition (code mode), two problems that used to belong entirely to the server.
- Even with smarter clients, a strict one-to-one endpoint-to-tool mapping still wastes tokens on any workflow that always requires the same chain of calls.
- Neon's 'create a branch' action is really three separate API calls: create the branch, attach compute, and fetch the connection string.
- Bundling a fixed multi-call sequence into one method (createWithCompute) is the same efficiency trick SDKs already use to wrap raw endpoints.
- Neon generates its full SDK straight from its OpenAPI spec, then adds a thinner ergonomic layer on top with the bundled, common-workflow methods.
- Pulling MCP tools into a standalone package (Neon Tools) lets the same tool definitions power the official MCP server and custom adapters for other agent frameworks.
- Organizing tools into categories lets a team scope down exactly which tools a given agent can access, instead of all-or-nothing.
- The dividing line going forward: the server decides which tools exist, the client decides how to discover and execute them.
Servers pick the tools, clients now pick how to use them
MCP SERVER DESIGN
As MCP clients take over tool discovery and tool-chaining, servers should stop mapping every endpoint 1:1 and instead bundle common multi-call workflows into single ergonomic tools.
01Why MCP server design is changing
- MCP usage by agents is growing fast enough that the old server-side conventions for exposing tools are already being rewritten.
02One-to-one API tools and context bloat
- Mapping each API endpoint straight to its own tool gives an agent full coverage of your API, but at real cost once the API is large.
- Hundreds of similar-sounding tools loaded up front can make an agent pick the wrong one, independent of any flaw in the underlying API.
03Server-side layered tool discovery
- Replacing hundreds of one-to-one tools with a search, inspect, and execute tool cuts what gets loaded into context before a session even starts.
- A layered tool call approach trades some directness for a dramatically smaller, more manageable tool list.
04Progressive tool discovery on MCP clients
- The same layered-search pattern that used to live inside the server is now being built directly into MCP clients like coding agents.
- When the client owns tool discovery, the server no longer has to solve that problem on its own side.
05Programmatic tool calling (code mode)
- In code mode, an agent writes a script that chains multiple tool calls together and runs it in a sandbox instead of calling tools one at a time.
- Only the sandbox script's final result comes back to the model, so intermediate tool outputs never eat into the context window.
06Why workflow tools still beat raw endpoints
- With clients now handling both which tool to pick and how to chain tools together, servers are losing two problems they used to own.
- That shift raises an obvious but wrong conclusion: that servers can now safely go back to a full one-to-one API mapping.
- Even a smart client still has to reinvent the same multi-call workflow every time if the server only exposes raw, individual endpoints.
- Making an agent rediscover a fixed sequence of calls on its own, every session, burns tokens for no real benefit.
07Neon createWithCompute: 3 API calls, one tool
- SDKs solve this exact problem for human developers: raw endpoints for flexibility, plus bundled methods for the workflows everyone actually uses.
- Creating a Neon branch is really three API calls (create branch, attach compute, get connection string) collapsed into one method, createWithCompute.
- A simple, low-complexity API can stay one-to-one; the bundling effort only pays off once provisioning gets multi-step and easy to get wrong.
08SDK, neon-tools, and the Neon MCP server
- Generating the SDK straight from the OpenAPI spec guarantees full endpoint coverage without hand-maintaining a mapping for every route.
- The ergonomic layer sits on top of the generated raw-endpoint layer and is where bundled, multi-call methods like createWithCompute actually live.
- Pulling all of this into its own package (Neon Tools) decouples the tool definitions from any single MCP server implementation.
09Framework adapters and tool categories
- The same tool package can power the official MCP server and be adapted for other agent frameworks, since the tools themselves aren't server-specific.
- Organizing tools into categories lets you scope down exactly which tools a given agent gets access to, instead of all-or-nothing.
10Server owns tools; client owns discovery
- The clean split going forward: the server decides which tools exist at all, the client decides how to discover and run them.
Terms worth knowing.
- MCP (Model Context Protocol)
- A standard way for AI agents to discover and call external tools, letting one agent connect to many different backends through the same interface.
- Progressive tool discovery
- A client-side pattern where an agent searches for and loads only the tools it needs for a given task instead of every tool being listed up front.
- Programmatic tool calling (code mode)
- An agent writes a script that calls multiple tools inside a sandboxed environment, and only the script's final output is sent back to the model rather than every intermediate tool result.
- Ergonomic layer
- A thin layer added on top of raw, auto-generated API bindings that bundles common multi-step workflows into single, easier-to-use methods.
- OpenAPI spec
- A machine-readable description of an API's endpoints and data shapes, commonly used to auto-generate SDKs and documentation.
Things they pointed at.
04:55toolMastra
04:55toolEve (agent framework)
Lines you could clip.
00:00
“MCP is blowing up right now.”
02:18
“So surely this means we can just go back to the original method of doing a one-to-one mapping of API endpoints to tool calls, right? Not quite.”
05:31
“The server is controlling what tools are available, but then the client handles discovering and executing those tools in whatever way it sees fit.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
analogy
MCP is blowing up right now. Agents usage of MCP is increasing exponentially and it's not showing any signs of slowing down. But at the same time, many agents are now changing the way that they handle tools and starting to take over responsibilities that used to belong to the server.
So what does all of this mean for the way that we build MCP servers? Well, let's break it all down. When MCP first hit the scene, one of the most common approaches for building MCP servers was to just map each of your API endpoints to its own tool.
And by doing this, an agent was able to access the full range of your API surface area. And this implementation worked, but It presented two major issues.
First, if your API had hundreds of endpoints, then that meant your MCP server had hundreds of tools. And all of these tools would be loaded into the context window up front, meaning that before you even started your session, your context window could have been completely bloated by MCP tools. And secondly, if you had lots of endpoints that were similar to each other, an agent might end up getting confused and not pick the right tool for the job.
In order to solve some of these problems, a lot of MCP servers adopted a layered tool call approach. So now instead of listing out hundreds of tool calls, you might just have two or three. You might have a tool to search all of the available endpoints, a tool to inspect the definition of a specific endpoint, and a tool to execute the request.
This pattern has seen a lot of adoption, but this is now where the big change happens. Traditionally, this pattern was implemented on the MCP server side. But more recently, many MCP clients, especially many popular coding agents, are implementing this pattern on the client side.
The pattern is now called progressive tool discovery, and it's a recommended best practice for MCP clients. In addition, a lot of these agents like Codex or Claude Code are implementing what's called Programmatic Tool Calling, also known as Code Mode. And with Code Mode, instead of calling tools one at a time, the agent will go ahead and write a script that chains those tools together in a sandbox environment.
The script then runs in the sandbox and then only the final result is returned back to the model. So between progressive discovery handling tool call selection and then code mode handling tool composition, the clients are now starting to take more ownership of the problems that servers originally were trying to solve. So surely this means we can just go back to the original method of doing a one -to -one mapping of API endpoints to tool calls, right?
Not quite. While an agent certainly can accomplish everything it needs to just by having access to tools that represent every API endpoint, that isn't necessarily always the most efficient way to interact with an API. For any given API, there are often very common tasks or workflows that require stringing together multiple API calls.
And if an agent has to figure out that chain on its own every single time, that's a lot of wasted tokens. And this is the same reason that SDKs exist. They give you the raw endpoints, but also bundle common workflows into single operations.
And we can apply that same idea to the tools that we expose through our MCP server. So for example, with Neon, we have this idea of creating a branch, but it turns out that creating a branch is actually three separate API calls under the hood. You have to first create the branch itself, but then make a separate call to attach compute resources.
sources to the branch and make a third call to get the connection string. In the SDK, we bundle those three API calls into one method called createWithCompute. So as this relates to our MCP server, in order to give MCP clients the most token efficient path possible, it's helpful to expose operations like this that they can take advantage of in some of these common use cases.
Of course, if your API is relatively simple and straightforward, a one -to -one mapping might be totally fine. But for something like Neon, where there's some complexity in provisioning infrastructure, these ergonomic shortcuts save the agent from making the same mistakes over and over again. So at Neon, we have an SDK, which is generated from our open API spec.
So that way it covers every API endpoint, but On top of that generated layer, we also have another thinner layer that adds the ergonomic methods that we were just talking about. Things like create with compute.
From here, in order for this to be usable by agents, we need to convert all of these methods into tool calls. So that's exactly what we did with a package that we call Neon Tools. So that includes both the raw endpoints and the ergonomic workflows, all as tool calls.
And by virtue of pulling these tools out into a separate package, we're able to serve a few different use cases. First and foremost, in the Neon MCP server, the server imports this package to surface all of these tools to any MCP client.
But on top of that, we can also take this package and build adapters around it for different agent frameworks. So for example, we have adapters for both Mastra and Eve for anyone building custom agents with those frameworks. And one more thing worth noting is that these tools are organized into categories.
So that way you can scope down exactly which tools you want the agent to have access to. All in all, the big idea here is that the server is controlling what tools are available, but then the client handles discovering and executing those tools in whatever way it sees fit.
All of this is open source, so if you want to dive through the code and see exactly how everything is implemented, I'll have some links down in the description for you to check out. And if you have ways that you're approaching building your own MCP server, let us know down in the comments. Thank you so much for watching, and I'll see you in the next one.
The Hook
The bait, then the rug-pull.
MCP tool design just flipped: the search-inspect-execute pattern that used to live inside servers is moving into the clients themselves, and that changes what a well-built MCP server should expose.
Named ideas worth stealing.
01:10list
Layered Tool Call Pattern
- Search available endpoints
- Inspect a specific endpoint's definition
- Execute the request
Instead of one tool per endpoint, expose two or three general-purpose tools that search, inspect, and execute against the full API surface.
Steal forAny MCP server with a large or fast-growing API surface
04:24model
SDK Two-Layer Architecture (raw + ergonomic)
- Raw endpoints layer, generated from the OpenAPI spec
- Ergonomic layer, bundling common multi-call workflows
Auto-generate full endpoint coverage from the API spec, then hand-add a thin layer of bundled methods for the workflows developers actually use.
Steal forAny MCP server wrapping an API with multi-step provisioning or setup flows
03:16concept
createWithCompute bundling example
Neon's three-call branch-creation flow (create branch, attach compute, get connection string) collapsed into one ergonomic SDK/tool call.
Steal forAny workflow that always requires the same fixed sequence of API calls
How they asked for the click.
VERBAL ASK
05:37link
“All of this is open source, so if you want to dive through the code and see exactly how everything is implemented, I'll have some links down in the description for you to check out.”
Soft CTA pointing to open-source repo links in the description, paired with a prompt for viewers to share their own MCP server approach in the comments — no product pitch, no subscribe ask.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
OTHER LINKSAlso linked in the description.
Visual structure at a glance.
