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.
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.
> 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.
> 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
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.
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
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: https://somedomain.com/llm.txt"
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.
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.
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.
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.
Not for me. I don’t even remember when (or since how many years ago) I turned off Protect My Email and turned on both Hide IP Address and Block All Remote Content. I still have these toggles as they are, despite the fact that I use beta releases as and when they’re released (currently still on iOS 26.x).
I also just tried this as well, sending an email from a Migadu-based account to one at both Gmail and MXRoute using Mail.app under macOS 15.7.7. Neither included any private IP address info I could find in either headers or raw source. That would be a good leak to know about and as sibling comment said saagarjha definitely knows their stuff, so any tips to replicate would be appreciated.
Received: from smtpclient.apple (ptr. [ip])
by smtp.gmail.com with ESMTPSA id ...
for <...>
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Thu, 02 Jul 2026 ..:..:.. -0700 (PDT)
For me that IP belongs to apple, when using the iOS mail client. I presume Apple forces third party apps to use their API and then stuff like this happens. Guess that's also on google, not mitigating that issue, tho.
Have you tried a VPN? I wonder, if Apple manages to expose IP despite a VPN. They had issues with stuff like that before.
Same, I remember it being in the headers long ago but don't see it now. macOS Tahoe, Mail.app client, iCloud email sending to itself or to my Gmail, both set up in default ways, IPv6 disabled
> The reason why my IP address is visible is because Apple Mail sends emails with SMTP.
Unless you use a proxy, your IP address is visible to an SMTP server, just like it's visible to an HTTP server when you use a web browser. This is not specific to Apple Mail or to Gmail.
Yeah but I think Gmail seems to actually just keep that header rather than nuking it. To be fair I don't entirely know what I would do to fix it since (like the post) this seems like there aren't many good options here.
I clearly remember many years ago that this wasn’t the case with Gmail, when looking for the source IP address in a case involving harassment of a person. I could only get Gmail’s own IP address in the headers from the multiple emails I examined at that time.
Nevertheless, as js2 said in another comment, it’s your mail provider (in this case Gmail) deciding whether to include the sender’s IP address or not.
Fetching any email content is always worse than blocking it, because the typical threshold for spam is "is this inbox monitored". If that is true, then blast it with spam. And fetching anything ever proves that the inbox is monitored.
At least in Gmail, downloading content (e.g. images) is disabled by default for suspicious emails. There is no way for the sender to know if it’s monitored unless this is disabled by explicit user action.
This freaked me out the first time I used Mail. It rendered a PDF about buying bitcoin on PayPal (I don't have PayPal). Looked at the same email in Gmail and Thunderbird, it's just a PDF attachment, no message, and the sender was different. No wonder people are falling for those scams, Mail makes it easy for them.
Now if only I had a better client on my phone (never buying an iPhone again)
I am starting to think all these "privacy" features merely exist as excuse for getting people to hand off their mails to Apple. Clearly the all do not deliver on the intended functionality, but the proxy/relay routing happens to some extent anyway. How convenient. If you were a company promising its users all the privacy, but secretly not giving a fuck beyond collecting user traffic and meta data, wouldn't you expect the state of things to look exactly like that? I mean, how could you explain this any other way, considering the size of Apple and the relative ease of developing such features reliably? Apple is hardly breaking ground here.
I spend a lot of time telling Opus 4.8 to search for security bugs in the code it wrote, and it spends a lot of time finding them, and then fixing them. Fable wont let me fix the security issues that Opus 4.8 created.
Not the OP but my Fable says something to the effect of "I'm afraid I can't do that Dave" and very obviously (not secretly) downgrades to Opus. I work in life sciences.
https://gitlab.com/grepular/foxcage - Runs Firefox inside podman to isolate it from the host. Has some interesting features that I wanted and nothing else gave me.
Currently working on a tool for sanitising email. Will be blogging it up at https://www.grepular.com/blog/ when it's ready for others to use. Does things like applying policies to html/svg/calendar/vcard parts to whitelist or blacklist tags/attributes/css/url schemas, clean URLs, fetch remote content at delivery time and attaching to the email to prevent tracking, pgp and smime auto encryption/decryption and a million other features.
You defeated https://www.emailprivacytester.com straight off. Which is more than most new email services. You seem to be relying on CSP entirely for this, but it works.
You declare HSTS preload, but you are not in the preload list. You can not be added to the preload list at https://hstspreload.org/ because www.rootshell.is exists but has an invalid certificate.
Your MX TLS configuration supports various anon ciphers. These should be disabled.
Your DANE is broken. Try any of a number of freely available online validators.
I gave your service a test, seeing all buttons in gray, and could not figure out if the service was broken, if my browser was broken, or if my e-mail client (Betterbird) was doing something good. Then I remembered that I use LuLu[1] to deny it all network access besides reaching my private e-mail server. Not ideal, I've learned to live with the caveats, but I do suppose it really does get the job done of stopping in-mail tracking.
I wasn't able to sign up for [email protected], but I was able to get [email protected]. You should be careful about what standard email addresses you allow people to take. I recommend you take abuse@ back from me and you should really have a strong denylist. I just asked an LLM for a list of things you should be blocking and it came back with the following. The cert validation ones seem particularly important:
RFC 2142 mailbox names (the core list):
postmaster@ — required by RFC 5321; mail systems expect it to always work
abuse@ — for reporting spam/misuse
hostmaster@ — DNS issues
webmaster@ — website issues
noc@ — network operations
security@ — security/vulnerability reports
info@, marketing@, sales@, support@ — business functions
admin@, administrator@
ssladmin@, ssladministrator@, sysadmin@
These can be used to validate domain control and issue certificates, so handing them to a random user is a real security risk.
Common automated/system senders people impersonate or that cause confusion:
billing@, accounts@, payments@
help@, contact@, service@
legal@, privacy@, dmca@
register@, registration@, signup@
The service's own name (e.g. [brand]@, team@, staff@, official@)
[edit] Re the TLS issue. You should set up a CAA DNS record and also check on crt.sh later to see if anybody managed to get a cert for rootshell.is if you didn't lock down the validation addresses
Wouldn't the better guidance be to use different domain for official communication similar to sites where you can customize the subdomain? Attackers can always come up with something you didn't think to block.
Google doesn't let just anyone make a mail on the google.com domain for example.
I hate shoving LLMs everywhere, but honestly this is probably a good use case for tiny models like the 0.6B Qwen model to flag account names for human review.
Targetted automated spam, most likely written by an LLM you say. By any chance do you see the text "agentmail" anywhere in the headers/body of that email?
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.