grepular

So MCP is useful until cheap models get better?

I just run claude's cli tool?

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.

I turned this on a few days ago. Looking good so far (UK)

The text is added to get around bayesian filters. The spammer doesn't want the text to be displayed to the end user though typically.

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.

I don't use X. You can tell him if you want.

That wouldn't be better guidance. That would be additional guidance. I'm sure Google also never let anybody set up [email protected]

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

TLS/certificate validation addresses (RFC 8552 / CA-Browser Forum):

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:

noreply@, no-reply@, donotreply@ mailer-daemon@ — bounce messages (RFC 5321 sender) root@, daemon@, bin@, sys@ — Unix-style system accounts null@, devnull@

Brand/trust-sensitive ones worth blocking too:

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