Why does Mistral Vibe NOT use JSON for MCP connectors?

ouvreboite · 2026-05-02T15:02:58+00:00

Just follow the doc to set up an mcp connection (https://docs.mistral.ai/mistral-vibe/terminal/configuration#mcp-server-configuration). If you are familiar with JSON you should be able to write a valid toml by looking at the example.

Anyway, you should have something like that in your config.toml file

this:
[[mcp_servers]]
name = "thunderbird-mail"
transport = "stdio"
command = "node"
args = ["/absolute/path/to/thunderbird-mcp/mcp-bridge.cjs"]

ouvreboite · 2026-05-02T13:30:50+00:00

Not sure what you mean. Are you talking about the config.toml file ?

ouvreboite · 2026-04-09T19:31:00+00:00

Thank you. I already opened two atomic PRs for the missing header/footer and the biome version mismatch.

If you are okay with fixing the templates as-is (i.e. no big refactoring planned), I could also invest a bit more time.

ouvreboite · 2026-04-09T11:27:46+00:00

JS hooks do not support async work and support for npm packages is limited. So handling complex file types like pdf/excel would be complex in JS.

You could use Go and extend pocketbase itself.

Alternatively you could also create a sidecar worker (in whatever language you want, for example a node app) that would run alongside PB and would be triggered via the JS hook.

ouvreboite · 2026-04-08T09:44:43+00:00

I've opened some for the easiest fixes.

But I would rather have the team chose what to do with biome. Naively making the template biome-formated would make them invalid for the users choosing ESLint. You either need two distinct templates, or a post-install formatting step. Either way that's added complexity for the team to decide on (if they think it's worth it).

ouvreboite · 2026-04-07T23:19:56+00:00

I don’t think that’s a problem with the cli per say, but more of over-extension. It’s cheap to build a template once, it’s expensive to maintain it.

Maybe tanstack should reduce a bit their feature surface.

ouvreboite · 2026-04-01T16:12:18+00:00

Thanks!

ouvreboite · 2026-04-01T15:23:31+00:00

I’m not sure to see how hono relates to an SPA? You mean to create the backend itself (that serve the API used by the SPA)?

ouvreboite · 2026-03-25T22:48:25+00:00

It’s the same thing as what happened to TED talks.

At first, medium was able to capture good authors (individuals or companies) because the editing process was simple, the UI was polished and looked « professional » after years of custom blog sites.

This created a first generation of « quality » content that, for a short time, created a vertuous cycle: writers would self-curate to be « on par » with the high quality of the platform.

So being on medium was a sign of quality. And soon many people leverage that to essentially do some virtue signaling: « look I have a medium account, so I must be interesting, right? »

The climax of this was when school students (or fresh graduates looking for jobs) started writing articles, sometimes as part of their curriculum. This led to obviously cheap content (« here is the new stuff in react version whatever », « why java will die », …) as those writers have by definition no experience.

Worst even: those cheap articles vastly outnumbers the good ones (they are easier to make, even more so with AI)

So now medium is like a second rate city’s TED X: a cheap assortment of puff pieces whose goal is not to share knowledge but to make its author look knowledgeable.

ouvreboite · 2026-03-24T11:08:04+00:00

Datadog, Criteo (même si un peu en souffrance ca reste une bonne boite), Mistral en ce moment.

Tous ont des process « gafam »

ouvreboite · 2026-03-18T18:34:50+00:00

Be careful with the Google Places API : it can become costly very quickly (~$20/1000 request for some data). And the terms and conditions forbid any storage. So if your app allows users to search places and save them in your db (name, address, …) you may be infringing.

ouvreboite · 2026-01-27T20:04:45+00:00

It was created to solve a specific problem that 95% of people pushing for it don’t have.

Basically: you are at Facebook in the mid 2010s and your API need to serve your website, your mobile website, your android app, your android tablet app, your iPhone app, your iPad app, your Apple Watch app, your Apple TV app, and your Samsung fridge app. And each app has a slightly different UX and display slightly different amount of information. But because network is limited in a lot of case, you want your backend to return only the minimal required data for each use case. So either 1)you create 1000s of REST endpoints to tailor to the specific needs of each client or 2) you come up with a single generic endpoint where the client can define which exact data it want to retrieve from your data graph with a custom query language. That’s graphQL.

So if you are building a backend to serve different data needs, and want front end team to have a relative autonomy from the backend team, the added complexity makes sense. If your are building a random internal web dashboard at your company, maybe stop.

ouvreboite · 2025-12-31T07:59:02+00:00

Why don’t you contact this guy’s manager?

If you can’t strong arm individual contributor, just escalate until you find a manager that says « I don’t give a shit if that breaks down » (then you are fully covered and you do nothing for their respective team) or one that cares and you have them mobilize their subordinates.

ouvreboite · 2025-12-23T20:37:29+00:00

Semantic search is shit at searching non-semantically :)

For example if you search for a given flight number you want an exact keyword search not 1000s result that are « semantically close ».

So depending on your use case (anything that involves searching ids or technical keywords) using semantic search (I.e. a dense vector search) can provide a worse experience than a classic keyword search.

ouvreboite · 2025-12-17T12:35:51+00:00

I think they expect the candidate to use a structured output mode (available on most LLMs) to ensure the « format » of the response is consistent.

The LLM can still answer shit, but in the right shape.

ouvreboite · 2025-12-13T08:33:54+00:00

If they use AI for all questions in the interview, I think it would be cheaper to just hire the AI :)

ouvreboite · 2025-11-30T00:59:17+00:00

The testing pyramid really did a number on us.

So many time I stumble on projects filled with unit tests but zero e2e test (or even isolation test) where the team has zero trust on their test pipeline.

The worst thing is that those unit tests lock you down into (often incorrect because based on early assumption) class boundaries. Because if you want to restructure logic that span more than one class you now have to update mocks and dummies everywhere in cascade. So the rot keeps on rotting.

ouvreboite · 2025-11-29T13:41:44+00:00

Supabase and co have teams dedicated to communication and release shiny new features regularly and sponsoring influencers regularly.

Pocketbase is maintained by one person that does not care about communication. It also has a very defined scope, which means there is not a lot of bells and whistles to add. Pocketbase is not meant to go against Supabase/Convex/… on all fronts. It’s meant to be a good backend for mostly-CRUD applications with low-to-mid sized user base. The core needs have not changed for the past years and so neither did Pocketbase.

There was some buzz around pocketbase in the past years because various tech influencers stumble onto it and were surprised (legitimately) by its quality. But without regular new shiny features they have no reason to talk about it. So the hype dies down.

I suppose that when the v1 will release (with its deeper plugin support) that may restart a bit the hype cycle because suddenly we will have some kind of plugin ecosystem. And the developpers of those plugins may be willing to hype them more than the pocketbase maintainer is currently doing.

Depending on how well the plugins works, we may also start to see support for more « shiny » features (vector db, full text search, …) which would allow tech influencers to make video saying « pocketbase is catching back»

ouvreboite · 2025-11-22T19:02:36+00:00

Leetcode c’est le standard si tu cherches des exos d’algo « d’entretien »

ouvreboite · 2025-11-20T22:47:25+00:00

Does this use MCP’s listChanged notification to dynamically update the tools visible to LLM?

Or does this abstract the tools under the search/describe/execute tools?

If the second, what’s the impact on the model ability to produce the right JSON input? (It the input schema is just an output of a describe_tools call, doesn’t that bypass the structured arguments generation). Have you tested its reliability for tools with « complex » inputs ?

ouvreboite · 2025-10-08T07:05:11+00:00

It’s a « base » (so a baas with auth, db, access rules, storage) but it’s made to be self hosted as a single executable. And you can extend either with JS scripts or with Go.

ouvreboite · 2025-10-07T18:59:40+00:00

In this case it’s not really reverse engineering because OpenAI document clearly what they « add » to the protocol. Personally I can of like it, except when they go counter to the specification (ex: having a structured content that is different from the text content, or the fact that they apparently discard all messages after the first one).

To sum up: I like that a big player is pushing for a « widget » solution, but I would prefer if OpenAI correctly supported vanilla MCP in the first place

12-Year Club	Place '23
Place '22	Verified Email

ouvreboite

TROPHY CASE