A platform that doesn't let you simply install a desired package without being shown ads is kind of crazy but it's basically industry standard for everything that's not Linux.
He/She meant _searching_ for apps for a functionality in App Store is a sure way to get gobbledygooky apps. He/She probably searches them on $SEARCH_ENGINE and uses the AppStore just for the download.
Ah, so using a different advertisement platform instead of this one.
Let me put this another way: if you want to manually kick off app updates, you literally have to see ads. App Store > Today tab (the default view) has ads. Then you hit your profile button to escape the ad center and there is your app update interface.
This has been normalized by basically all commercial OS platforms, but imagine how insanely negatively received it would be if apt upgrade or brew upgrade displayed ads before your packages downloaded.
Apple even shows ads for stuff like Apple Music/TV+/Fitness/News+ free trials in the settings pane.
And people give Microsoft shit for having ads in their platform...at least they don't show you ads in Windows Update!
Now, you might say this is because of the influence of SteamOS, but I think you’d be hard pressed to argue that Ubuntu has been getting more popular overall.
Linux users have a choice while iOS and Android users essentially don’t.
Web search engines' advertising can be hidden with an ad blockier. The App Store? Not so much. Its search is completely unusable anyway, even when you give it the exact app name you want.
Apple's enshittification is real, and accelerating.
Is it? I don't think I've ever downloaded anything from Apple's app store. Hmm. What have I got? Chrome. Installed from website. GIMP. Installed from website. LibreOffice. Installed from website. VSCode. Installed from website. VLC. Installed from website. Zoom. Installed from website. Homebrew. Installed by using a command from a website. And then, a bunch of stuff installed from brew.
Other than all the scammy & microtransaction BS for the kids I’m always confused about this as well. I can count on one hand how many “new” apps I’ve installed in 2025 - one - the Bambu app for talking to the 3D printer.
I’ve got my banking apps, business apps, Strava, etc. the same now, for years. It would take a monumental effort from Apple for me to feel like “cruising” the App store, the idea is so patently ridiculous to me, I actually LOL’d thinking about it. Literally any other portable device is better to play games on - Switch, Steamdeck, 3DS, Atari Lynx, etc.
I have Apple Arcade as well (included with something else), I can’t even remember the last time I could be bothered to scroll that…
If Apple thinks more ads is a solution to some of their problems, things must be way worse than imagined over there.
MCP parameter serialization fails consistently on consecutive function calls in both Claude Code and Claude Desktop, making MCP tools effectively unusable for any workflow requiring multiple parameter-based calls. I feel like someone ripped out part of my brain and then asked me to debug with what’s left.
Thank you for this release. I believe your library is a key component to unlocking the potential of LLMs without the limitations/restricitions of existing clients.
Since you released version 0.26 alpha, I’ve been trying to create a plugin to interact with a some MCP server, but it’s a bit too challenging for me. So far, I’ve managed to connect and dynamically retrieve and use tools, but I’m not yet able to pass parameters.
Yeah I had a bit of an experiment with MCP this morning, to see if I could get a quick plugin demo out for it. It's a bit tricky! The official mcp Python library really wants you to run asyncio and connect to the server and introspect the available tools.
I'm a heavy user of the llm tool, so as soon as I saw your post, I started tinkering with MCP.
I’ve just published an alpha version that works with stdio-based MCP servers (tested with @modelcontextprotocol/server-filesystem) - https://github.com/Virtuslab/llm-tools-mcp. Very early stage, so please make sure to use with --ta option (Manually approve every tool execution).
The code is still messy and there are a couple of TODOs in the README.md, but I plan to work on it full-time until the end of the week.
Some questions:
Where do you think mcp.json should be stored? Also, it might be a bit inconvenient to specify tools one by one with -T. Do you think adding a --all-tools flag or supporting glob patterns like -T name-prefix* in llm would be a good idea?
1. A single class can have multiple tool methods in it, you just have to specify it once
2. Toolboxes can take configuration
With a Toolbox, your plugin could work like this:
llm -T 'MCP("path/to/mcp.json")' ...
You might even be able to design it such that you don't need a mcp.json at all, and everything gets passed to that constructor.
There's one catch: currently you would have to dynamically create the class with methods for each tool, which is possible in Python but a bit messy. I have an open issue to make that better here: https://github.com/simonw/llm/issues/1111