Two full time projects at the same time:

1. Helping to make ActivityPods apps working on top of https://nextgraph.org/ (instead of SOLID).

2. https://cloudywithachanceoflatency.net, network monitoring done right (according to me), for humans and AI SREs (still WIP but quite fun already).

And when I get a chance, accepting some small paying contracts to pay bills. Weird times.

Ultimately, I find it likely that TLS will become a tool to prevent users from accessing foreign content (browsers stubbornly refusing to show untrusted sites in the name of security, slowly getting there), more than a tool to prevent eavesdropping on users secrets.

Just to let you know you are not alone, stranger; but also to advise you to be careful when touching on group identities.

An agent can easily use a text cli tool, not an interactive TUI.

One hour ago, while looking casually at a package.json, I saw this and was horrified:

  rm -rf pkg/snippets & rmdir pkg\\snippets /s /q & wasm-pack build --target bundler && node prepare-web.js

Looked like a strange mix of unix shell and msdos batch that would, on my box, try to rmdir "/s" and "/q". I asked Claude about this, and he replied something like "Yes that's a standard and clever hack to delete a directory that works both on linux and windows!".

Poor Claude has been trained on so much awful human code that it required several prompts for it to admit that there was indeed a problem.

The industry is the process by which convenient crap like this gets standardized.

To meekly defend the indefensible here: it's not like rmdir on Linux (I won't speak for all Unixen) can cause loss of data, since it only removes empty directories.

In this case, the rm -rf before that does. The rmdir is the Windows command in this example and with /s /q, it will quietly delete everything.

Yep, but that could still cause issues (those entries could be used as signals, or be mount points for currently unmounted partitions, etc). rmdir anything that start with "/" should be an absolute no-go.

To say nothing about running a sequence of shell commands without the -e option.

Yikes. I would never approve a PR with that in it.

Your agent might!

> Poor Claude has been trained on so much awful human code that it required several prompts for it to admit that there was indeed a problem.

Claude probably birthed this abomination in the first place

I hope the "standard" part is as much of a hallucination as "clever" is

My personnal solution to this is CTRL+W.

  > Problem 1: It Devours the Context Window

Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something? At least with MCP your harness could add in the context only the title of each tool and add full documentation on demand, MCP server by MCP server and tool by tool. The equivalent would be for all CLI to feature a "--short-descr" command.

  > Problem 2: Low Operational Reliability

If the tool is also using a REST API I see no reason why MCP should be slower, given the protocols are so close. When that happen, it's probably because MCP was added on top of an API, maybe hosted in a far away datacenter by a subcontractor? I won't argue that most MCP servers are probably awful, but that's an argument against the industry not the protocol.

  > Problem 3: Overlaps with Existing CLI/API

Yes, when a CLI tool already exist. A SQL MCP server sounds stupid to me, and a waste of token. Why not a curl MCP? But in the vast majority of shops, a cli tool does not exist. At best they have an API, which is designed to be used by programs not LLMs (you know what I mean).

  > Provide CLI -> API -> docs, in that order

Sure, and instead of slow and wasteful websites companies should first provide a native client for desktop, then a native client for phone.

> Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something?

I'm not super deep into all of this, but I think except latest Claude Code release the mcp is frontloaded into the context. So if you don't need it that often you have to disable and enabled it again when needed.

And I guess you can put some usage examples into the skill file. Which might migate the first --help.

Also I guess with cli it's easy to spin up a sub agent with their own context that just returns the result?

Yes I believe it is preloaded (from a recent test with latest claude-code actually). But that's an issue with the harness not something that's mandated by the MCP protocol.

I like MCP, but most servers and harnesses just dump all of the tools into context each message. Also the default tutorials for everything around MCP say to dump tools this way.

It’s really hard to determine which tools an agent will need on the fly. The best idea I’ve seen was to do a “search tools” tool which an agent would use to find relevant tools, then have an “execute tool” tool which did what it says.

Alternatively, if you’re using an agent that’s good with code, give it something like “port of context” (pctx) which translates MCP tools into a JavaScript package so the agent can chain MCP tools together with code, and they can filter the data down to just what they need. I haven’t used this method much yet but soon I need to improve the MCP gateway in our cloud agent builder product so I’m going to try this one out soon myself.

Agreed 100%. It's sad when the harness floods the context with a whole MCP response and then see the model dumping everything to disk to process it with a script. That's something the harness should do whenever the result is large: dump the json into a file and just say to the model: "your data is in /tmp/foo.json, it's very large so be careful with it", but I don't remember having ever seen that; maybe some harnesses do it? Depending on what the model is after it might want to filter for this or that, no need to load everything in the context.

That’s a good idea too, I might steal it.

Soon, if you want the performance of your AI clients to improve (wrt. token count and understanding) you will start to customize the output of the MCP server for more synthetic data, different data types, more permissive inputs, etc. And since most your clients will be AI that might be your API that fall behind, and MCP that will be maintained.

That's at least my experience with my current project: the traditional json, coding oriented API feels out of place, I maintain it out of habit. The real API is the MCP server, which is not designed like a traditional API would; understandability of the output for an LLM prevails instead of searchng for exhaustiveness, orthogonality etc.

Interesting points. A couple of questions. Do you have a frontend (React, Vue, anything) and if you do, does it interact with the server using the MCP server or the JSON API? Are all your clients AIs or do you expect that most of them will be AIs?

The reason I'm asking those questions is that a customer of mine has a service with a JSON API, a Vue frontend and a score of customers using that JSON API. We know that the newest ones are using bots to code their clients (and they are using them wrong, by the mistakes they do.) I don't see a near future in which all those third party apps become LLMs that would benefit from a MCP server and we retire the API.

I do have a front-end, but it interacts with the server with a specific, private API. It's using a more compact data encoding than JSON optimised for streaming the data that's needed for the front-end.

But yes I agree with your point: for a simpler app with a more traditional web UI it's likely the API used by the front-end would largely overlap with the user-oriented API. Then indeed the REST API has to be maintained for as long as humans continue to use the front-end.

/newest not so much, but I'm trying to visit /shownew (with showdeads) every now and then. I believe that's really why HN is for, and voting there a service duty.

Sounds simple. Would you also have a story to explain why Europe never managed to develop an independent IT industry either?

the 8bit era had a few 'european' computers. but not scaled enough to survive the PC era, I guess.

arm is one offshoot of that era.

Erlang and Prolog (and Ada I guess) are also european-ish.

why? too many localisation to be able to scale?