It also comes with Toolforest's first interactive MCP GUI widget. Drag the slider below.

These interactive components only work on platforms that support MCP widgets, like Claude, ChatGPT, and Grok. Now that the foundation is built, I see a great opportunity to go back and add widget-leveraging tools to my existing toolkits.

Getting the widget to actually render in Claude took some effort. I noticed a lot of other developers in the community were hitting the same walls, so I built a simple, Claude-friendly reference implementation to make it easier. You can find it here: https://github.com/primevalsoup/mcp-apps-claude-demo.

Where the handle can't go

The slider is the fun answer, which naturally means it is the fragile one. Step outside a perfectly configured chat window into a markdown document, a saved history, or an older model that looks at interactive widgets the way a dog looks at a ceiling fan, and you suddenly need a regular, unglamorous image.

So EO builds the lowest common denominator first. Every panel starts with identical constraints: area, collection, settings, pixels. EO decodes each one and checks the math, mostly because APIs are perfectly happy to hand you half a picture and pretend it’s a whole one. If a panel is partial or misaligned, the comparison stubbornly refuses to proceed. Only when everything actually lines up does EO label the pieces, stitch them into a single PNG, and mint a short URL. That static image is the universal fallback.

Alongside it, EO sends a polite little dossier of the panels: their display order, image URLs, and titles. Then it washes its hands of the matter. The Toolforest layer takes over from there. Two panels become a wipe slider; three or four become a swipeable strip. A client that has no idea what an MCP widget is remains blissfully ignorant and just gets the labeled PNG.

EO’s job is to ensure the comparison is rooted in reality. Toolforest decides how to dress it up.

There is one ironclad rule: no blank panels. My first attempt at writing this post asked for a year the archive didn't actually cover at that site. Instead of cheerfully serving me a dramatic before-and-after of a Texas ranch and a dark void, EO just said no.

The picture came second

A before-and-after slider is a great trick provided you actually know the dates for the before and the after. The Stargate campus was easy since the construction schedule made the news. The real test is when nobody has any idea when to look. Here is a stretch of the Cascades near Skykomish, Washington, about two hours from my house.

(August 2022 left of the handle, July 2023 right: the same forest one summer after the Bolt Creek Fire. The burn is the brown-grey ground where green used to be.)

Nobody gave the assistant those dates. I just vaguely asked if anything had happened to this particular patch of trees in the last few years. The assistant made one statistics call and dragged back a monthly vegetation index covering ninety months. Every summer the line dutifully climbed to about 0.8. Then between August and September of 2022, the math fell completely off a cliff.

The comparison pictures were pulled only after the data spotted the drop. That statistical cliff had a real-world name: the Bolt Creek Fire, which closed Highway 2 that September.

The wrong number looks right

The Sentinel-2 API is always thrilled to hand you a number. The actual challenge is figuring out if that number has any relationship to reality.

The standard defense is a maximum cloud cover setting. But that measures the entire scene, not the specific place you care about. An image can pass the test with flying colors while a giant cloud parks itself directly over your lake.

During testing, Lake Shasta was full. For the exact same month, one cloud threshold produced a water index of −0.120 and another yielded +0.417. Both requests succeeded perfectly. Both numbers looked entirely professional. One of them was just a cloud.

So EO ignores the scene and looks at the pixels instead. It uses Sentinel-2's own classification to mask the clouds, then reports exactly what share of the month's pixels actually survived the purge. A month scraped together from ten percent of its pixels is no longer allowed to masquerade as a month computed from ninety.

When a month is completely clouded over, the Sentinel-2 API does not do the polite thing and return an empty row. The month simply ceases to exist. Read the results as a standard list, and every value after the missing month quietly slides into the wrong spot on the calendar. EO has to manually rebuild the expected timeline, put every value back where it belongs, and formally declare the gaps.

The physical burn scar is easy enough to see. The severity is harder to measure, mostly because the untouched forest still gets a vote in the average. Zoomed in on the burn, the average vegetation index the following summer was down a mere 0.09. That sounds like a mild dry spell. But the tenth percentile was down 0.25. The surviving trees soften the average, while the bottom tenth shows where the fire actually did its work. Getting that darker, more accurate view just takes one extra parameter.

Composability, again

Just like last week, when I showed how your assistant could bolt the Geo toolkit to Anki to build spatial flashcards, getting independent tools to cooperate isn't a trick. It’s just the natural result of pointing increasingly smarter LLMs at an expanding library of toolkits. The real objective here is getting the output to actually escape the chat window.

In this case, the objective was to write a short report on the Bolt Creek Fire, tracking the initial damage and measuring the forest's slow recovery over the last few years. To get there, the pieces assemble into a finished document, with each toolkit doing its specific job and passing the data cleanly to the next.

The Geo toolkit resolves the boundary into a short reference string. The heavy geometry stays safely on the server, and EO accepts the reference directly. This means a complex forest perimeter with twenty thousand vertices never has to cross the conversation and completely blow out the context window.

Once EO turns that reference into imagery and a clean time series, it hands off the baton. The Google Sheets toolkit takes the time series, builds a spreadsheet, generates a chart, and spits out an image of it. Finally, the Google Docs toolkit sweeps up the imagery, the chart, and the written analysis, and binds it all into a proper report.

(A satellite site report on the Bolt Creek Fire, assembled by the assistant in fourteen tool calls: seven years of monthly vegetation statistics, a chart built in Google Sheets, four summers of imagery, and the written analysis. Read the report.)

Boundaries on the imagery

The two toolkits also meet directly inside a single image. Boundaries supplied by Geo can be drawn straight onto satellite renders: an outline, a label, or a spotlight effect that dims everything outside the chosen polygon. Because the boundary arrives as a reference and resolves on the server, the exact same overlay gets applied to every panel of a temporal comparison. A highlighted parcel stays perfectly locked in place while the years shift beneath it. The county flashcards from last week can now show the county directly from space.

The point

Sentinel Hub, which serves the imagery under all of this, is a remarkably powerful API. It will search catalogs, process pixels, and calculate statistics all day long. What it will not do is stop you from asking a subtly wrong question. In fact, it will cheerfully return a successful, highly plausible, and entirely useless answer to one.

The toolkit's actual job is everything that happens between the raw endpoint and a trustworthy answer. It remembers which bands mean what on which sensor. It knows the difference between a cloudy scene and a cloudy pixel. It patches the calendar back together when months go missing, forces sampling scales to be explicitly reported instead of vaguely implied, and has the decency to explain a blank image rather than just shipping a void.

And now, it delivers a result that knows how to dress itself for the occasion: as a slick interactive slider where the client allows, and as a stubbornly reliable labeled image everywhere else.

The Geo post ended by promising that toolkit would get more useful this week. This is what I meant. Say where, say when, and drag the handle.

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

I've wanted my assistant to understand geography for a while. Not geography in the capitals-and-rivers sense, but the geography of actual questions: Where are the tennis courts near me? What's the largest park in town? Can you show me every county in a state on one map?

The data to answer all of these questions exists in OpenStreetMap, and it's open. The problem is that the raw APIs around that data are a poor fit for an LLM. They use a specialized vocabulary, return large and sometimes messy geometries, and can quickly bloat the model's context window by passing thousands of coordinates back and forth. This post is a little longer than usual because Geo turned out to be a particularly good example of the difference between wrapping an API and building a toolkit.

OpenStreetMap doesn't call a tennis court a tennis court

OpenStreetMap is an open tagging system, with a perfectly logical vocabulary that almost nobody actually speaks. In OpenStreetMap, a tennis court is leisure=pitch plus sport=tennis. A gas station is amenity=fuel. A drugstore is amenity=pharmacy. A model that queries for leisure=tennis_court has produced perfectly plausible English, but also an invalid query that returns nothing.

So the toolkit translates the request before it queries OpenStreetMap. It includes close to 4,500 natural-language aliases generated from OpenStreetMap's own tagging schema, validates values for the most commonly used tag keys, and expands interchangeable terms such as field, court, pitch, and diamond when they refer to the same kind of sports facility.

If you enter sport=tenis, it suggests tennis, table_tennis, and paddle_tennis rather than sending a typo off into the network and waiting politely for nothing to come back. It also handles multi-use facilities, so a court tagged sport=tennis;basketball appears when you ask for either sport.

When the toolkit rewrites a query, it tells you exactly what changed. The correction is visible, not silent.

Shapes you can trust

The second problem is what to do with the geometry once you have it. A lake or city boundary can contain thousands of coordinate pairs. You don't want to hand all of those coordinates to an LLM, so the toolkit simplifies shapes before returning them.

But simplification is also where the map can begin lying to you. Early on, I forced the Lake Washington shoreline down to 80 points and, in the process, apparently created 42.6 percent more lake.

The toolkit now projects the geometry locally and applies topology-preserving Douglas–Peucker simplification in metres. The algorithm removes points while retaining the overall outline, rather than forcing every boundary down to an arbitrary vertex count. It does not guarantee that area will remain unchanged, so area and other measurements still come from the original geometry. The toolkit also compares the simplified area with the original and warns you if it changes by more than 5 percent.

A simplified outline is fine for looking at. Just don't ask the sketch to do the measuring.

The toolkit also handles the geometry work LLMs are not particularly good at: merging all the parks in a city, buffering a boundary by 100 metres, intersecting two areas, measuring perimeter, or testing whether one shape contains another. The operation happens on the server, so the model gets the result rather than a pile of coordinates.

Keeping 21,000 coordinates out of the context window

The context-window problem became obvious in practice. I was passing the Shasta Lake shoreline between tools, and even after simplifying it to 586 vertices, the geometry was copied into the model's context three times, at several thousand tokens each time.

The full boundary has 21,512 vertices and would not fit at all. Simplifying it until it did fit solved the context problem by creating a geography problem: the lake's area shifted by 7.9 percent.

The fix was simple in principle: stop passing the shape around. When a tool produces a complex boundary, it stores the full geometry privately and returns a short reference such as aoi_7b8....

Every other Geo tool accepts that reference in place of the geometry itself. Derived operations return new references, so merge, buffer, and intersect can proceed without the shoreline ever taking a tour through the context window.

The model still gets the metadata it needs, including bounds, area, and vertex count, but never sees the coordinates themselves. References expire after about 48 hours. Identical geometry produces the same reference, so retries do not create duplicate lakes.

Rendering geography

Sometimes, after all that geometry, what you need is simply to see it. The new render_outline tool accepts boundaries by name, OpenStreetMap ID, or Geo reference and returns a hosted image.

It handles the mechanical parts of turning geography into an image: choosing a projection, fitting the canvas, assigning a colorblind-safe palette, and adding attribution. It also refuses to render an administrative boundary if it could assemble only part of it. A map can be wrong very convincingly.

Labels are harder. A cartographer can move them off-centre, add leader lines, abbreviate names, or split them across two lines. render_outline places one label per shape at a representative point. When two labels would collide, it drops one rather than overlapping them, and tells you which one it dropped.

That makes the tool better suited to outlines, highlighted regions, and other visual assets than to densely labelled reference maps. The resulting images can be used directly in a presentation or flashcard, or passed into another toolkit.

Here are Tokyo's 23 special wards, with Setagaya-ku highlighted. It took a single request, and none of the underlying geometry entered the model's context window.

Flashcards, because why not

Composability is where toolkits start to get more interesting. Since adding the Anki toolkit last month, I've been thinking of ways to connect it to something else, and geography supplied one almost immediately.

Learning where things are is a classic flashcard subject, but most existing geography decks are built from static image packs assembled by hand.

With Geo and Anki connected, my assistant generated a South Dakota county deck in one conversation. For each card, Geo renders the whole state with one county highlighted and the other 65 dimmed. The Anki toolkit then pulls the image into the deck by URL and creates the card. The front asks which county is highlighted; the back gives its name and county seat.

No image bytes enter the model's context window, and there is no static image pack to prepare in advance. The same process works for states, countries, city districts, or neighborhoods.

What's coming next week

Geo is useful on its own, but the reason I built it now is that I need it for the Earth observation toolkit I'm releasing next week. It will provide satellite imagery and vegetation and water statistics for any area you can describe in words, for individual dates or across a date range.

The two toolkits are designed for composability. A Geo reference for a merged set of parks, a buffered lakeshore, or a town boundary can pass directly into the Earth observation tools.

You'll be able to say, "Merge every park in my city and tell me how green they stayed between June and August," and the geometry will pass from one toolkit to the other without ever entering the model's context window.

The Geo toolkit is useful on its own. It gets a lot more useful next week.

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

Last week was quiet. I was traveling with family, so I didn't release any new toolkits.

When I added the Anki toolkit, it inspired me to add support for similar learning apps. Mochi jumped to the front of the queue because of my nephew. He's studying medical French this summer, and when I suggested Anki for the vocabulary grind, he told me he was already using Mochi. He prefers Mochi because it natively supports multi-sided cards. By adding markdown dividers, he can break complex concepts down into sequential steps.

Since I knew he already used Grok, getting him to be a guinea pig was easy. The problem with existing Mochi (and many other) MCP servers is that they run locally. Connecting a local server to a cloud-based chat client like Grok is a bit of a lift, requiring the user to set up and maintain a network tunnel for the connection. If I had asked my nephew to do that, he probably would not have bothered.

Toolforest's cloud architecture bypasses this completely, and since Mochi has an API, users don't even need to run a bridge like they do with Anki. They can just load their Mochi API key into Toolforest, where it's stored encrypted, and authenticate with their AI assistant.

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

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.