Lately I found MCP to be much more than a coding tool. For example, I implemented it in my more complex macOS apps [0] like rcmd, Clop, Lunar, so they can be configured by natural language.
So even with a local Qwen and Pi you can now say things like:
Set up Clop to optimise any PNG that I drop in my website assets folder and convert to a webp with the same name near it
Get Crank to start Time Machine backups immediately when I connect my HDD and notify me when the backup is done.
I want to be able to hold rcmd and fuzzy search and focus cmux agent panes
BetterTouchTool has a great MCP which can create native SwiftUI views and bind them to hotkeys, trackpad gestures etc. It can leverage its immense macOS automation tools and private APIs to let agents do Computer Use.
You would need a much more capable coding model to code those tools from scratch and get the same fail-safe logic that the apps have honed over the years.
Like, since MCP, Crank [1] has fully replaced my use of crontab, launchd, scattered scripts I run once a week. Not that it could not do that before, but it's so much simpler now to just describe the automation and have it happen reliably and visible in the UI. The friction is gone.
I just wanted to say thank you for making the tools that you have either free, or very reasonably priced. ZoomHider, MusicDecoy, YellowDot, and IsThereNet are some of the first things I install on my/my family's Macs (often before even Homebrew).
They're so powerful and yet get out of your way when you're not using them. I couldn't imagine being without them. Thanks y'all!
I guess the best way I would put it is that MCP is an RPC for any software in a way that an LLM could interface with easier. Since MCP etc can work with things like Blender.
This isn't restricted to agents. It's generally annoying when any service I may want to use programmatically is exposed through a CLI but not an API. Sure, I can call a CLI from most programming languages, but I/O beyond arguments and return values is at best awkward, and especially on non-UNIX OSes performance can suffer due to process creation overhead for every command.
Recent example: The AWS CLI has a convenient "s3 sync" command that does a one-way directory sync, only downloadiong new files if existing files with matching sizes and timestamps don't exist, but the closest thing the .NET SDK has unconditionally overwrites destination files.
Another example: one of the nicest things about C# is how the compiler exposes itself as extensive library functionality, so, not only can I compile and run code at runtime, I can generate this code from programmatically created ASTs instead of text, parse expressions into ASTs, etc.
Yes - Or a working directory that’s under version control where they can write arbitrary memory files and maintain working state across contexts.
These are things devs often take for granted as being part of ‘how chat agents operate’ but they are specific to how claude code/opencode/pi/codex operate.
Giving agents a Unix computer account they can play with is definitely a powerful tool that makes them capable of doing a lot more (see: meta muse, OpenAI dots), in much the same way that giving a human a computer they are trained to use makes them way more capable… but it’s surely not the only way we can run these things.
Hi! I've dabbled in implementing an MCP server/client back in March. To me a proper REST API and/or cli tool seems sufficient enough, agents use them with good efficiency.
Any reason not to provide CLI or REST interface for your tools, but MCP for agents specifically?
In my apps, CLI came first which works through Mach ports as the IPC, so the "REST equivalent" of macOS apps is also present. MCP takes advantage of the same client-server architecture I created for the CLI, so there's nothing you can't do with the CLI that needs an MCP.
But in my case, a CLI was not enough.
Like, to the MCP I might say:
Set Clop to make every video copied in ~/shots smaller, 2x and silent
Then the MCP can use elicitation and say:
By smaller, you mean re-encode to compress file size (factor can be 0 to 100 max compression) or downscale resolution (100% same size, 50% half size)?
And does 2x mean faster speed? In which case do you want to keep frames so the video plays smoother or drop frames for size? Or does 2x mean upscale?
And the agent will present those as nice choice menus I can decide schematically on.
With the CLI I have to first read, learn and memorize the requests and commands needed for each app, the accepted values and formats and the steps to reach a specific result.
There's only so much space in my head I can leave for implementation details of arbitrary apps. I'd rather have an agent care about that.
And yes I get the irony, those are my apps, I coded them by hand for years, I should know their implementation details, yet even I forget if I should pass 50% or 0.5 for half size.
Btw Clop is a media file compressor for context: <a href="https://lowtechguys.com/clop" rel="nofollow">https://lowtechguys.com/clop
You answered "Why use MCP with your agent instead of using CLI manually?" but the more interesting question is "Why build an MCP when you could already point your agent to the CLI?". The user experience of "the agent will present those as nice choice menus I can decide schematically on" will probably be the same since agents are very adept at using cli tools and gathering required/optional arguments, examples, and warnings/errors to present you with useful choices on how to proceed.
The most important reason is that I can keep the CLI output and help for humans, while the MCP can be crammed with information for agents.
Plus I can add some complex commands like in the rcmd Stages [1] case where the agent can create a 4 monitor layout with apps and windows placed where you want, with every window opening the document/folder/project/URL you want and running the terminal commands you need. Sure you can do that with the CLI, but it's hard enough to get right because of shell quoting issues, that even an agent can get it wrong.
For simple tasks though, sure, the CLI is just enough and the agent can use it without needing to install yet another MCP. You'll know when you need it.
EDIT: I just remembered, you can even hook the Claude/Codex/Gemini desktop app to the MCP, while you can't get it to use the CLI. so there's that for users that still don't feel comfortable at a terminal, which is a number higher than you might estimate.
Where I found MCP's really useful is integrating with "consumer AI" (chatgpt.com, claude.ai, etc).
I'm working on a sideproject called Rowbly[1]. It acts as a sharable data store where LLM's can dump research rather than keeping it in their memory or throwing it into a spreadsheet.
At first I thought "I don't need an MCP, I'll just expose a CLI" but that carries a pretty big limitation in that it only works with agents on your computer (Codex, Claude Code, Pi, etc). For the folks on here this is not an issue and is often times preferable but I'm also targeting the average LLM user that primarily interfaces with it via "consumer AI" and with those tools the stuff you can do is very very limited.
I still think MCP's have a long way to go maturity wise and hey maybe in a few years we will figure out a better way to do things but for now, if you want to interact with consumer AI apps, there's just no way around using them.
I use rcmd daily (and have just taken the time to dial in the configuration, it works even better now!) and I have to say that it's wonderful. It makes using the computer so much faster and easier: with window scripts too, it's like magic.
There were some teething problems on Golden Gate: keystrokes didn't seem to make it to the rcmd popup, but your recent remediations seem to have solved it. It's a beta OS version too, of course :-)
Thank you! Yes, macOS 27 continues to be a pain with the all new rewritten window manager.
Still working on finding all the edge cases, so sorry if you still encounter problems there. I've been using it since June and still find problems in input handling.
Like there's this thing, where if an app has Accessibility Permissions and listens to key events (like rcmd does) and then you revoke that permission while the app is running, then your whole system will stop responding to keys and clicks. Until you kill the app in question, but how are you going to do that without a keyboard?
All apps have this problem, even established ones like BTT, because it's a recently introduced macOS behavior in how the internals of CGEventTap work.
Yeah, I thought so -- I imagine quite a lot has changed behind the scenes. It does seem much better than Tahoe, though.
Yikes, that accessibility bug is bad LOL. It seems a bit like Linux in that way: certain bugs hang around for years. I always found that with Linux, you could either use an LTS and stick with the same bugs for years, or try your luck with a rolling release and trade them for new ones. Anyway...
I've just started leaning more heavily on the window switcher (moved it to Lcmd) and it's made me so much faster. Had rcmd for ages but never changed it to that; it solves the problem of "where the hell did I put that window?!" when I try to organize stuff into different spaces. It's a better candidate for Lcmd too IMO: I very rarely wonder where I put a random window of an app (and after all, if it's already open I usually want to choose a window), but I'm always switching between certain windows of one app, like Safari. Swiping back and forth between desktops was a nightmare!
I find it exciting that the dust is finally settling.
We're back onto the original use cases for natural language processing. This is where all the value always was, and now the market has proven to itself what anyone with even a bachelor's in computer science already knew.
Nothing in there is innovative or unattainable, Clop uses open source tools behind the scenes anyway so obviously you can replicate it with scripts.
But this is for people that already use the app, researchers, writers, students, people that aren't necessarily comfortable with a terminal. And given Clop already implements the basics: an efficient file events watcher, tuned encoders for the Mac silicon, fail safe backups and UI for seeing the result and interacting with it in real time, it has advantages over trying to do it yourself.
I'm not intending to denigrate your tool. I'm just commenting on the "look at how we go full circle" aspect.
I will point out that the shell script way uses less resources than an LLM making a tool call. But I understand that these scenarios are not necessarily meant for the same user.
Oh for sure, I would prefer to have the automations as invisible things running at the system level, doing exactly what I want and nothing else, not wasting resources on UIs and event watchers I might not need. I would get rid of my own apps if that was easy to do.
But it seems we need to waste some resources to get some usability in return.
I had no idea this was a thing: <a href="https://developer.apple.com/library/archive/documentation/AppleScript/Conceptual/AppleScriptLangGuide/reference/ASLR_folder_actions.html" rel="nofollow">https://developer.apple.com/library/archive/documentation/Ap...
Definitely saving it for further use, I sometimes need to have small invisible watchers and I don't want a full fledged app or shell scripts for that.
I gave claude an API key for Home Assistant. I can tell it to create dashboards, set up automations, diagnose problems etc, all using natural language. No MCP needed.
Yesterday I received a new thermometer for my aquarium to replace an old broken one. Both were bluetooth, but different models. I just told claude "I'm going to set up up my new bluetooth thermometer for my fish tank in a few minutes, keep an eye out for it and replace the old broken one with it in Home Assistant" and then walked away and put a battery in it and put it in my aquarium.
When I came back it had found it, replaced all my existing entities for the broken one with the new one, and verified it was all working with my existing graphs and automations.
Thanks. It sounded like something more since you asked it to look in a few minutes time. I’m not familiar with the cli tool (I just use vscode) but I assumed it was openclaw you were using or something.
That's smart! That reminds me, I have to get back into HomeAssistant. I had my whole house through it a few years ago, but the complexity and things breaking in hard to debug ways made the experience too frustrating for my wife and visiting relatives.
Having an agent keep an eye on stuff and fix things proactively should make the experience much better. Plus I can no longer write yamls at last.
Developing for HA with Claude has been great. Not only can it make all of those yaml changes based on natural language goals, but it's so easy now to create a custom dashboard or configure various apps. I was struggling with both the ChoreOps docs and its fairly cumbersome interface until I pointed Claude at it and told it what I was trying to do.
I +1 this approach. We are doing similarly. Instead of providing MCP, we are simply providing API key and documentation. Folks are able to then just paste that link and use our service.
User will interact or build apps with simply text like: "Give me all the issues that are X, context: <a href="https://somedomain.com/llm.txt" rel="nofollow">https://somedomain.com/llm.txt"
MCP is a tool more for security than anything else. If you give your agents access to an API key, there's a chance they can accidentally or maliciously leak that key. If the MCP server has access to the keys instead, it takes that possibility away. That's not always something you need to care about, but it is very important for some people's threat model.
The agent doesn't, the harness does. It's separate from a normal conversation / agent runtime environment. How do you suspect auth keys can leak from an MCP that's been added to chatgpt.com?
With a different key, obviously. This lets you keep the MCP server firewalled to your local network only while still allowing home assistant itself to access the internet
My own approach is to put the API key in the MCP server, apply principle of least privilege there, and firewall access to MCP with agents being on same private network with Tailscale.
Not only giving an API key to an agent can leak to the model because of harness issues or too broad reading rights, but also most providers don't give the ability to apply principle of least privilege to an API key.
I don't want to give an agent full R/W access to any of my services/accounts.
> MCP is a tool more for security than anything else.
The agent can get to the resource through the MCP server or using API key. I personally do not see the benefit MCP is providing here. Sure you can reduce the exposed surface at MCP layer, but I do that at the API layer. I don't need to add another layer here.
I can kinda understand if you do not have control of the API layer and/or you have to expose the API layer to the public Internet as well. Most of the time that is not the case for me.
There are many ways to do this without using mcp, for example one of the many proxy servers that inject the token into requests. I use a custom solution that redacts all secrets to agent transcripts before the agent sees them in a hook.
I find it way better to be able to confidently tell agents to use CLIs than worrying about partially implemented mcps that need configuration and are often yolo’d with npx @latest anyway
> MCP is a tool more for security than anything else.
+1 to this; API keys mean:
a) Your agents are overprivileged by default
b) Your API key is more likely to get into logs and pre-training / leaked as FrinkleFrankie mentioned
c) You can't manage it centrally with granular tool policies in Enterprises. (e.g. "you're not allowed to read slack channel for #finances")
Also, you can always collapse MCP to CLI, so MCP as auth/security middleware makes a lot of sense.
PoC of MCP -> CLI:
<a href="https://github.com/edison-watch/cli" rel="nofollow">https://github.com/edison-watch/cli
One of the nice things about MCP is that the tools have descriptions that provide guidance to the LLM. You can provide documentation in other formats like OpenAPI but its nice that the documentation is so closely coupled with MCP servers.
> One of the nice things about MCP is that the tools have descriptions that provide guidance to the LLM.
It is more of a curse than a blessing. MCP pollutes agent context even when you are not using it. Use a manually invoked skill instead if you don't want to be wasting tokens on every turn and bloating up agent context making it dumber in the process.
One of the key points of the comment you replied to is that you don’t need a very powerful model to do MCP stuff, such as local Qwen. The “let the agent figure it out” approach works much better with powerful models, such as Claude (which you mentioned you are using).
It still takes decent hardware to run local LLMs that are at all useful. What would be really cool is if we could get useful LLMs on hardware cheap enough to go into “things”.
Verging away from the topic, but I've found Claude is a great addition to HA. I want smart home features, but don't have the time/inclination to learn HA's way of working. Historically I just defaulted to Google Home because it was easier, but with Claude I barely need to touch HA configuration at all.
Recently I wanted to set up a slightly complex routine involving some lights and a couple of motion sensors. It feels like magic to be able to describe the behavior I want, briefly discuss the implementation, and walk past the sensor and see it in action.
For Home Assistant, the MCP can enable the LLM to make changes without using up excessive tokens.
For example, the only way to make a change to an HA automation via the API is to POST a whole new copy of the YAML, even if changing one things. The skill and HA MCP I use allows the LLM to use tools which make more precise changes without excessive context usage.
Certainly still works either way though. And of course your LLM instance could just roll its own tools to do the exact same thing.
Not really. macOS may wait for idle time, may prioritize internal disk and the backup will go extremely slow on an HDD, there's no notification whatsoever.
It's a very specific thing for me really, I connect the HDD specifically for doing backups as fast as possible then I want to disconnect and store it back so I can keep using my laptop. I don't have a desk anymore where I can keep these things connected all the time.
I haven't even considered using MCP for locally-running apps! I mean I used to, but they almost always got associated with cloud service access and integrations nowadays, and most local stuff is trivially handled with agent skills.
Thanks for the tips. TIL about BTT having MCP support. Crank looks very promising too, since it looks like a more effective Shortcuts and Hazel replacement
alin23 · · focus · HN ↗
So even with a local Qwen and Pi you can now say things like:
BetterTouchTool has a great MCP which can create native SwiftUI views and bind them to hotkeys, trackpad gestures etc. It can leverage its immense macOS automation tools and private APIs to let agents do Computer Use.You would need a much more capable coding model to code those tools from scratch and get the same fail-safe logic that the apps have honed over the years.
Like, since MCP, Crank [1] has fully replaced my use of crontab, launchd, scattered scripts I run once a week. Not that it could not do that before, but it's so much simpler now to just describe the automation and have it happen reliably and visible in the UI. The friction is gone.
[0] <a href="https://reddit.com/r/macapps/comments/1wkv0dy/mcp_in_macos_apps_are_they_useful_for_you/" rel="nofollow">https://reddit.com/r/macapps/comments/1wkv0dy/mcp_in_macos_a...
[1] <a href="https://lowtechguys.com/crank" rel="nofollow">https://lowtechguys.com/crank
taylor-tg · · focus · HN ↗
They're so powerful and yet get out of your way when you're not using them. I couldn't imagine being without them. Thanks y'all!
alin23 · · focus · HN ↗
alsetmusic · · focus · HN ↗
rudcodex · · focus · HN ↗
giancarlostoro · · focus · HN ↗
alin23 · · focus · HN ↗
anthonypasq · · focus · HN ↗
Everyone on this forum has an absolute paucity of imagination when it comes to applying LLMs to any use case that doesnt involve coding.
vorticalbox · · focus · HN ↗
Of course MCP has its use case like if you want auth, or session based actions.
anthonypasq · · focus · HN ↗
NO IT CANT!!! why dont you understand that not all agents have access to a terminal!
jasomill · · focus · HN ↗
Recent example: The AWS CLI has a convenient "s3 sync" command that does a one-way directory sync, only downloadiong new files if existing files with matching sizes and timestamps don't exist, but the closest thing the .NET SDK has unconditionally overwrites destination files.
Another example: one of the nicest things about C# is how the compiler exposes itself as extensive library functionality, so, not only can I compile and run code at runtime, I can generate this code from programmatically created ASTs instead of text, parse expressions into ASTs, etc.
jameshart · · focus · HN ↗
These are things devs often take for granted as being part of ‘how chat agents operate’ but they are specific to how claude code/opencode/pi/codex operate.
Giving agents a Unix computer account they can play with is definitely a powerful tool that makes them capable of doing a lot more (see: meta muse, OpenAI dots), in much the same way that giving a human a computer they are trained to use makes them way more capable… but it’s surely not the only way we can run these things.
nimih · · focus · HN ↗
anthonypasq · · focus · HN ↗
pjmlp · · focus · HN ↗
They pay tons of money for hardware, only to use it the same way I was using those DG/UX terminals at the university.
Naturally there are no coders in other operating systems as well.
gojogs · · focus · HN ↗
anthonypasq · · focus · HN ↗
gojogs · · focus · HN ↗
brabel · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
gojogs · · focus · HN ↗
alin23 · · focus · HN ↗
But in my case, a CLI was not enough.
Like, to the MCP I might say:
Then the MCP can use elicitation and say: And the agent will present those as nice choice menus I can decide schematically on.With the CLI I have to first read, learn and memorize the requests and commands needed for each app, the accepted values and formats and the steps to reach a specific result.
There's only so much space in my head I can leave for implementation details of arbitrary apps. I'd rather have an agent care about that.
And yes I get the irony, those are my apps, I coded them by hand for years, I should know their implementation details, yet even I forget if I should pass 50% or 0.5 for half size.
Btw Clop is a media file compressor for context: <a href="https://lowtechguys.com/clop" rel="nofollow">https://lowtechguys.com/clop
DrammBA · · focus · HN ↗
alin23 · · focus · HN ↗
Plus I can add some complex commands like in the rcmd Stages [1] case where the agent can create a 4 monitor layout with apps and windows placed where you want, with every window opening the document/folder/project/URL you want and running the terminal commands you need. Sure you can do that with the CLI, but it's hard enough to get right because of shell quoting issues, that even an agent can get it wrong.
For simple tasks though, sure, the CLI is just enough and the agent can use it without needing to install yet another MCP. You'll know when you need it.
[1] <a href="https://lowtechguys.com/rcmd" rel="nofollow">https://lowtechguys.com/rcmd
---
EDIT: I just remembered, you can even hook the Claude/Codex/Gemini desktop app to the MCP, while you can't get it to use the CLI. so there's that for users that still don't feel comfortable at a terminal, which is a number higher than you might estimate.
_fat_santa · · focus · HN ↗
I'm working on a sideproject called Rowbly[1]. It acts as a sharable data store where LLM's can dump research rather than keeping it in their memory or throwing it into a spreadsheet.
At first I thought "I don't need an MCP, I'll just expose a CLI" but that carries a pretty big limitation in that it only works with agents on your computer (Codex, Claude Code, Pi, etc). For the folks on here this is not an issue and is often times preferable but I'm also targeting the average LLM user that primarily interfaces with it via "consumer AI" and with those tools the stuff you can do is very very limited.
I still think MCP's have a long way to go maturity wise and hey maybe in a few years we will figure out a better way to do things but for now, if you want to interact with consumer AI apps, there's just no way around using them.
[1]: <a href="https://rowbly.com" rel="nofollow">https://rowbly.com
tentacleuno · · focus · HN ↗
There were some teething problems on Golden Gate: keystrokes didn't seem to make it to the rcmd popup, but your recent remediations seem to have solved it. It's a beta OS version too, of course :-)
alin23 · · focus · HN ↗
Still working on finding all the edge cases, so sorry if you still encounter problems there. I've been using it since June and still find problems in input handling.
Like there's this thing, where if an app has Accessibility Permissions and listens to key events (like rcmd does) and then you revoke that permission while the app is running, then your whole system will stop responding to keys and clicks. Until you kill the app in question, but how are you going to do that without a keyboard?
All apps have this problem, even established ones like BTT, because it's a recently introduced macOS behavior in how the internals of CGEventTap work.
selicos · · focus · HN ↗
tentacleuno · · focus · HN ↗
Yikes, that accessibility bug is bad LOL. It seems a bit like Linux in that way: certain bugs hang around for years. I always found that with Linux, you could either use an LTS and stick with the same bugs for years, or try your luck with a rolling release and trade them for new ones. Anyway...
I've just started leaning more heavily on the window switcher (moved it to Lcmd) and it's made me so much faster. Had rcmd for ages but never changed it to that; it solves the problem of "where the hell did I put that window?!" when I try to organize stuff into different spaces. It's a better candidate for Lcmd too IMO: I very rarely wonder where I put a random window of an app (and after all, if it's already open I usually want to choose a window), but I'm always switching between certain windows of one app, like Safari. Swiping back and forth between desktops was a nightmare!
selicos · · focus · HN ↗
Why is AI involved for any other reason than building the original test implementation?
alin23 · · focus · HN ↗
Not sure if you got the right context, your question doesn't really make sense to me.
sublinear · · focus · HN ↗
We're back onto the original use cases for natural language processing. This is where all the value always was, and now the market has proven to itself what anyone with even a bachelor's in computer science already knew.
asveikau · · focus · HN ↗
This seems like exactly the sort of thing I've done with shell scripts or even makefiles.
alin23 · · focus · HN ↗
But this is for people that already use the app, researchers, writers, students, people that aren't necessarily comfortable with a terminal. And given Clop already implements the basics: an efficient file events watcher, tuned encoders for the Mac silicon, fail safe backups and UI for seeing the result and interacting with it in real time, it has advantages over trying to do it yourself.
asveikau · · focus · HN ↗
I will point out that the shell script way uses less resources than an LLM making a tool call. But I understand that these scenarios are not necessarily meant for the same user.
alin23 · · focus · HN ↗
Oh for sure, I would prefer to have the automations as invisible things running at the system level, doing exactly what I want and nothing else, not wasting resources on UIs and event watchers I might not need. I would get rid of my own apps if that was easy to do.
But it seems we need to waste some resources to get some usability in return.
weego · · focus · HN ↗
kccqzy · · focus · HN ↗
alin23 · · focus · HN ↗
Definitely saving it for further use, I sometimes need to have small invisible watchers and I don't want a full fledged app or shell scripts for that.
kccqzy · · focus · HN ↗
mike-cardwell · · focus · HN ↗
Yesterday I received a new thermometer for my aquarium to replace an old broken one. Both were bluetooth, but different models. I just told claude "I'm going to set up up my new bluetooth thermometer for my fish tank in a few minutes, keep an eye out for it and replace the old broken one with it in Home Assistant" and then walked away and put a battery in it and put it in my aquarium.
When I came back it had found it, replaced all my existing entities for the broken one with the new one, and verified it was all working with my existing graphs and automations.
thebruce87m · · focus · HN ↗
SV_BubbleTime · · focus · HN ↗
mike-cardwell · · focus · HN ↗
thebruce87m · · focus · HN ↗
alin23 · · focus · HN ↗
Having an agent keep an eye on stuff and fix things proactively should make the experience much better. Plus I can no longer write yamls at last.
mithr · · focus · HN ↗
30minAdayHN · · focus · HN ↗
User will interact or build apps with simply text like: "Give me all the issues that are X, context: <a href="https://somedomain.com/llm.txt" rel="nofollow">https://somedomain.com/llm.txt"
llm.txt will have all the API instructions
FrinkleFrankle · · focus · HN ↗
Toutouxc · · focus · HN ↗
SV_BubbleTime · · focus · HN ↗
c-hendricks · · focus · HN ↗
dandelany · · focus · HN ↗
wiether · · focus · HN ↗
Not only giving an API key to an agent can leak to the model because of harness issues or too broad reading rights, but also most providers don't give the ability to apply principle of least privilege to an API key.
I don't want to give an agent full R/W access to any of my services/accounts.
cheema33 · · focus · HN ↗
The agent can get to the resource through the MCP server or using API key. I personally do not see the benefit MCP is providing here. Sure you can reduce the exposed surface at MCP layer, but I do that at the API layer. I don't need to add another layer here.
I can kinda understand if you do not have control of the API layer and/or you have to expose the API layer to the public Internet as well. Most of the time that is not the case for me.
anamexis · · focus · HN ↗
spellboots · · focus · HN ↗
I find it way better to be able to confidently tell agents to use CLIs than worrying about partially implemented mcps that need configuration and are often yolo’d with npx @latest anyway
Miyamura80 · · focus · HN ↗
Also, you can always collapse MCP to CLI, so MCP as auth/security middleware makes a lot of sense.
PoC of MCP -> CLI: <a href="https://github.com/edison-watch/cli" rel="nofollow">https://github.com/edison-watch/cli
c-hendricks · · focus · HN ↗
Definitely helps that the home assistant api is documented online most likely in the training data.
matt_heimer · · focus · HN ↗
cheema33 · · focus · HN ↗
It is more of a curse than a blessing. MCP pollutes agent context even when you are not using it. Use a manually invoked skill instead if you don't want to be wasting tokens on every turn and bloating up agent context making it dumber in the process.
c-hendricks · · focus · HN ↗
MCP in some harnesses bloats context. MCP in some harnesses doesn't bloat context.
Vegenoid · · focus · HN ↗
mike-cardwell · · focus · HN ↗
Vegenoid · · focus · HN ↗
ash_091 · · focus · HN ↗
Recently I wanted to set up a slightly complex routine involving some lights and a couple of motion sensors. It feels like magic to be able to describe the behavior I want, briefly discuss the implementation, and walk past the sensor and see it in action.
varenc · · focus · HN ↗
For example, the only way to make a change to an HA automation via the API is to POST a whole new copy of the YAML, even if changing one things. The skill and HA MCP I use allows the LLM to use tools which make more precise changes without excessive context usage.
Certainly still works either way though. And of course your LLM instance could just roll its own tools to do the exact same thing.
astrange · · focus · HN ↗
Is that not how it works out of the box?
alin23 · · focus · HN ↗
It's a very specific thing for me really, I connect the HDD specifically for doing backups as fast as possible then I want to disconnect and store it back so I can keep using my laptop. I don't have a desk anymore where I can keep these things connected all the time.
lmz · · focus · HN ↗
jerieljan · · focus · HN ↗
Thanks for the tips. TIL about BTT having MCP support. Crank looks very promising too, since it looks like a more effective Shortcuts and Hazel replacement