Hacker News new | ask | show | jobs
Show HN: MCP Isn't Dead. You're Just Using It Wrong
6 points by isaacrolandson 93 days ago
Everyone and their gran have been saying that MCP is dead.

But could it be that MCP's saving grace has been with us all along - hiding in plain sight?

A feature buried in Claude Code's Jan 2026 release may have marked the most powerful development in MCP since its inception - and almost nobody noticed. Dynamic Tool Registration.

Dynamic tool registration extends an MCP server's abilities beyond that of just a glorified swagger doc - allowing the server not just to list a static set of tools, but to dynamically add and remove new tools in real time as part of a stateful agent session.

And what's so powerful about that? Well for one it elegantly solves the main problem most people had with MCP in the first place - context bloat. Group your tools into collections of related actions - call them abilities - then provide a load_ability tool. The agent loads what it needs, when it needs it.

But it gets deeper than that.

Last weekend I built and shipped Commandable MCP - the MCP server for creating new MCP servers on the fly. MCP inception, if you will.

It gives agents tools to create new tools, usable immediately without compiling any code or restarting any processes.

Why would I want this?

Think about a standard Trello MCP server. It gives an agent something like create_trello_card(boardId, listId, name, description, labelIds, ...). Every time the agent wants to use it, it has to go fishing for IDs - calling get_boards, get_lists, get_labels - just to find the right place to add the card.

Imagine instead, the agent inspects your actual Trello account and generates add_bug_to_sprint(title, priority) - a tool that already knows your board, your list, your labels. Now it can use that tool whenever it needs to add a bug without reinventing the wheel.

Commandable lets agents build targeted tools for repeatable actions they actually use instead of long lists of generic tools from a standardised MCP or API. Credentials are encrypted at rest and never exposed to the LLM.

And - there's no context bloat. yay.

So, is MCP dead? Not yet.

GitHub: https://github.com/commandable/commandable-mcp

Full writeup: https://commandable.ai/blog/mcp-isnt-dead

6 comments

Dynamic tool registration matters more than it sounds. I've hit the context limit multiple times just from MCP servers loading 50+ tools at startup, most of which the agent never touches.

The Trello example is fine but I keep coming back to the security piece. If agents can spin up tools with credentials baked in, what's stopping a tool from dumping those credentials through its output? "Encrypted at rest" handles storage, sure. But at runtime those credentials are sitting in memory and passing through the response chain. Nobody seems to talk about that part.

Other thing — do dynamically created tools survive a restart? Or am I recreating them every session?

The lazy-loading abilities pattern makes a lot of sense for context bloat. But I'm curious about the practical middle ground? have you found that agents reliably know when to call load_ability vs trying to work with what they already have? In my experience the hardest part of tool use isn't having tools available, it's getting the model to pick the right one at the right time. What's been your experience?
Ah, I could very much see this being used widely, especially where the enterprise-provided MCPs dont-quite-do what's needed - which is very common across APIs (where the permissions are fine but the APIs just aren't built in a particular way)!

And - similar question on this thread, do they persist? Can they be shared? (E.g. hey team clone my MCP-addon to use this like I do)

Excellent work mate!! very excited to test this out!
MCP is a masterclass in how to not design an API.
well its more of a protocol than an API isnt it? And it kind of works - especially if you use it properly!
this is amazing! I saw the Google maps demo on the repo and cant wait to try it out it my workflow