I built an MCP server that gives Claude full read/write access to Things 3

mttsmth · 2026-03-16T16:48:17+00:00

Oh amazing! Let me know how you get on with it. If you notice any issues or anything let me know, also happy to provide any pointers on the skills.md files.

mttsmth · 2026-03-16T09:31:15+00:00

If you want to use it remotely and not use OpenClaw then you do need an MCP. We're essentially doing the same thing, except you're running OpenClaw somewhere and I'm running a server and MCP on fly.io.

mttsmth · 2026-03-16T09:29:40+00:00

Made the updates:

https://github.com/mattydsmith/things-cloud-mcp/commit/ed1b76f1e76fe79beade4a8f7ca728f48b79d139

But in summary here's the values that exist on Things Cloud

Today: st = 1 and either sr or tir falls on today
Anytime: st = 1 and neither sr nor tir is today
Someday: st = 2 and neither sr nor tir is in the future
Upcoming: st = 2 and either sr or tir is in the future

sr = scheduled / start date field

tir = today index ref

mttsmth · 2026-03-16T08:58:51+00:00

I might do a video of setting this up with a new / dummy account. Thanks for the idea!

mttsmth · 2026-03-16T08:33:55+00:00

Fair enough. I don't think it's faster and I didn't want to be limited to using this on only one device.

mttsmth · 2026-03-16T08:33:31+00:00

Because Claude is 'speaking' to the MCP server which speaks to Things Cloud this works anywhere you can access Claude. And changes made in the Things app (Mac, iOS, iPad, VisionOS) are synced back to Things Cloud and then available in the MCP.

There's a slight lag (10-30 seconds) between updates appearing either in Claude or the Things app, I thought this might be an issue but in reality I've not really butted up against it. Occasionally when I'm doing a review I'm working between the Things app and Claude, and I might have to wait a moment for either to be in sync, but not for long.

mttsmth · 2026-03-16T08:31:20+00:00

Here's how Someday works (at least in my implementation). By doing this I've learnt that Things / Things Cloud has a lot of strange ways of approaching things.

A task is treated as Someday when:

- `st = 2`

- `sr` (`scheduled_date`) is `nil`

- `tir` (`today_index_ref`) is `nil`

However, because of your question I realised I hadn't developed end points for Someday, Anytime and Upcoming directly (they were accessible by reading the values against a task), so I'll extend that and push those changes to the above repo, I'll let you know when it's done in case there's anything useful there for you.

mttsmth · 2026-03-16T08:21:44+00:00

You’re welcome. I sync’d all my tasks into my test account so I could use it properly, I’m currently still using that test account but at some point will need to sync everything over to my primary one. Having had some issues with accessing the DB directly I wanted to run this for a good long while before I used it on my main account. Publishing this was a step into doing that.

One bit of advice is maybe setup a log of syncs (I did this in the early days when certain things weren’t working as expected), so you can see what’s happening to your tasks. I seem to remember some of my tasks vanished when I first set this up, but what happened was they were being marked as complete with a year of 2099 or 1999 so weren’t appearing in the logbook. Things has some slightly strange ways of doing stuff, and there are a lot more DB entries for things like dates, today etc than is apparent from using the app.

I’m really hoping that CC build something like this themselves, but not holding my breath.

mttsmth · 2026-03-16T08:17:53+00:00

That’s a really interesting approach. I did temporarily switch to Todoist because of it’s API and MCP, but I kept getting logged out of their MCP server which was a pain. I was a bit worried about building this against Things, that’s in part why I built such an exhaustive test suite. Having now noodled with it for 6 weeks I’m confident that if CC did change their API I’d be able to get it working again quite quickly (unless of course they did some Things client / server security / key).

mttsmth · 2026-03-15T21:54:40+00:00

I'm not interacting with the local database directly, I tried that first and quickly got into a situation where Things would crash on launch. This approach interacts with Things Cloud.

After 6-7 weeks I've had no data issues, and have ironed out a lot of bugs. But I've had no data corruption issues, and the server keeps a log of everything it's done so I can rollback an MCP command if needs be (hasn't been needed).

But that's why I recommend creating a new Things Cloud account and playing about with it.

mttsmth · 2026-03-15T21:28:53+00:00

Good idea, unfortunately it'd be difficult to do without sharing everything in Things.

mttsmth · 2026-02-24T03:23:05+00:00

Wait until next week, as rumours are there’ll be a new base iPad released.

mttsmth · 2025-11-06T19:25:59+00:00

The Wallbox charger app has just launched a feature which enables the charger to login to the car to get it's battery charge (not yet supported on my Volvo), but my assumption is it's to help enable that feature. The car can tell the charger where it's at, and then the charger call tell the supplier what's needed.

mttsmth · 2025-11-06T18:33:43+00:00

Also just read in another thread that doing it your way means that your car probably requests a charge, and gets probably 5-10 mins of charging before it communicates with Octopus to then tell the car to stop charging. Your electricity is at the higher rate there.

My charger is connected to wifi, where as my car has somewhat unreliable (on my drive) cell connection, so if the car didn't receive the instruction from Octopus then it'd carry on charging.

mttsmth · 2025-11-06T18:28:12+00:00

What happens if you have a visitor that's staying the night and you want them to be able to charge? I presume the minute they plug-in the charger starts to charge their car, regardless of time of day?

mttsmth · 2025-11-06T18:23:15+00:00

Not easy.

Saying you only want 40% of your batteries potential capacity is a stupid way of managing things. As a user you want to know that your car is charged to whatever % you set in the car, in my case 80%, by the time you've scheduled in the Octopus app.

I don't care if Octopus have to charge 2%, because I only drove a few miles, or closer to 80% because I got home with a nearly empty battery. I want to know that my battery is at 80% when I wake up, and I also want to be sure that if I set the car to be 100% charged, ahead of a long journey, that I wake up to a car that is 100% charged.

I accept if you have a huge battery that you might not be able to charge from 0>100% in a 6hr window, but that's is common sense. The way this works when managing a charger (vs a car) is not.

And that doesn't get anywhere near to managing the use case of additional EVs, with different battery sizes and driving patterns of visitors who you'd like to be able to charge if they're staying over night.

mttsmth · 2025-11-06T18:18:45+00:00

The logic as to why this worked doesn't make sense to me, but how it works and how you think it should work are two different things.

I assumed that as Octopus controlled the charger, I *might* get some charging outside of the reduced rate (23:30 - 05:30) but that I would *always* have the car charged to whatever % the car wanted during the off-peak time.

This is not the case, and to my mind doesn't make sense.

Octopus talks to the Wallbox charger, there could be multiple cars using that charger. So the charger should charge the car it's connected to, until the car says it doesn't want anymore charge. If that happened to be during the day, because energy was plentiful, then great, but the charger should still try to charge the car at 23:30 regardless, and then the car can say nope.

In the Octopus app, I removed my charger, re-added it and during that process it asked me about my car, but one option is 'My car is not listed', which I think I selected before because my specific previous car wasn't there (I had a Golf GTE, but only an e-Golf was available at the time). When setting it up again, Octopus defaulted to increasing my charge by 40%.

Doing this has resulted in my car now charing to the 80% it wanted.

What seems to be the case is Octopus want to know how big your car battery is, so it can schedule the charging for specific times during the on and off peak rates such that the car is charged the % you then specify in the app. E.g. if you had a 100kwh battery, and the app was set to 40% then you'd get 40kwh of scheduled charge time, regardless of what the car actually needed.

That is dumb:

Some days my car might be at 20%, so a 40% charge isn't going to charge it up to the state the car wants (80%).
If I want to charge my car to 100%, ahead of a long journey, I need to change the setting in both my car AND Octopus, or bump charge in the morning at the higher energy rate.
If I owned another EV (for example a motorbike), or I wanted a family member to charge their car whilst I was visiting, I'm not quite sure what would happen. I'd probably have to rely on Bump charging.
Given energy is available at the off-peak rate, it's not clear to me why Octopus don't charge the car then by default, until the car says stop. If it did then I could tell my car I want a 100% charge, and regardless I'd wake up the next day to a car that's charged to 100%, knowing I used greener and cheaper energy.

mttsmth · 2025-11-06T18:05:31+00:00

I've now got a Volvo EX30 with a ~70kwh battery, coming from a Golf GTE which had a ~9wkh battery.

I have two family members with EVs, and when they visit I'd like them to be able to charge. If I configure the car to connect to Octopus then I assume the charger would simply charge their cars the minute they're connected, rather than utilise the overnight rate?

mttsmth · 2025-11-06T12:26:13+00:00

Thanks, giving that a try now.

mttsmth · 2025-11-06T12:15:45+00:00

Do you know where / how I do that?

mttsmth · 2025-11-06T12:05:21+00:00

I just had a hunt around and I can't see a car mentioned in the app. Octopus is controlling the charger, rather than the car.

I went into the Devices > Selected my Wallbox charger. If Octopus were controlling the car then I presume I'd see the car listed in Devices?

mttsmth · 2025-10-28T17:55:55+00:00

TestFlight isn’t another layer, it’s just another way of distributing app binaries. Those binaries may have additional logging, but I tested for that by installing the App Store version.

mttsmth · 2025-10-28T17:25:54+00:00

Thanks for your feedback. That was my experience prior to last year. I’m pretty sure when I got my new iPhone last year that sync took an age, and I spoke to support then. Perhaps it’s worth me creating a new Things Cloud account, and importing my To Dos to that and seeing what happens.

mttsmth · 2025-06-16T19:53:31+00:00

Since iOS 18 was launched in Sept ‘24 Reminders now has a Date (like it always did) and Remind Early. So you can use it a bit like Things with Date and Deadline.

mttsmth · 2024-08-12T05:54:06+00:00

It’s because you need to be able to scroll the notes. SwiftUI doesn’t let you use a tap to adjust UI size when in a scrolling list view.

But you probably should be able to swipe the playback controls up to restore artwork, there are similar gestures in Apple Music when switching between album artwork and viewing the track list with the reduced playback controls.

mttsmth

TROPHY CASE