Thanks, but i believe the business model of a one time payment is not that great tbh, im joining anyways, but i just wanted to know how people make this a profitable business
MCP is great. But what i'd like to understand is whats the difference between MCP and manually prompting the model a list of tools with description and calling the specific function based on the llm response ?
1. it makes tool discovery and use happen elsewhere so programs become more portable
2. it standardizes the method so every LLM doesn't need to do it differently
3. it creates a space for further shared development beyond tool use and discovery
4. it begins to open up hosted tool usage across LLMs for publicly hosted tools
5. for better or worse, it continues to drive the opinion that 'everything is a tool' so that even more functionality like memory and web searching can be developed across different LLMs
6. it offers a standard way to set up persistent connections to things like databases instead of handling them ad-hoc inside of each LLM or library
If you are looking for anything more, you won't find it. This just standardizes the existing tool use / function calling concept while adding minimal overhead. People shouldn't be booing this so much, but nor should they be dramatically cheering it.
You can build all the tools yourself, or you can just go to a "tools store", install it and use it. MCP is just the standard everyone can use to build, share and use these tools.
Just like an app store, a chrome extension store, we can have a LLM tools store.
I totally agree, but what i hate about react.js is that if you have like a big app, the routes definitions will be a nightmare, i would love to see native file routing system inside react.js
> i hate about react.js is that if you have like a big app, the routes definitions will be a nightmare
I'm curious how you define your routes cause I've got several big apps with lot of routes, nested routes and complex access permissions for each route and it never entered in my mind that there was anything complicated about it.
lol this is exactly what im trying to understand, you hear this phrase sometimes in yt videos. I mean it doesnt make sense unless probably you are selling a t-shirt for your community, posting a pic of the product to see their reaction, but in the tech industry it seems impossible
If it's a child sitting on the lap with her father, and her father is related to Hezbollah (and as such carrying a pager), this stuff could happen, I think.
Apparently a message was sent to the pagers right before exploding. I saw in a couple videos where the victim looked down at their hip and angled it to see the screen. It makes sense as a trick to ensure the target is close by when it goes off, but a kid could just as easily pick it up off a table after hearing it buzz.
I don't get it, you can already get the user time zone with javascript
```
Intl.DateTimeFormat().resolvedOptions()
```
a good library like dayjs can handle timezones
It's quite annoying to deal with different library dependencies that all picked a different userspace library for something that should be standardized. For example, you might ship a date picker component using dayjs, but I already adopted Luxon in my application, so now I need to write some janky adapter or end up using both.
I would love to not have to import dayjs or another userspace library, so that i can pass datetime-with-timezone to other libraries and instead use an IETF standard way of handling time that's backed by performant native runtime code.
In my experience, userspace timestring parsing and timezone conversion can also be a surprising CPU bottleneck. At Notion, we got a 15% speedup on datetime queries by patching various inefficiencies in the library we selected. The runtime can be more efficient as well as saving page weight on tzdata and locale stuff.
