Similar approach as MCPCat (telling agents to specify context about why a tool was called in special tool arguments): https://mcpcat.io/
I don't love it (potential privacy issues, and it makes the user's agent spend more tokens), but I don't think there's a better approach right now. Would be great if someone took the time to add an observability mechanism to the MCP spec itself.
After taking a closer look at MCPCat the implementation is quite different for MCPCat you need to integrate a SDK and HyprMCP works as a proxy in front for your already existing MCP server.
That's more or less how Tokyo works. Almost no on-street parking, people have to prove that they have a parking spot when buying a car, liberal zoning so there are lots of very small pay parking lots around the city. It works really well IMO but it would be politically very difficult in North America.
Sharpening a knife to r/sharpening standards is hard. But just honing frequently and occasionally using a cheap sharpener will get you further than 95% of home chefs.
If it’s not maximized, the space isn’t wasted. The title in the response image looks incredibly crowded. May be ok if several buttons could be removed from the titlebar.
Many people use tiling window managers, so title bars become useless. The first thing I did in configuring ghostty was disabling window decoration for this reason.
I work in this space and I was not able to understand how this project works in a couple minutes. The README feels LLM-generated. I think you're supposed to point this at your MCP server's code and not the server itself, is that right?
sorry for the issues you are facing. can you let me know what was the issue? the repo can scan github mcp server code posted in the repo like https://github.com/punkpeye/awesome-mcp-servers and provide a quick, deep, or deep with ai analysis. let us know if there is anything we can help with.
Aider is good at one-shotting Git commits, but requires a human in the loop for a lot of iteration. Claude Code is better at iterating on problems that take multiple tries to get right (which is most problems IMO). I was really impressed by Aider until I started using CC.
Anthropic's Research is pretty good; I'd say on par with OpenAI.
Agreed about Google, accuracy is a little better on the paid version but the reports are still frustrating to read through. They're incredibly verbose, like an undergrad padding a report to get to a certain word count.
That's Gemini Pro now in general. The initial preview was pretty good, but the newer iterations are incredibly verbose.
"Be terse" is a mandatory part of the prompt now.
Either it's to increase token counts so they can charge more, or to show better usage growth metrics internally or for shareholders, or just some odd effects of fine tuning / system prompt ... who knows.
That's sort of the popular wisdom, but rails don't guarantee it will be there for the long run. DC recently announced that they're replacing their light rail with buses:
I agree with him that in order to endure and justify a permanent operating subsidy a transit service needs to be useful and used by many people. Most American light rail doesn't meet that bar.
Interesting piece, thanks. I also enjoyed his piece "Streetcars: An Inconvenient Truth." His argument is based on length, speed and cost; the main point is that a technically equivalent bus would often be cheaper and thus could be run on a longer, more useful route. If you look at the hundreds of millions spent on DC Streetcar and its limited utility, this all starts to look quite obvious. So why did we do it?
I think there is another aspect that usually goes unstated, which is the vibes. If you're a mayor you want to build a tram. If you're a tourist you want to ride a tram. If you're a prospective resident you want to live near a tram. Yes, it's smoother and yadda yadda, but really it's because it has more sex appeal. A technically equivalent bus may well be _technically_ equivalent but could never be truly equivalent. Nobody would write a play entitled A Technically Equivalent Bus Named Desire. In a way, spending money on a tram is similar to spending money on parks or flowers or public art. And so we will spend the money; and we will build the streetcar; and damn the technical equivalence.
I wonder what the world would be like if we were honest with ourselves.
I never heard of the (Washington, D.C.) DC Streetcar until this comment.
Wiki tells me:
> The DC Streetcar is a surface streetcar network in Washington, D.C. that consists of a single line running 2.2 miles (3.5 km) in mixed traffic along H Street and Benning Road in the city's Northeast quadrant.
Is it even worth building a rail project that short? I had less than 900K riders last year. Something about light rail is so underwhelming to me.
This is very useful, thanks. I've implemented similar authentication with tower_cookies in a home project, and it took me a long time to figure out; Axum is powerful but not always the most intuitive. It was a great learning experience, but I'd love to offload more of this to a crate next time.
Rust ORMs still don't feel great. They're verbose, the tooling is flaky, and they feel fly-by-night. They're surprisingly not very type safe either. I'd rather use Rust's sqlx until the Rust ORM situation improves.
Axum and Actix are already drop in replacements for something like Flask. They're mature and good at what they do.
The dream of a Rails or Django in Rust is still really far off. I'm glad the Loco folks are trying, but it needs a lot more magic and maturity to truly bear that comparison.
Back when SeaORM first released, I was excited about another ORM that supported async (as Diesel didn't have an async shim at the time), but man does it have some weird design decisions.
The underlying query builder's API is just downright odd. The ActiveRecord pattern is fine for SeaORM, but it's just... weird. The ergonomics aren't right.
It's sent me down the path of wanting to design an ORM for myself that has the ergonomics I want. Nothing really to show yet at this point, but still something I want to build out someday.
Can you please explain what you found weird? I just started using sea-query and haven't found anything super odd quite yet, but I've only written a few migrations and queries so far
Namely, it comes from their query builder's API choices. For example, from SeaQuery's README:
```
use sea_query::*;
// For example Character table with column id, character, font_size...
pub enum Character {
Table,
Id,
FontId,
FontSize,
}
// Mapping between Enum variant and its corresponding string value
impl Iden for Character {
fn unquoted(&self, s: &mut dyn std::fmt::Write) {
write!(
s,
"{}",
match self {
Self::Table => "character",
Self::Id => "id",
Self::FontId => "font_id",
Self::FontSize => "font_size",
}
)
.unwrap();
}
}
```
The idea that the `Table` is part of the `enum` is an odd choice to me. The `Iden` trait also has an odd shape and use to me, as well.
In theory, the API for SeaORM is something I like, but in practice it feels off and stilted. Still a really cool project and I hope things improve over time, but Rust is going through a lot of growing pains around ORMs and database access.
I've used it for 3-4 months in a lot of my projects. For very basic queries it worked very well and I liked it quite a bit, but as soon as I had to do something a little less standard that's where I started to see the issues.
Documentation is not really there yet and I ended up loosing tons of time trying to look for the right function in the crate that would translate in the query I had to make. I've blogged about that too if you're interested [0] (TLDR: I got back to using raw SQL)
I don't think "glue" frameworks like Loco can get us there tbh. One problem is that frameworks like Django or RoR have to be tightly integrated! Auth needs to be aware of models and sessions, autogenerated admin pages like Django have to rely on model metadata, templates and view code might need to be aware of cache busting and static file handling, etc etc. It's a tough problem and a very high barrier to creating a new comprehensive framework.
I'm using Loco a lot since half a year, and have contributed some upstream patches. It's definitely not Rails, but where I was always afraid of refactoring Python applications, that fear is pretty much gone with Loco/Rust. That, and the incredible performance make me enjoy it a lot now. You pay extra with development time, but you get it back with long term maintainability.
My main remaining gripe is the Rust compilation speed...
I looked into it recently. Apparently it has session based auth.
I tried to figure out how to do the first thing that came to mind: on an incoming request, check that the user is authenticated, and if not redirect them to a login page with a ?next= parameter to be redirected back to after login.
Couldn't find a way to do it. In Django you use the @login_required decorator on a view and that's it.
Unfortunately it seems like you have to write a custom Axum middleware to retrieve the current user and then do the redirect manually. Not many lines of code but still…
And then again manually fetch the next query parameter after login.
This is such a common pattern, I’m astonished that it’s not provided out of the box.
I don't love it (potential privacy issues, and it makes the user's agent spend more tokens), but I don't think there's a better approach right now. Would be great if someone took the time to add an observability mechanism to the MCP spec itself.
reply