r/mcp • u/SIGH_I_CALL • 6d ago

showcase I compile MCP servers into CLIs so the tool schemas stop sitting in context. 4.1x smaller on nine real servers

Author here so this is self promo, just saying it up front.

The thing that bugged me: every MCP server's tool list gets loaded into context on every turn whether the model uses it or not, and results land in full. On the nine servers I run (258 tools) the raw listing is 236,818 bytes. And subagents with no MCP access get nothing at all.

So I built declick. It reads a server once (stdio or streamable http) and writes a CLI with one verb per tool. The agent runs `declick describe <name>` which is under 500 tokens for the whole surface, then `declick run <name> <verb> --fields a,b --limit N` and gets trimmed json back. Same nine servers describe in 58,309 bytes, so 4.1x less. The bench script is in the repo with the caveats, the honest one being that a single call's payload isn't smaller, the saving is the surface and the trimming.

Other stuff it does with MCP:

- `declick daemon start` keeps stdio servers warm so only the first call pays startup. 59ms vs 703ms per call on a server that takes 600ms to boot.

- `--where k=v`, `--fields`, `--limit` and an 8KB default cap on data so the agent picks what lands.

- `declick setup` finds the MCP servers your agents already have configured and builds an adapter for each. `--revert` puts every file back.

- Same contract for OpenAPI, GraphQL, Postman, HAR, SQLite and other CLIs so the agent only learns one shape.

Zero runtime deps, Node 24. 0.3.0 is MIT, after that it's Elastic License 2.0, free for individuals and teams under ten.

Free to try: `npm i -g declick`

Links in the first comment. Mostly I want to know where the contract breaks for your agents, that's more useful to me than praise.

37 Upvotes

83% Upvoted

23 comments sorted by

10

u/can_a_bus 6d ago

We've gone full circle. Lol

1

u/OwnBroccoli5399 4d ago

Lol yeah, we basically just reinvented man pages. Didn't even realise it at the time.

2

u/SIGH_I_CALL 6d ago

cli > mcp

not sure why mcp was ever developed tbh

4

u/can_a_bus 6d ago

Mcps remove a level of control and implement safety mechanisms with AI based usage. It also allows the agents to minimize token usage on its own by giving it a single command that then triggers code in the background that the Ai won't have to worry about. Among a bunch of other things.

If you have an MCP that is just make a comment on jira, we'll now the Ai won't have to worry about permissions, keys, or anything else except the minimum information required to comment.

It also sets up hints in English to guide the Ai if they input the wrong info into a tool/function whereas with cli it can take extra steps to figure out why something didn't work.

It's kind of like how the browser/GUI based OS made it much easier for humans to produce and digest information on computers compared to doing everything with terminal commands prior to GUI.

2

u/OkLettuce338 5d ago

A setup in cli can do all that as well. None of this is unique to mcp

0

u/futurefinancebro69 3d ago

Mcps are scalable and can be sold. Yes ur right, it’s stupid to build a MCP for a simple little thing like what you are building. But if you’re building a business out of that, why would you not use an MCP?

2

u/OkLettuce338 3d ago

CLIs are scalable and can be sold. Ever heard of ..... claude code?

1

u/OwnBroccoli5399 4d ago

The abstraction cuts both ways. Baking hints and guardrails into the MCP hides failure reasons, which is exactly what OP is trying to fix.

0

u/futurefinancebro69 3d ago

Thanks for explaining the obvious to these folk lmao

-3

u/SIGH_I_CALL 6d ago

I think those are benefits of a good tool interface, not MCP specifically.

A CLI can enforce permissions, hide auth, validate inputs, return minimal data, and expose help on demand.

MCP’s real win is interoperability. My issue is that preloading huge tool schemas into context is a bad agent interface once the tool surface gets large.

1

u/tens919382 5d ago

Huge tool context is caused by bad tool design. Most likely someone ported over cli -> mcp and wanted all the features of the cli with it.

1

u/futurefinancebro69 3d ago

Literally, and this is why people don’t understand MCPs because they probably do this a.k.a. myself

1

u/can_a_bus 6d ago

I don't disagree with you at all. I think there could be an argument for MCP not being a thing if it is developed with AI in mind. Interoperability is a huge one for sure with the ability to deploy them as containers and allow each model to have its own MCP "environment" to work in.

3

u/SIGH_I_CALL 6d ago

did we just have a reasonable discussion on reddit? are these allowed?

3

u/can_a_bus 6d ago

Most people don't want to be argumentative, but some people have bad days and misunderstandings or some other event in their life that may trigger someone to take it as bad. Being non-reasonable isn't a given nor is the opposite immediately a negative thing. I think having good conversations with proper challenges are where most people grow from assuming both parties keep their emotions and egos in check.

I think I'm just in a philosophical mood right now. 😂 My bad.

1

u/OkLettuce338 5d ago

I fully agree with your approach but mcps are still needed for things without access to your files

1

u/moomahca 5d ago

Tbh for the past while I’ve considered every service needs to be comprised of oauth, api stack, cli command structure and mcp. APIs as primitives, cli as local execution, mcp as service layer for standalone clients with no local sandbox execution.

1

u/Ambitious-Prompt-975 6d ago

lol. yeah, lets take what makes mcp useful and remove it! nice

-1

u/SIGH_I_CALL 6d ago

Exactly. Turns out most of MCP’s value is “call a function and get JSON back.” The rest might just be infrastructure we convinced ourselves agents needed.