241–250 of 383 posts
FYI the gif is not visible to us. In the shared chat: > Perfect! I've created your Slack GIF! > [Files hidden in shared chats]
> imagine a folder full of skills that covers tasks like the following: > Where to get US census data from and how to understand its structure Reminds me of my first time using Wolfram Alpha and got blown away by its ability to use actual structured tools to solve the problem, compared to normal search engine. In fact, I tried again just now and am still amazed: https://www.wolframalpha.com/input?i=what%27s+the+total…
tbh wolfram alpha was the craziest thing ever. haven't done much research on how this was implemented back in the day but to achieve what they did for such complex mathematical problems without AI was kind of nuts
We only call it AI until we understand it.
Once we understand LLMs more and there's a new promising poorly understood technology, we'll call our current AI something more computer sciency
These skills also rely on tools, having a standard way to add tools to an agent is good, otherwise each agent has its own siloed tools.
But also, I remember MCP having support for resources no? These skills are just context (though I guess it can include executable scripts to help, but the article said most skills are just an instruction markdown).
So you could already have an MCP expose skills as resources, and you could already have the model automatically decide to include a resource based on the resource description.
Now I understand to add user created resources is pretty annoying, and maybe it's not great for people to easily exchange themselves resources. But you assume that Slack would make the best context to generate Slack gifs, and then expose that as a resource from their MCP along with a prompt template and some tools to help or to add the gif to your slack as emojis or what not.
You could even add Skills specifically to MCP, to that you can expose a combination of context resources and scripts or something.
That said, I agree that the overabundance for tools as MCP is not that good, some tools are so powerful, they can cover 90% of all other tool use cases. Bash tool can do so many things. A generic web browsing tool as well. That's been the problem with MCP as tools.
Skills appear to be a good technique as a user, and I actually already did similar things. I like formalizing it, and it's nice that Claude Code now automatically scans and includes their description header for the model to know it can load the rest. That's the exciting part.
But I do feel for the more general public, MCP resources + prompts + tools are a better avenue.
Earlier quoted context omitted.
I don’t really see how this replaces MCP tbh. MCP gives the LLM access you your APIs. These skills are just text files with context about how to perform specific tasks.
You don't need MCP if you can instead drop in a skill markdown file that says "to access the GitHub API, use curl against api.github.com and send the GITHUB_API_KEY environment variable in the authorization header. Here are some examples. Consult github-api.md for more."
Depends on who the user is...
A difference/advantage of MCP is that it can be completely server-side. Which means that an average person can "install" MCP tools into their desktop or Web app by pointing it to a remote MCP server. This person doesn't want to install and manage skills files locally. And they definitely don't want to run python scripts locally or run a sandbox vm.
I do think the big story here is how hyperfocused and path-dependent people got on MCP, when the actually-interesting thing is simply "tool calls". Tool calls are incredibly interesting and useful. MCP is just one means to that end, and not one of the better ones.
It's nice to have an open standard though. In that sense it's pretty awesome.
But MCP isn't just tools, you can expose prompt templates and context resources as well.
All the skills that don't have an added dependency on a local script could just be an MCP resource.
We're doing something like this internally. Our monorepo context files were much too big, so we built a progressive tree of fragments to load up for different tasks. I am struck by how much these kinds of context documents resemble normal developer documentation, but actually useful and task-oriented. What was the barrier to creating these documents before? Three theories on why this is so different: 1) The feedback…
Edit- I'm basically repeating the poster who said it's principal agent problem.
Earlier quoted context omitted.
tbh wolfram alpha was the craziest thing ever. haven't done much research on how this was implemented back in the day but to achieve what they did for such complex mathematical problems without AI was kind of nuts
> without AI We only call it AI until we understand it. Once we understand LLMs more and there's a new promising poorly understood technology, we'll call our current AI something more computer sciency
Earlier quoted context omitted.
Would really like something selfhosted that does the basic Wolfram Alpha math things. Doesn't need the craziest math capability but standard symbolic math stuff like expression reduction, differentiation and integration of common equations, plotting, unit wrangling. All with an easy to use text interface that doesn't require learning.
Personal faves: - Mathematica - Maple - MathStudio (mobile) - Ti-89 calculator (high school favorite) Others: - SageMath - GNU Octave - SymPy - Maxima - Mathcad
I do think the big story here is how hyperfocused and path-dependent people got on MCP, when the actually-interesting thing is simply "tool calls". Tool calls are incredibly interesting and useful. MCP is just one means to that end, and not one of the better ones.
> Tool calls are incredibly interesting and useful. MCP is just one means to that end, and not one of the better ones. It's nice to have an open standard though. In that sense it's pretty awesome. But MCP isn't just tools, you can expose prompt templates and context resources as well. All the skills that don't have an added dependency on a local script could just be an MCP resource.
