Rendered at 04:40:18 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
apsurd 2 hours ago [-]
I think if nothing else the technical facing value proposition should be human written.
Communicating is hard but that’s the point, takes a lot of effort to close the gap between a new and skeptical user and your vision.
Devs will not be able to bypass the PTSD of reading Claude prose.
nostrebored 4 hours ago [-]
but... why?
you almost never want these tools in any given session, and creating any of them can be done simply with Claude. looking at the PRs, it seems like that is exactly what's happening. i guess this is my generic problem with MCP releases, who are they for and why?
rgbrgb 4 hours ago [-]
Im not OP but as someone who did one of these recently, I think about it kind of like sharing an essay. I had an idea, I clauded a working thing, used and refined until it was useful for my team then wanted to share the kernel that developed. OP is not claiming it’s like a panacea or a masterpiece and idk I appreciate the thoughts it’s making me think.
My other more general thought here is that the nature of LLMs is so generic and context specific that just learning about a workflow can unlock a ton of potential. This is evident in how the null state of every chat UI has a bunch of examples to teach you to use it. MCP’s are a portable way to share a workflow. To get concrete: I was pulling a lot of business data sources into my Claude code sessions to great effect but it was a force multiplier for my team to figure out an MCP version that would tell their Claude’s how to do the same. None of it was deeply technical engineering but it was immediately useful and most of the team using it are not engineers.
tulio_ribeiro 4 hours ago [-]
I’d go even further and add that these distinct tools don’t belong in the same toolbox.
serf 2 hours ago [-]
for high effort MCPs I see the reason. Big MCPs take major tokens to produce and test (if you're just telling an LLM to handle it) , it's nice if there is a high quality well tested thing out there to just plug into.
for things that are essentially a skill compendium, I see less reason..
ovciokko 4 hours ago [-]
contributors are one human and four agents, what an all star team
samrj12 4 hours ago [-]
Hey,
I liked this tool. Do you plan to develop more on the app creation tool? Is that shareable artifacts or what is the value prop?
srameshc 4 hours ago [-]
I admire your grit Asim, you never stop :) This looks great !! but what are we using for searching news here, I mean the sources ?
obilgic 5 hours ago [-]
Faith area is interesting.
sroerick 1 hours ago [-]
I honestly don't really get MCPs. They're like all the bad design choices of LSP multiplied by 5
xyzzy9563 2 hours ago [-]
Funny how you made the name Micro / MU while there is a major company called Micron with the stock ticker MU. Intentional I guess?
Communicating is hard but that’s the point, takes a lot of effort to close the gap between a new and skeptical user and your vision.
Devs will not be able to bypass the PTSD of reading Claude prose.
you almost never want these tools in any given session, and creating any of them can be done simply with Claude. looking at the PRs, it seems like that is exactly what's happening. i guess this is my generic problem with MCP releases, who are they for and why?
My other more general thought here is that the nature of LLMs is so generic and context specific that just learning about a workflow can unlock a ton of potential. This is evident in how the null state of every chat UI has a bunch of examples to teach you to use it. MCP’s are a portable way to share a workflow. To get concrete: I was pulling a lot of business data sources into my Claude code sessions to great effect but it was a force multiplier for my team to figure out an MCP version that would tell their Claude’s how to do the same. None of it was deeply technical engineering but it was immediately useful and most of the team using it are not engineers.
for things that are essentially a skill compendium, I see less reason..