This week I added a toolkit for Anki.

Anki is the flashcard app a lot of people rely on for spaced repetition, and now you can build and organize Anki decks using your AI assistant. Describe what you're trying to learn, and the cards land in your library ready to review.

This toolkit was different to build. Every other Toolforest toolkit so far connected to a cloud API. Anki runs on your desktop and has rich plugin support. So I built two pieces: a cloud gateway, and a bridge add-on that runs inside Anki and connects to it. The bridge is self-contained. It signs in with Toolforest using a device-code flow, then authenticates to the gateway with a scoped bridge token for the Anki capability.

The gateway provides a generic way for desktop and other local software to reach into Toolforest. That opens up a whole category of toolkits that weren't possible when everything had to be a cloud API.

The Anki toolkit has also inspired me to add support for similar learning apps, which are coming soon.

As always, ideas and suggestions are welcome at gerrit@toolforest.io.

It was a busy week elsewhere, so this one is light. Just two updates: a toolkit I'd been meaning to build, and a small bit of tidying on the homepage.

A Google Health toolkit

Toolforest already has a Fitbit toolkit, and it isn't going anywhere yet. But Google has said it will eventually retire the current Fitbit Web API, so I wanted a replacement ready before that day arrives. The new Google Health toolkit reads the same kind of data: activity, sleep, heart rate, and the rest. It also isn't limited to Fitbit hardware, so it can read from other Google wearables like the Pixel Watch.

Like Gmail and the other sensitive Google APIs, health data sits behind a verification process that Google requires before an application can offer it to everyone. I'm going through the process now, which from past experience will take several weeks. Until it's approved, access is limited to whitelisted users, so the toolkit has a register button that lets you request access in the meantime.

Tabs for the toolkits

The other change is smaller. As the number of toolkits has grown, having them all on one screen had started to feel crowded. The homepage now groups them into tabs, so the music toolkits sit together, the Google toolkits sit together, and so on. A small thing, but it should keep the set easy to scan as it keeps growing.

As always, ideas and suggestions are welcome at gerrit@toolforest.io.

Connecting your mail to an assistant means the model sees whatever is in those messages. Login and verification emails are a good example.

A one-time code is meant for you, once, for a minute, and then never again. Nobody sets out to hand a bank's verification code to an LLM. You just ask it to check your mail, and in comes the code, riding the same wave as the receipts and the reminders and the promotional clutter, perfectly ordinary and entirely exposed.

Redaction for Gmail

So this week I added security-code handling to the Gmail toolkit, and it's on by default. When the toolkit reads a message, it detects login codes, one-time passwords, password reset URLs, and magic links, and replaces them with a [REDACTED] placeholder before the content is returned to your assistant. The rest of the message comes through as normal.

It works off a dynamic list of known security-code senders combined with text patterns for the codes and links themselves. The point is to protect you if an assistant, a local agent, or some connected app is ever compromised, and to stop a malicious email from using prompt injection to talk your assistant into handing over a code.

If you want something other than the default, the toolkit's settings let you switch from redacting just the codes to withholding any message that looks like it contains one, or turn the handling off entirely. The setting applies across all of your sessions. I'd leave it on.

You can read more in the Gmail section of the docs.

A MusicBrainz toolkit

The music side of Toolforest already had ListenBrainz, Last.fm, and Apple Music. This week I added a MusicBrainz toolkit to sit alongside them. Toolforest has kept a replicated MusicBrainz database for a while to back the ListenBrainz toolkit, and the new toolkit puts that data directly in your assistant's hands.

The toolkit resolves any artist, recording, or release to its canonical MusicBrainz identifier and reads the credits behind a track: who produced it, who engineered and mixed it, and who played what. Credits in MusicBrainz are sometimes attached to the album rather than the individual song, so the toolkit also checks the release level. A question like "who produced this track" still gets an answer even when the credit lives one level up.

There are also relationship tools, so you can start from a band and branch outward to its members and the other projects they belong to. Put together with ListenBrainz, that means your assistant can take your most-played tracks and tell you the recurring producers behind them, or map the collaboration web around a band you like. There are now cookbook examples showing both.

As always, ideas and suggestions are welcome at gerrit@toolforest.io.

A user wrote in to say that there was no reason to use Toolforest for Gmail, because his AI assistant already came with a Gmail connector.

The catch was that it only supported one Gmail account at a time, and he had several that he used regularly. He said that if I could support multiple accounts, he would switch. So this week I added multi-account support for all of the Google toolkits: Gmail, Calendar, Tasks, Docs, Sheets, and Slides.

Toolforest now supports the concept of a primary account, which is the default and which you don't need to refer to by name, and any number of secondary accounts, which you do need to refer to by name.

Of course you can also say things like "summarize my recent mail for all my Gmail accounts" or "summarize events from all my calendars for today."

I hope users find this helpful, and I welcome your continued suggestions. You can reach me at gerrit@toolforest.io.

A week after introducing toolforest.io on the ListenBrainz forum, I got a couple of good suggestions: add support for Grok, since they'd just introduced support for third-party MCP connectors, and take a look at Last.fm.

Grok now works too

This one was just a matter of configuration. That leaves Gemini as really the last major holdout among the major AI assistants. I'm hoping they come around soon.

Last.fm

After spending some time on the Last.fm subreddit, I noticed an active subset of the community that's specifically looking to connect with "compatible" users, people whose listening overlaps with theirs. There's even a recognized kind of post for it, where someone shares their username and invites others to check compatibility.

That struck me as a great use case for a toolkit. By giving an LLM access to any two users' top artists and listening summaries, the toolkit lets it produce a rich compatibility analysis: finding the bridge artists between two libraries, telling a casual shared play apart from a real favorite, and pointing out where two tastes meet and where they diverge. There's an example of this generated by Grok in the cookbook.

There's also room to make the Last.fm toolkit even richer. Because toolforest.io already maintains a replicated MusicBrainz and ListenBrainz database for the ListenBrainz toolkit, I can lean on that same data to resolve artists to canonical identifiers, round out the metadata, and answer relationship questions across libraries. I haven't built that layer yet. I'll wait and see what the Last.fm community comes back with first and build it if there's sufficient interest.

If you have ideas for toolkits or enhancements, you can reach me at gerrit@toolforest.io or through the request form on the homepage. Thanks to the folks on the ListenBrainz forum who took the time to write back.

This project started as something much smaller than it became.

A few months ago I wanted a clean way to give Claude access to Google Sheets and Google Docs. That was it. I use those tools every day, and the existing options either didn't work the way I wanted or mapped so directly to the underlying API that the LLM ended up doing all the heavy lifting itself. Fighting font metrics, retrying calls, hallucinating field names.

Once I had a working framework for one toolkit, I realized adding another wasn't much work. Then a third. I started thinking less about individual integrations and more about what an aggregator could look like if it were built specifically for the things consumers actually use (fitness data, listening history, prediction markets, calendars), rather than the developer and enterprise APIs that everyone else has already covered well.

That's toolforest.io. As of today it's in open beta.

What's different

There are excellent sites out there, like Zapier and Composio, that connect AI assistants to hundreds of APIs. For a lot of use cases they're a perfect fit. The thing I kept running into, though, was that many of these integrations are essentially thin wrappers. The LLM gets handed the same surface the API exposes, with all of its quirks intact.

I think there's real value in adding an intermediate layer between the toolkit and the underlying API. A few examples of what I mean:

• Google Slides. The raw API has no concept of font metrics, which means LLMs routinely generate slides where text overflows its text box. Toolforest's Google Slides toolkit measures fonts properly and gives the model the tools it needs to lay things out correctly.
• Google Sheets. The default auto-resize-column behavior doesn't measure fonts accurately. We compute widths properly so the output actually looks right.
• Polymarket and Kalshi. The raw APIs expose markets, events, prices, and order books, but they don't have a built-in concept of "what's moving." The toolkits add that layer by continuously snapshotting markets, computing price and volume changes over multiple windows, filtering out low-volume noise, and normalizing the quirks between venues. The model can ask for meaningful movers directly instead of trying to assemble that analysis from a pile of raw API calls.
• ListenBrainz. Toolforest maintains a replicated MusicBrainz and ListenBrainz database, so the toolkit can do more than proxy the public API. It resolves missing MBIDs, normalizes time ranges, paginates large histories, explains empty or truncated results, cleans playlist metadata, and supports database-backed questions the public API doesn't expose directly. The result is that an assistant can answer questions like "which Pink Floyd tracks has this user listened to most over time?" or "which similar artists should I explore?" without stitching together brittle raw API calls.

The LLM just gets the right answer faster, and the user never sees the plumbing.

Why I'm announcing this to ListenBrainz first

The toolkits across the site are all live, but I wanted to introduce toolforest somewhere specific rather than everywhere at once. ListenBrainz felt like the obvious place.

I've spent time on the community forums recently, and what struck me was how much of what people want to build is exactly the kind of thing an LLM with structured access to listening data is good at. Taste twins. Year-end summaries that are actually personalized. Reconstructing the shape of a specific day, a year ago. Connecting dots across years of scrobbles.

The dataset is open, the community is generous, and the use cases are genuinely fun. It felt like the right room to walk into first.

If you want to try it, the easiest path is to connect your ListenBrainz account to Toolforest and ask Claude (or whichever assistant you use) something like "According to my ListenBrainz data, who are my three closest taste twins?" The examples in the Cookbook section will give you a few more ideas.

Where this goes

This is a personal project. I have no plans to commercialize it. I'll support the infrastructure myself for as long as that's reasonable; if usage ever gets to the point where the costs become a problem, I'll figure something out then.

What I'm most interested in, though, is closing the loop on toolkit development itself. The same LLMs that use these toolkits are pretty good at evaluating them: finding rough edges, suggesting better tool shapes, inventing use cases I wouldn't have thought of. I've been building a pipeline where models do exactly that. Pick a toolkit, invent a use case, execute it, evaluate the result, and write the findings back as structured feedback. The end state is something close to LLM-guided toolkit development, where agents propose new toolkits, build intermediate layers, and roll them out with minimal hand-holding from me. I'll write more about that in a future post.

If you have ideas for toolkits or enhancements you'd like to see, you can reach me at gerrit@toolforest.io or through the request form on the homepage. And if you're a ListenBrainz user, thanks for taking a look. Hoping this is useful.