But this is just using the Model Context Protocol that Anthropic itself released to let Claude use tools in order to do actions outside the context of the conversation.
Hey folks, we at June (YC W21) built an open-source app store for Claude which makes installing MCPs in Claude super easy. We've been using MCPs within Claude for a while and found them super useful, for example, with the Slack and Linear MCPs, we can ask Claude to find the last bug a customer reported in a shared slack channel and open an issue on Linear with all the details.
We found that installing MCPs was not the most straightforward experience, especially for someone who doesn't have Python and Node set up on their computer. So we built a desktop app that handles the complexity of installing the right tools in the environment to make MCP installation super easy.
The app itself is open-source and it runs only on your machine. Your data only goes to Anthropic when you ask Claude to do something with it. You can find the GitHub repo here: https://github.com/fleuristes/fleur. We also have an app registry where you can submit more MCPs: https://github.com/fleuristes/app-registry. We're making sure that every MCP we add works really well because we found a ton of them which had errors and didn't work. We're also trying to figure out a way to make the Google OAuth flow very smooth before we add the Gmail and Calendar MCPs.
Not sure tbh, but right now there's a supporter tier ($50) to support sustainable development, which has everything from the free tier + gives early access to new features + a discord badge
Yep that's the reason we generate a schema.sql at the end so that you know the current state of the database after the migrations have been applied (you don't need to mentally sum those migrations). Coupled with git, you get to see the diff of the schema.sql to see what changed which is super useful, like the same additional index example you mentioned.
I agree with your point about SQL's readability, however, I think there's value in having structured metadata around migrations, like dependencies between migrations, rollback instructions, and environment specific variations, beyond just the raw SQL.
This could be done with SQL comments, but having it in a structured format makes it more reliable to parse and validate programmatically. I do see why YAML's quirks could become a problem in a tool that's meant to help you make sure your database is in order, we didn't run into issues like country codes or numbers being interpreted as sexagesimal (yet).
Perhaps a middle ground would be to keep the actual migrations in .sql files for readability, while using a separate metadata file (in JSON or TOML) for the orchestration details. What do you think?
This makes a ton of sense! We've faced the same exact problem because whenever we need to add a new materialized table or column, we need to backfill data into it.
For materialized columns, it's a "easy" (not really because you still need to monitor the backfill) because we can run something like `ALTER TABLE events UPDATE materialized_column = materialized_column WHERE 1`. Depending on the materialization that can bring the load up on clickhouse because it still creates a lot of background mutations that we need to monitor, because they can fail due to all sorts of reasons (memory limit or disk space errors), in which case we need to jump in and fix things by hand.
For materialized tables, it's a bit harder because we need to write custom scripts to load data in day-wise (or month, depending on the data size) chunks like you mentioned, because an `INSERT INTO table SELECT * FROM another_table` will for sure run into memory limit errors depending on the data size.
I would love to think more about this to see if it's something that would make sense to handle within Houseplant.
Interesting, we didn't run into the need for blocking and async migrations for our use case, because we do incremental updates to our clickhouse schema. What do you mean by needing to change the ordering of existing tables? I'll check out the background migrations link tomorrow!
You can run DDL commands directly on ClickHouse, but after you have a lot of these commands in your codebase, it becomes a pain to manage them. We had these commands defined in a lot of ruby files named <timestamp>_create_table.rb using which we mimicked the way rails and active record manage the app database migrations. Rails and active record also give you a schema.rb which shows the latest state of the app database at all times. After having no schema.rb for a long time, and it becoming a pain to manage the standalone migration files in ruby, we decided to build this to be able to manage migrations for ClickHouse, our analytics database. We love using it and the schema.sql file (with the latest db state) it generates at the end.
As pointed out in this thread, right now it only works with text-based PDFs. But there's a PR[1] which will add OCR support (using EasyOCR) for image-based PDFs in some time.
Yes I need to work on that PR, haven't been getting a lot of free time these days. It adds OCR support using EasyOCR, which I found on HN some time ago!